Re: [RFC] Kernel version numbering scheme change

From: Adrian Bunk
Date: Fri Oct 17 2008 - 02:48:18 EST


On Thu, Oct 16, 2008 at 08:47:17PM -0700, Greg KH wrote:
> On Thu, Oct 16, 2008 at 07:46:02PM +0300, Adrian Bunk wrote:
> > On Thu, Oct 16, 2008 at 08:17:48AM -0700, Greg KH wrote:
> > > On Thu, Oct 16, 2008 at 03:49:43PM +0300, Adrian Bunk wrote:
> > >...
> > > > If a distribution will try to autobuild an urgent OpenSSL security
> > > > update for their stable release in a chroot on a machine running
> > > > kernel 2009.2.3 they will surely love you for being responsible
> > > > for this...
> > >
> > > Distros properly patch things and backport "urgent OpenSSL security
> > > updates" to older versions of packages, so they would not run into this
> > > problem.
> >
> > You didn't get my point.
> >
> > Let me make an example:
> >
> > The current Debian release will be supported until one year after the
> > next release gets released.
> >
> > Someone from the Debian security team send a fixed package to the
> > buildds.
> >
> > The buildds build packages in chroots.
> >
> > A buildd may run any Debian release.
> >
> > And it's perfectly normal that a buildd runs a more recent release of
> > Debian than the one a package gets built for in a chroot.
>
> So you are saying the Debian build system would build a package for an
> older release, on a system that is newer,

Packages are built in a chroot with the correct release installed.

> and that build would be
> determining things based on the system it is built on, not what it is
> being built for?

No.

In the example I gave it is OpenSSL that parses the version number of
the kernel.

> If so, then something is very broken already in the Debian build system
> and I think you have much bigger problems to worry about right now.
>
> For all other "sane" build systems that I know of, you build against the
> libraries/kernel/gcc/glibc/etc that you are wanting to support it for,
> not against some random-whatever-happened-to-be-installed-on-the-box.

Building in a chroot is hardly "very broken".

And it does build against the correct
libraries/kernel headers/gcc/glibc/etc .

Did you ever use a chroot?


And this was just one example.

What does userspace with the kernel version returned by GDTIOCTL_OSVERS?
I don't know whether it just displays the number, or whether it
determines anything based on it.

Or what else might parse the version number?

What if some proprietary userspace software like Skype or Flash or
whatever parses the kernel version number at runtime and barfs on
2009.2.3 in a way similar to the OpenSSL build system?

WHAT YOU SUGGEST WILL BREAK EXISTING USERSPACE SOFTWARE.

Please admit this fact.


>...
> Hope this helps,
>
> greg k-h

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/