[Nix-dev] Generating nixos-compatible binaries? And bootstrapped packages.

[Vladimír Čunát]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3771 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160824/61c88310/attachment.p7s>