[Nix-dev] Re: Please update of stdenv-linux tarballs

[Lluís Batlle i Rossell]

On Mon, Nov 01, 2010 at 11:09:27PM +0100, Peter Simons wrote:
> Hi Ludovic,
> 
>  > As for the broken Red Hat kernel, I think it’s great if Nixpkgs can
>  > support it, but only if that’s not too much of a maintenance burden;
>  > the primary target should remain NixOS, and then distributions that
>  > ship (almost) unmodified upstream software.
> 
> as it is right now, Nix doesn't support Red Hat's broken kernel,
> because the current bootstrap tools use a glibc newer than 2.5
> already. That issue is not a big deal, though, because the kernel in
> question is quite old and chances are slim that many people still use
> it today.
So do you have problems running the bootstrap-tools of nixpkgs trunk?

> What concerns me is not so much that particular bug. I am concerned
> about the bugs that might be discovered after that update has been
> merged. The bootstrap tools are a single point of failure for new
> users who'd like to try out Nix. If Nix can't bootstrap itself, then
> there's not much anyone can do with it. You or I or anyone else on
> this list can work around such a problem, but new users will have
> neither the knowledge nor the incentive to do so. This situation gives
> us an incentive to provide bootstrap tools that are very reliable --
> after all, we want Nix to be used!
I agree.

> In my humble opinion, a sensible guideline would be that bootstrap
> tools are not supposed to be modified unless they have to be.
I agree, but it is not much about having *old* bootstrap-tools, but a whole
bootstrap-procedure that allows running old *kernels*. And old kernels does not
necessarily mean old userland code.

> Now, I understand Lluís needs the latest binutils in bootstrap tools.
> That is a perfectly legitimate interest, and I am all for it. I wonder
> about the update to glibc 2.12.1, though. Is that really necessary to
> support loongson2f?
No, the glibc 2.12.1 was not necessary. I only needed a gcc newer or equal than
4.4, and we had 4.3 there. I put glibc 2.12.1 because at the time of rebuilding
the bootstrap-tools, I took the gcc there (4.5.1, instead of the minimum I
required), the glibc there (2.12.1) and the binutils there (the snapshot, not
part of an official release). And the same for the rest of the software there.

When we build glibc, we build it with specific linux headers. This is what links
the userland code with the system calls of one kernel or another. This time I
had used the headers for 2.6.32. In the previous bootstrap-tools we had glibc
built with 2.6.28 (> 2.6.25 for sure, I'd have to double check for 2.6.28).

I think that maybe the trouble we have with that CentOS is that we build glibc
with too new linux-headers, and for the bootstrap-tools we may have to use some
much older headers, as linux tries to be backwards-compatible on syscalls not
not forward-compatible. I'd like to confirm if that is the CentOS problem you
are experiencing. I still doubt the problem is related to one glibc version or
another, and I'll keep on doubting unless more evidences come into play.

So, I agree on having a 'better' bootstrap procedure that would allow nix users
to run nix built software in their old kernels. This not necessarily goes *only*
to having bootstrap-tools that can run on old kernels. We need to redefine the
stdenv boostrap, and more importantly, maybe we have to allow choosing the linux
headers the users want to use. As the linux-headers are part of the stdenv, this
will end up with hydra building packages for some specific linux kernels.

What I propose now is... for the known problematic cases we have (Peter with
CentOS), the new situation in nixpkgs stdenv-updates (the bootstrap-tools I
used) does not make things worse than in nixpkgs trunk. Peter, correct me if I
am wrong. So, as now we have quite stable stdenv-updates, and we are trying to
get the merge to trunk since some weeks ago, I propose to merge that in.

I have two slow platforms running nixos-stdenv-updates, one of them (mips) not
having any support in nixpkgs trunk, and noone is building packages for me. It
takes four days of rebuilding nixos at every stdenv-updates stdenv change.
Another nixos user is running nixos on mips with stdenv-updates code too.
So if the merge to trunk will not set the situation worse for your case, Peter,
I propose your case not to be a stopper for this merge. On the other hand, after
the merge I and another nixos user will be able to run nixos with nixpkgs trunk,
and we will be able to do the kind of play needed to get nixpkgs working fine in
that CentOS system.

Do you agree?

Regards,
Lluís.