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 ;-)
\____________________________________