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

Domen Kožar domen at dev.si
Mon Jun 6 14:59:39 CEST 2016


We really need a construct to validate if path exists at build time. ${
opelnssl.lib => /mylib.so }

On Mon, Jun 6, 2016 at 1:57 PM, Bjørn Forsman <bjorn.forsman at gmail.com>
wrote:

> On 6 June 2016 at 12:17, Profpatsch <mail at profpatsch.de> 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?
>
> My (crazy) idea to improve this is "hierarchical Nix store paths",
> which I posted here:
>
> http://comments.gmane.org/gmane.linux.distributions.nixos/20421
>
> The idea is that if you refer to ${pkg}, you get the whole output. But
> if you refer to ${pkg.bin.some-exe} you get that path (guaranteed),
> and Nix is able to garbage collect the rest of ${pkg}, unless
> something _else_ refers to anything in that output tree.
>
> I don't really know Nix though, and that idea might very well be
> impossible to implement. I just feel that the current multiple-outputs
> system doesn't scale well, there is no way to create really fine
> grained (sub)packages with it. So I had to post the idea.
>
> Best regards,
> Bjørn Forsman
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160606/d952aa72/attachment.html>


More information about the nix-dev mailing list