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

[Tomasz Czyż]

Personaly, I was a little tired with repatching 3rd party binaries and I
linked ld-linux-x86-64.so to /lib and /usr/lib (where most apps looks for
this).

One time I even linked /usr/lib and /lib directly to
/run/current-profile/sw/lib and even have got working some non static
binaries :-) (but that's evil, don't do that :-))

2016-08-24 20:24 GMT+01:00 Vladimír Čunát <vcunat at gmail.com>:

> 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
>
>
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>


-- 
Tomasz Czyż
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160824/3cf6f120/attachment-0001.html>