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)?


-- mailing list

Reply via email to