[Nix-dev] Splitting packages silently breaks a lot of stuff

Kevin Cox kevincox at kevincox.ca
Mon Jun 6 14:34:35 CEST 2016


On 06/06/16 06:17, Profpatsch wrote:
> In the past month or so more and more packages have been
> split into multiple outputs. I like that, but:
> 
> Doing so breaks lots of dependencies silently.
> 
> I think that is a very bad problem we need to address.
> Every program with runtime dependencies does build just
> fine, but breaks once its executed.
> 
> Two solutions I can think of:
> 1. Programs can assert *files* they depend on directly in the
>    nix expression and nix ensures these exist on build time.
> 2. Don’t use the first element in the `outputs` list by default.
>    Default to a derivation of *all* outputs if no output is given
>    by name.
> 
> 1 might be hard to implement (afaik aszlig tried something in that
> direction) and still breaks old packages that are not updated.
> 2 will un-break all packages again and they need to be patched to
> get the closure size down again.
> 
> Thoughts? Anything I’ve missed?
> 


I had this same thing happen to me. I updated my NixOS and my script
that used the OpenSSL binary stopped working.

1. This would be interesting. Currently the pattern is ${pkg}/bin/exe. I
think if we could abstract that the checking could be automatic.

2. I think this train of thought more but unfortunately there is no
"all" output anymore. So you would still have to reference the right one.

Also it appears that in general the `lib` is the default output. It
seems to me like the `bin` is more useful as that is what humans would
reference more. Where as the `lib` output is used more in other build
scripts and errors would be thrown if the library isn't found.

I'm giving a definite +1 to figuring out how to reduce this breakage.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
URL: <http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160606/6ff90b9b/attachment.sig>


More information about the nix-dev mailing list