On 2016-08-03 04:08, Patrick Mahoney wrote:
> 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.)
OK, it's very weird and unconventional, but it sounds like it's
possible to make it work - binaries would be Nix-only, and pretty
fragile, but if Nix claims to guarantees the immutability of
cross-package dependencies, then it's on the system, not on the
installed software, to ensure that it keeps working, so it's ok.
A --enable-nix option that would set both BINPREFIX and EXTBINPREFIX
(and stuff like SBINPREFIX) to the same absolute path sounds like the
right thing: if you write a patch that implements that, I'll upstream
it when I get back home.
One more question: how does Nix address unexported binaries? i.e.
binaries that are supposed to be "hidden", only accessible as internal
details of the working of a package, and typically installed under
/libexec on a FHS system? Slashpackage puts them in BINPREFIX and
simply doesn't export them to /command. IIUC, the equivalent in Nix
would be to also put them in BINPREFIX and not generate a wrapper with
an ad-hoc PATH for them. Is that right?
I shiver at the thought of what Nix must do with shared libraries -
either wrappers with LD_LIBRARY_PATH (brrrr) or hardcoded absolute
rpaths at compile-time (maybe a tiny bit less brrrr). Please tell me
you will --enable-static when compiling skarnet.org packages for Nix;
since the dependency tree is immutable, making things as static as
possible and reducing cross-package dependencies sounds like the right
thing anyway.
Maybe even --enable-static-libc if you package musl too. :)
--
Laurent
Received on Wed Aug 03 2016 - 06:59:40 UTC