[Nix-dev] Re: Problem installing vim-7.2-huge-X11-python-tcl.drv

[Pjotr Prins]

On Tue, Aug 12, 2008 at 11:46:19AM +0200, Peter Simons wrote:
> kind of problems will re-occur. But it's not correct to imply that this
> problem is in any way specific to Nix.

I am not saying it is 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. 

Can you point me to that policy. I think for the 2.6 kernels it is
not valid any longer, if it ever was. Linux remains a moving target,
with sometimes major shifts. Fortunately most of the interface to
user land is (normally) rather stable. That is why it usually
compiles.

> 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.

Uhm. That may be one aspect. 

>  > 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.

Multi-boot systems have the same risks. I think we ought not assume,
nor ask for, the Kernel and supporting libraries to be backward
compatible. That is wishful thinking. It is, in fact, surprising how
few times it breaks. A compilation error is actually good. However,
problems may be more subtle and bad when not caught at compile time.
Debian, which I happen to know best, will force upgrades of Kernels
and glibc if there are dependency problems.  Which can be very
annoying, but it is unavoidable for guaranteeing consistency.

> All in all, I feel that we have other, better solutions available.

Which? I am in the dark here.

Pj.