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. _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
