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?
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?
> Hm, I'll have to think about this some more. I'd rather not introduce
> package-manager-specific special cases if it can be avoided...
I don't mind adding support for various file hierarchy organizations
as long as they provide the required functionality, i.e. guaranteed
absolute BINPREFIX and EXTBINPREFIX. Slashpackage is good, but it's
only being used by the few people in the world who are as crazy as I am;
I'm not fixated on slashpackage, but on the guarantees it provides, so
I'm interested in supporting real-world initiatives that achieve the
same benefits.
>> If Nix's policy is to provide "standard" wrappers for every binary
>> in a package, then it is definitely broken.
> It's not policy; it's just an available technique that works without
> requiring any changes to the executable being invoked.
Except it does *not* work. IIUC what it does, what it ends up achieving
is providing a different PATH to every executable it's running; this goes
against standard Unix usage, and may very well work by luck most of
the time because there aren't too many cross-package dependencies,
but it will not work in all cases, and in s6's case it will definitely
break. skarnet.org packages rely on either guaranteed absolute paths
(including nonversioned ones), or a stable cross-package PATH; if Nix
can't provide either, then Nix is broken.
> Generally I'd
> prefer patching things so that executables are invoked via absolute
> path.
It doesn't sound like there's much of a choice here anyway - but note that
just as I'm willing to upstream patches that add support for file hierarchy
policies that work, 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. :)
--
Laurent
Received on Tue Aug 02 2016 - 18:56:42 UTC