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

[Michael Raskin]

<E1Qy7ah-0002Y4-00.7c6f434c-mail-ru at smtp6.mail.ru>
<E1QyOjz-0005ym-00.7c6f434c-mail-ru at smtp1.mail.ru>)
Mime-Version: 1.0
Content-type: text/plain; charset="UTF-8"

> >> Eventually, you decide that the new glibc is stable, and then you
> >> run "git merge stdenv/glibc" on whatever happens to be your
> >> equivalent of the official master branch, and then you push the
> >> changeset upstream, which effectively makes them "stable" for
> >> everyone.
> >
> > Right, and the "make" change keeps hanging. So we are worse off than
> > now, because we get two stdenv rebuilds.
>
>actually, it's exactly the opposite. We are better off because we have
>significantly reduced the amount of inference between changes to GNU
>Make and changes to GNU libc.
>
>When the glibc update has been pushed, those changes become "stable" or
>"official" or however you want to call it, meaning that those changes
>are going to be propagated into all active stdenv/* topic branches,
>where the people working on those branches can address problems the
>glibc update might cause locally. If all these changes were to occur in
>a single branch, then those changes would constantly interfere with each
>other, causing lots and lots of unnecessary re-builds and making
>everyone's live much harder.

"Everyone" is using trunk on the computers which they expect to work.

So two stdenv rebuilds where one would work is an annoyance.

The changes from glibc and from make would interfere once. We would 
rebuild make, then learn to build glibc with new make (we have to do
this anyway), then make and glibc are quite likely not to change. 

Solutions to many problems with updates often include updating the 
offending packages to get upstream fixes. 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.

And, by the way, if updating a package to a new-and-shiny version which
boasts "fixed problems with fresh glibc" also requires fresh gcc, won't
it lead either to consiously breaking trunk or to making glibc-updates 
branch closer to stdenv-updates anyway? Updating GNU TLS to 3.0 seems to
make need GTK+-3.0 packages for glib-networking to work. It is just a
fresh example...