lkml.org 
[lkml]   [1996]   [Jul]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: No Distribution is 2.0.0 Current
I'm afraid this message goes on at some length, but I do feel that we
still have a misunderstanding here. I don't feel that I've yet
managed to get across what I wanted to say to Alan ...

Stephen Masterman writes ("Re: No Distribution is 2.0.0 Current"):
> > [Ian Jackson:]
> > > Surely this is missing a fundamental point: we, the Debian project,
> > > have to ship binaries that will work on everybody's system, so that
> > > our users can use the kernels that they choose.
> >
> [Alan Cox:]
> > Which is missing the fundamental point that everyone else writes their stuff
> > to detect 1.2/2.0 by kernel headers so a build does produce the right
> > binaries.
>
> I don't know much about this stuff, but you two don't seem to be
> talking about quite the same thing. [Alan] is saying that everyone
> else writes stuff which detects, at build time, whether the system
> has 1.2 or 2.0 kernel headers. But [Ian] is saying that Debian has
> to distribute binaries, which are already compiled with either 1.2
> or 2.0 or x.x kernel headers, but which are to be useable on many
> systems - after all, not every debian user compiles his own binaries
> for every package.

Thanks, that's exactly my point.

Alan Cox writes ("Re: No Distribution is 2.0.0 Current"):
...
> Linux 1.2 is almost 100% BINARY compatible with 2.0. A lot of stuff is
> designed to detect 2.0 kernels and build appropriately.

I don't understand this point at all. Surely the problems with using
old kernel headers to compile binaries are exactly the same as just
using old binaries compiled with then-recent but now-old kernel
headers ?

Therefore if it's almost 100% binary compatible it'll be almost 100%
kernel-header compatible, too.

> > Surely this is missing a fundamental point: we, the Debian project,
> > have to ship binaries that will work on everybody's system, so that
> > our users can use the kernels that they choose.
>
> Which is missing the fundamental point that everyone else writes their stuff
> to detect 1.2/2.0 by kernel headers so a build does produce the right
> binaries.

What does `right' mean ? Corresponding to the system where the
binaries are built, or the one where they are to be used ? I think
the former definition of `right' is unhelpful - most users nowadays
run binaries built by other people. If it's the latter then how does
having the person who builds the binaries having more recent headers
help ?

...
> > A Linux distribution is a very large piece of software engineering,
> > and comes is a point where expecting its maintainers to play
> > `catch-up' continuously with new and sometimes-incompatible kernel
> > interfaces is unreasonable.
>
> Yes. I can see where you came from. But for network stuff because we now
> support IP options and kernel recvmsg/sendmsg, BSD 4.4 unix fd passing etc
> the interfaces have subtle shifts. The alternative was to stand still and
> keep poorer systems.

I'm not saying you should keep the interface frozen. I am saying that
you have to have a transition plan. Old binaries have to continue to
work on new kernels, and new binaries built from sources which
autodetect new kernel features at build-time should not die horribly
when they're run on old kernels.

For this reason it is much less critical than it used to be (in the
days before we were trying to do release engineering) which kernel
headers are used when a binary is built.

It is for us much more important that ordinary compilations continue
to work and produce correct binaries using a known stable interface
even when the user (or distribution developer, in many cases) wants to
use more recent kernels (than perhaps all their users can be expected
to).

Ian.


\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.059 / U:0.968 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site