Re: [gentoo-dev] Pending Removal of $KV

[John Mylchreest]

On Tue, Jun 20, 2006 at 02:32:36PM +0200, "Kevin F. Quinn" <kevquinn@g.o> wrote:
> > >>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.

Firstly, thanks for using it :) 

If you have any suggections (speculating based off the "Almost" part please 
feel free to talk to me about them and I'll see what I can do :)


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

Additional to this linux-info is close to useless outside of an
available linux-source tree. We do provide an interface which should
very very rarely be used for running kernels get_running_version() and
in this case I can see why the source-tree can be dropped, but I dont
plan on doing so any time soon.

Really this all stems back to gentoo policy regarding building/testing
against kernel srctree/objtree which is as simple as anything
requiring or depending on kernel sources should always use those which
are pointed to by the "/usr/src/linux" symlink. This enabls us to build
packages against a target, rather than current. Cross-compiling would be
a nice example here.

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

They can optionally be non-fatal, and you can also call the API directly
and handle it as required.

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

I've tried to clarify my point fairly well above, but the dependancy is
fairly strict by design. What in linux-mod except for my specific
example above would continue to work if there were no kernel sources
present? (I do of course know the answer but its rhetorical)

To that end is the reason why the dependancy still exists. That said,
I'm open to persuasion.

- John

-- 
Role:            Gentoo Linux Kernel Lead
Gentoo Linux:    http://www.gentoo.org
Public Key:      gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515