Re: Set binprefix when not using slashpackage

From: Patrick Mahoney <pat_at_polycrystal.org>
Date: Tue, 02 Aug 2016 21:08:17 -0500

On , Laurent Bercot wrote:

> On 2016-08-02 19:41, Patrick Mahoney wrote:
>
>> Yes, the absolute path will be stable. This could be set at
>> configure time and would never change.
>
> Let me repeat/rephrase my question: will it also be true if the
> package,
> or a dependency of the package, gets updated?

Yes. Sort of. In Nix, if /nix/store/vkik24-s6-2.3.0.0 references
/nix/store/q4jpv9-execline-2.1.5.0, that will never change (packages
are immutable).

A new version of execline implies a new version of s6 (even if nothing
but s6's dependencies have changed). So /nix/store/qa8jl4-s6-2.3.0.0
now references /nix/store/k35q95-execline-2.1.6.0.

> With slashpackage, say for the s6-svc command, you have two guaranteed
> absolute paths:
>
> - the versioned one: /package/admin/s6-2.3.0.0/command/s6-svc
> This is used by commands *inside* the s6 package, to make sure they
> always
> call binaries from the same version as their own. It is encoded in
> /package/admin/s6-2.3.0.0/include/s6/config.h as S6_BINPREFIX.
>
> - the non-versioned one: /package/admin/s6/command/s6-svc
> This is used by basically everyone else, to reach the s6-svc command no
> matter what s6 version is currently the default, and is the "official"
> absolute path for the s6-svc command. It is encoded in
> /package/admin/s6/include/s6/config.h as S6_EXTBINPREFIX.
>
> AIUI, the Nix system provides a guaranteed absolute path that contains,
> under one form or another, the version of the software, i.e. something
> suitable for BINPREFIX. From what you have written so far, however, I
> see
> nothing that would be the equivalent of EXTBINPREFIX.

> Does Nix provide such a path that remains stable across version
> changes?

Yes, but not in the way slashpackage does. Now that I understand what
these constants are for, it's clear that EXECLINE_BINPREFIX and
EXECLINE_EXTBINPREFIX should be defined to point to the same absolute
bin directory of a specific Nix package of execline. This is correct
as far as Nix is concerned: each version of execline will have a
unique EXECLINE_EXTBINPREFIX, and each version of s6 will point to one
unchanging version of execline. (Note I use "version" in the Nix
sense of the hash of a package's source code and a hash of all its
build and run time dependencies, not in the sense of the version
number of s6.)

In fact, I already do exactly this at the point where s6-log invokes
execlineb. It's just that the issue is larger than I had realized at
that time.

(In Nix, it isn't allowed to mutate the dependency tree in the way
that /package/admin/s6/command/s6-svc might point to different
versions over time. This is one of the tradeoffs in Nix; a given
immutable
package points to the same immutable dependencies, including any libs
and libc, for all time.)

> I'm very much unwilling to lift a finger to support ones that manage
> to be even more idiotic than FHS. I'm on vacation right now, so I'm
> not going to do the accurate research to know what side Nix falls
> into - not before a couple weeks at least - but if you're doing it,
> I'm interested in the result. :)

Ha ha. No worries, Nix definitely does things (very, very) differently
than FHS or most other package managers (it shares some goals with
slashpackage, perhaps). In my opinion, the benefits outweigh the
tradeoffs of being different, but I'm not here to advocate Nix, just
trying to correctly package s6 et. al.

Thanks,
Patrick
Received on Wed Aug 03 2016 - 02:08:17 UTC