Pjotr Prins writes: >> The entire situation is a bit of a mess. > > And it will re-occur. [...]
This problem occurred by mistake. People make mistakes. So, yes, those kind of problems will re-occur. But it's not correct to imply that this problem is in any way specific to Nix. All software that is supposed to run on a Linux x.y.z kernel must be configured with x.y kernel headers. The last digit, however, is supposed to be insignificant. This policy was broken by an unfortunate interaction of unwise decision by Red Hat (because they ship broken kernels), glibc (because they stubbornly refuse to work around broken kernels like Red Hat's), and coreutils (because they release software that uses brand-new features without implementing fallback behavior). There are many different parties involved in this situation, but Nix is not one of them. Nix just happens to run into this problem first because the distribution comes with bleeding-edge packages. > I think the only solution is to build packages against specific > kernel versions and their headers. So if my Debian runs Linux 2.6.8 I > should compile against the headers of 2.6.8. It's fair to say that this approach would reduce the likelihood of kernel/userland inconsistencies, but it's certainly not "the only solution". Some people would argue that this is no practical solution at all, because they don't want to re-compile their entire system after upgrading from Linux 2.6.21 to 2.6.22. Besides, it's unclear how this approach would work in the presence of multi-boot systems that can run different kernels, etc. All in all, I feel that we have other, better solutions available. Take care, Peter _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
