Re: [RFC] Kernel version numbering scheme change
From: Adrian Bunk
Date: Sat Oct 18 2008 - 09:49:01 EST
On Sat, Oct 18, 2008 at 02:28:51PM +0200, Willy Tarreau wrote:
> On Sat, Oct 18, 2008 at 02:50:38PM +0300, Adrian Bunk wrote:
> > > > Scratchbox , e.g. used for building the software in Nokias Internet
> > > > Tablets  or the ARM Linux Internet Platform , is a chrooted
> > > > cross-compilation environment.
> > > >
> > > > Yes, it works.
> > >
> > > I'm not saying it does not work, I'm saying it's far from being practical
> > > when you want to support multiple architectures or targets, and that it
> > > will do nasty things under you without letting you know.
> > Scratchbox easily allows switching between targets, no matter which
> > architectures they are for.
> > Can you describe the problems you have experienced more precisely?
> Adrian, don't try to make me look like dumb by asking for specific
> problems. Problems range from auto-detection of kernel version to
> enable or disable feature X or Y,
Works inside Scratchbox.
> to endian detection and bit width
Works inside Scratchbox.
> detection. If you don't believe me, it's just that you're used to
> build completely OS-agnostic packages,
That's completely wrong.
> which is perfectly fine, but
> that doesn't seem to be completely the case given that you're feeling
> you will get annoyed by breaking the openssl BUILD environment if
> you make it run on a different kernel. *That* is the funny part,
> since this build environment should not even require to run on Linux
> at all!
10 years ago someone wrote his own version of config.guess, and assumed
kernel developers would always use sane versions.
This doesn't make it Linux-specific.
> > > A build environment is what it is, a build environment. It contains
> > > compilers, shells to run scripts, various interpreters and build tools,
> > > possibily debuggers and editors, versionning systems, etc...
> > The build environment in the chroot is the correct release.
> No it isn't because you're saying that some of the packages check for
> kernel version which is not the right one. So if you move your chroot
> to another machine, it is susceptible to break because it relies on
> the host's kernel version. So your chroot is not your build environment,
> it's just part of it.
The version is one of the few things the kernel leaks inside a chroot.
> > > > Userspace ABIs of the kernel are usually stable.
> > >
> > > Yes but they are not necessarily forward-compatible. If openssl believes
> > > some feature is present in 2.6.521 because 521 is bigger than 233, you
> > > will build a broken package which will not work with any distro running
> > > your long-term 2.6.27 which does not have the feature introduced in .233.
> > I already addressed this previously in this thread:
> > I'm not even sure whether OpenSSL actually does anything with the
> > information: The script comes from the Apache foundation and
> > claims to be "Similar to config.guess but much, much smaller."
> You addressed it only for openssl and apache 1.3, that you used as
> examples to object to a change of changing kernel version numbering
> scheme. So do you have other examples of packages like this which
> might break and might be more sensible to build environment's kernel
> version ? Because if only apache 1.3 and openssl 0.9.8g are sensible,
> the fix will be really quick using something like this in your build
> scripts and makefiles :
> And BTW, if your build environment mimmics so well the target except
> for uname, let's fix its uname tool to reflect the target version !
The problem has nothing to do with any build environments or chroots.
A "just for fun" change of the version number will break existing
programs, and that will cause various problems for various people.
> > > And when
> > > you know how to fix packages so that chroot is not a problem, then you
> > > know how to fix the package not to require a chroot.
> > That's complete bullshit:
> > Packages do not require fixes for being built inside a chroot.
> > Given:
> > - some software package of a foobar program
> > - Scratchbox on an x86 host
> > - an ARM target that mounts the target filesystem from the host
> > host # ./configure && make && make install
> > target # foobar
> > The build system of the software thinks it gets built on the target
> > architecture.
> Quite cool stuff, but I'm really not interested. Having been beat by
> a number of packages which try to run target environment commands
> during the build when not set for cross-compile, I'd expect pretty
> random results.
The build system of the package thinks it gets compiled natively - that
avoids exactly the problems you describe.
And trying to run a target binary when building on the host *does work*
inside Scratchbox. Please *read* what I wrote directly below:
> > And due to transparent usage of qemu or sbrsh it also works when the
> > package uses a program built for the target during the build.
> > No matter whether the build system of the package knows anything about
> > cross-compilation.
"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/