On Wed, Aug 03, 2016 at 08:59:40AM +0200, Laurent Bercot wrote:
> 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
Yes.
> 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.
I'll hopefully have time to work on this in the coming days. Not sure what best
to call the option. --enable-nix seems too specific. The Guix packager may not
realize it yet, but Guix needs this option as well (it is based on Nix).
Options, none of which I particularly like:
--enable-immutable
(in any/all package managers, the packages are already immutable; in Nix,
it's the dependency graph that's immutable as well...)
--enable-immutable-system
(somewhat more accurate, but a bit of a mouthful, and obscure)
--enable-binprefix-is-bindir
(more accurate, but possibly too narrow, since extbinprefix, libexecprefix,
shebangprefix would all be set)
Or possibly provide options to set --binprefix and related directly, though
that is a bit cumbersome, and there may not be a use case to set them
individually (rather than to set them as a group to satisy Nix or
slashpackage).
> 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?
Each package in Nix lives in its own directory. To "install" a package is to
symlink its directories into a tree of symlinks called a "profile". Typically
one sets one's PATH to include ~/.nix-profile/bin. Any package's libexec dir
would be linked to ~/.nix-profile/libexec, but not present in PATH. A package
that isn't "installed" in any profile may still be present as a dependency of
another package. In most cases then, the correct way to invoke binaries is via
the immutable path directly into that package's dir (e.g.
/nix/store/${somehash}-somepackage/libexec/command).
> I shiver at the thought of what Nix must do with shared libraries -
> ...
> hardcoded absolute rpaths at compile-time (maybe a tiny bit less brrrr).
This one. They even provide the patchelf[1] command to force this for binaries
whose source is not available.
[1]
http://nixos.org/patchelf.html
> 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.
Nix's default is actually to configure with --disable-static, though I have
disabled that for skarnet packages.
> Maybe even --enable-static-libc if you package musl too. :)
I've not looked into what it takes to build against musl, but would be an
interesting option.
-Patrick
Received on Sat Aug 06 2016 - 03:34:26 UTC