[Nix-dev] Re: new possible movement to git (?)

[Michael Raskin]

<87ei03aw6p.fsf at write-only.cryp.to>
<E1QyQ0P-0003fq-00.7c6f434c-mail-ru at smtp15.mail.ru>)
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.