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

Reply via email to