Re: Set binprefix when not using slashpackage

From: Patrick Mahoney <>
Date: Fri, 5 Aug 2016 22:34:26 -0500

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


> 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:

    (in any/all package managers, the packages are already immutable; in Nix,
    it's the dependency graph that's immutable as well...)

    (somewhat more accurate, but a bit of a mouthful, and obscure)

    (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

> 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.
> 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.


> Please tell me
> you will --enable-static when compiling 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.

Received on Sat Aug 06 2016 - 03:34:26 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:38:49 UTC