Alec Warner wrote:
Georgi Georgiev wrote:
maillog: 19/06/2006-11:13:33(+0000): Alec Warner types
Portage currently exports $KV as the current kernel version. We
detect this by attempting to mess around with the things in
/usr/src/linux (.config, make files, etc...)
This is duplicating the superb efforts of the kernel team and of
linux-info eclass. As such I would like to deprecate $KV in favor
of using linux-info eclass. I don't see the need for portage to
export $KV into the environment for all packages.
There are a few packages left that use this. There will be a
tracker bug shortly. Mostly this mail is just a heads up ;)
But any kind of checks against something in $KERNEL_DIR are just wrong,
wrong, wrong. The only exception being when the ebuild is building
something *against* those sources (kernel modules, and that's it).
It's annoying to have virtual/linux-sources pulled as a dep of gnupg,
iptables or any other package that can do fine without them.
In many cases those packages are looking for a specific kernel feature
to make sure support is enabled for it.
You could argue that in the case where you aren't compiling against
the kernel that support being enabled isn't critical, but that is a
discussion you need to have with the package maintainers.
Hmmm....I don't know about this, since I'm jusr a user without much
programming experience, and haven't developed anything that makes use of
kernel features, but If they don't actually build against the kernel,
couldn't/shouldn't they look at either kernel-headers or the output of
`uname -r` (possibly with a way to force the feature on if the user
knows it's available but the build system isn't detecting it)?
--Arek
--
gentoo-dev@gentoo.org mailing list
