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