On Mon, 19 Jun 2006 13:38:49 +0000
Alec Warner <[EMAIL PROTECTED]> 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...)

Which is broken, since there's no guarantee that's where the built
kernel is.

> >>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.

Yes please.  linux-info.eclass is great; does (almost) exactly what
should be done, i.e. depend on user-supplied kernel source & object
locations.

> >>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.

I do agree virtual/linux-sources shouldn't be a dependency.  The
ebuilds should depend on the existence of the kernel sources or
objects against which the package will be built, which can only be
detected in pkg_setup.  To this end I think DEPEND should not be set in
linux-info.eclass.

> 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.

I think it's wrong for ebuilds to refuse to build if support is missing
from the build system kernel.  ebuilds should not be using the
configuration of the build system to decide whether to build pieces for
the target system (such decisions should be made via USE), and
certainly shouldn't die if run-time support isn't built on the build
system (unless the support is actually needed for the build process
itself, such that the build would fail).  With linux-info.eclass you can
specify the location of the kernel tree to build against
(KBUILD_OUTPUT) and thus build for different kernel configurations as
appropriate (the default being the build system kernel, which makes
things simple for the common case where the target is the build system).

In summary, I agree that $KV should disappear from portage, and that
anything that depends on kernel configuration should use
linux-info.eclass.  Also I'd like to see the dependency on
virtual/linux-sources removed from linux-info.eclass.

-- 
Kevin F. Quinn

Attachment: signature.asc
Description: PGP signature

Reply via email to