<[email protected]> <[email protected]>) Mime-Version: 1.0 Content-type: text/plain; charset="UTF-8"
> > Two stdenv rebuilds where one would work is an annoyance. > > Your way supposes trying to build them with just new glibc, and then > > trying to build them with new glibc and make. It doesn't look like > > this approach would reduce rebuilds. >my impression is that we approach the question at hand using different >priorities. You seem to be concerned mostly with Hydra, i.e. you argue >that policies should be designed so that Hydra is happy, whereas I am >concerned with people, i.e. I argue for policies that simplify >development -- even if this means that Hydra has to perform builds that >could theoretically have been avoided. Well, I'd say that I care more about people using Nix, because usually I use way more packages than dependencies of any given package (which I would rebuild while developing a package). Also, not everything I use is built by Hydra... Also, looks like state of the affairs in the parts of Nixpkgs we work on is too different. I could look for some examples where updating sanely meant simply updating everything first and sorting things out later; there obviously are some updates where knowing whether new glibc or new gcc breaks the build helps. I guess getting any numbers would be hard. >Under those circumstances, I don't see how we could agree, so I suggest >we agree to disagree. Well, I am even more unconvinced - based on my experience with updates, I would prefer stdenv-updates to be unified branch even for the process of fixing the packages. Because easy things are just done and hard things are - in my experience with packaging - usually easy to trace back to single dependency and hard to fix anyway. But you are right, it's not likely that we could find any new arguments. _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
