[gentoo-dev] Ebuilds referencing /usr/src/linux makes baby Jesus kill kittens

[gentoo-dev] Ebuilds referencing /usr/src/linux makes baby Jesus kill kittens

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1566 bytes --]

Just a friendly reminder that you should really avoid messing around
with /usr/src/linux inside ebuilds. In particular, code like the
following is utterly wrong:

if [ ! -e "/usr/src/linux/include/linux/dm-ioctl.h" ] ; then
        eerror
        eerror "Your currently linked kernel (/usr/src/linux) hasn't"   
        eerror "been patched for device mapper support."               
        eerror
        die "kernel not patched for device mapper support"       
fi

Don't try to do clever things with /usr/src/linux to determine whether a
kernel has a particular feature. Especially don't go near .config. The
kernel running may not be the kernel in /usr/src/linux. The box in
question might be a chroot setup or a netboot system or a system built
with a crosscompiler, in which case /usr/src/linux* won't exist at all.
The user might be sharing kernel binaries between dozens of identical
boxes and only building on one. The user might be building kernels
in/home to avoid having to build kernels as root or chown a bunch of
stuff. The /usr/src/linux symlink might be out of date. The box might be
building binary packages for a different system.

You shouldn't be using /usr/src/linux for headers either. I suggest
people give the following a good read before they commit even more
broken code to the tree:

http://www.linuxmafia.com/faq/Kernel/usr-src-linux-symlink.html

Think of the kittens, people!

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Ebuilds referencing /usr/src/linux makes baby Jesus kill kittens

[Donnie Berkholz]

Ciaran McCreesh said:
> Just a friendly reminder that you should really avoid messing around
> with /usr/src/linux inside ebuilds. In particular, code like the
> following is utterly wrong:
<snip>
> Don't try to do clever things with /usr/src/linux to determine whether a
> kernel has a particular feature. Especially don't go near .config. The
> kernel running may not be the kernel in /usr/src/linux. The box in
> question might be a chroot setup or a netboot system or a system built
> with a crosscompiler, in which case /usr/src/linux* won't exist at all.
> The user might be sharing kernel binaries between dozens of identical
> boxes and only building on one. The user might be building kernels
> in/home to avoid having to build kernels as root or chown a bunch of
> stuff. The /usr/src/linux symlink might be out of date. The box might be
> building binary packages for a different system.

Just a friendly response that kernel modules should build based on
${ROOT}/usr/src/linux and not on the running kernel. Also other things
that require a kernel should be using that symlink rather than the running
kernel. That's how it's been in Gentoo in the past. The rationale is the
ability to build things for a (or multiple) non-running kernel(s).

The FAQ to which you refer only talks about not using the symlink for your
headers, which is an entirely different thing from what I'm getting at.

Donnie



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds referencing /usr/src/linux makes baby Jesus kill kittens

[Mike Frysinger]

On Friday 23 July 2004 06:22 pm, Ciaran McCreesh wrote:
> Just a friendly reminder that you should really avoid messing around
> with /usr/src/linux inside ebuilds. In particular, code like the
> following is utterly wrong:
>
> if [ ! -e "/usr/src/linux/include/linux/dm-ioctl.h" ] ; then

the only packages that should poke around /usr/src/linux/ are kernel module 
packages ... and like donnie said, using ${ROOT}/usr/src/linux/ is ok

> You shouldn't be using /usr/src/linux for headers either. I suggest
> people give the following a good read before they commit even more
> broken code to the tree:

agreed, headers should be taken from the system
-mike

--
gentoo-dev@gentoo.org mailing list