On 08/24/2016 05:51 PM, Nick Sabalausky wrote: > Also, kind of related: When a package does depend on an older version of > itself in order to be built from source, what is the nix way of going > about that? > > Ie: Suppose building package foobar v3.0 depends on foobar v2.0, and > building foobar 2.0 depends on foobar v1.0. > > Would there be separate packages "foobar1, foobar2, and foobar3" with > foobar3 set to depend on foobar2, etc? But then wouldn't that lead to a > conflict when trying to build/install foobar v3.0 while foobar v2.0 is > already installed (since it needed to be installed in order to build v3.0)? > > Or would the nix expression for foobar v3.0 not *formally* depend on the > older packages and just simply *internally* download/build v1, then v2, > then v3? But then down the road, wouldn't that eventually severely bloat > build times for the latest versions?
We do have some packages that require a binary version to bootstrap itself - often compilers, e.g. gcc, ghc, etc. The dependency would be build-time only, so most people get the final binary directly from Hydra and never see the older one. Conflicts: you have to realize that building a package doesn't normally put it into any visible/conflictable place - it's just a path in /nix/store/something. If the user *explicitly* asked to put multiple versions into a single environment (via nix-env -i or systemPackages), there would be a conflicting bin/foo most likely, but people typically don't need that... --Vladimir
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
