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 <[email protected]> wrote: > On 6 June 2016 at 12:17, Profpatsch <[email protected]> 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 > [email protected] > http://lists.science.uu.nl/mailman/listinfo/nix-dev >
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
