lkml.org 
[lkml]   [1996]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: No Distribution is 2.0.0 Current
On Tue, 25 Jun 1996, Ian Jackson wrote:
>
> 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.
>
> Furthermore, we have to do this while running all manner of kernels
> ourselves.
>
> If the kernel system call interface has changed in such a way that
> binaries compiled against old kernel headers will do terrible things
> when run on new kernels, or vice versa, then surely this is (a) a
> problem with the kernel developers not thinking enough about backward
> compatibility and (b) not something we can solve by using a particular
> set of headers ?
>

Well expecting this to work over minor releases of stable releases is ok,
but not between stable releases (ie 1.2.x -> 2.0.y), and not through the
devlopment cycle (ie you shouldn't expect that 1.3.1x work with 1.3.9y).
What you should expect to work is the reverse, but only if you use both
new and old headers (ie ... if(kernel_release >= 0x....) { .... } else {
....} ), so you could expect up to date binaries to work with old systems
(ie 2.1.x -> 2.0.y).

> Changes to kernel interfaces breaking the odd program so that they
> need to be upgraded is OK, if something of a pain, but changes which
> make the old programs work but insecurely (for example) are
> pernicious, as are changes which mean that it's impossible to compile
> a program so that it works on both old and new kernels.
>

You have to make newer binaries that work with what has been, not what
will be. Demanding that the kernel interface never change will just
stall development (that's why ksyms exists too ....).

> All of this has little to do with whether we ship a particular set of
> kernel headers with our libc package - in fact, if we were to upgrade
> our libc to contain 2.0 headers then we would at least be able to
> build binaries with 2.0 headers without necessarily requiring all of
> our developers to upgrade to 2.0 simultaneously.
>

Forcing old headers on new compiles is not a good idea ....

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

Well that's obvious, but anything that's radically broken during the
devlopment cycle can be kept up to date (eg procps has been broken a long
time, and should have been (and I hope was) fixed shortly after you hurd
what the exact cause of the problem was). You should idealy keep a set
an up to date source tree of the whole distribution that you can maintain
on a week to week, month to month basis, and not have to do the whole
thing in one go when the next stable kernel is released.

> Expecting the users to know to upgrade everything at once is
> unreasonable too, IMO.
>

Well if your packageing system is up to it, then you don't have to, only
bit's that have changed (ie a package here, a package there during the
devlopment should be more than enough). Huge changes between the code
freeze, and the actual release are unlikly, (assuming it sticks ;).

> Ian.
> (maintainer of dpkg)
>
Bryn
--
PGP key pass phrase forgotten, \ Overload -- core meltdown sequence
again :( | initiated.
/ This space is intentionally left
| blank, apart from this text ;-)
\____________________________________



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