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
