| 1 |
On Mon, 19 Jun 2006 13:38:49 +0000 |
| 2 |
Alec Warner <antarus@g.o> wrote: |
| 3 |
|
| 4 |
> Georgi Georgiev wrote: |
| 5 |
> > maillog: 19/06/2006-11:13:33(+0000): Alec Warner types |
| 6 |
> > |
| 7 |
> >>Portage currently exports $KV as the current kernel version. We |
| 8 |
> >>detect this by attempting to mess around with the things |
| 9 |
> >>in /usr/src/linux (.config, make files, etc...) |
| 10 |
|
| 11 |
Which is broken, since there's no guarantee that's where the built |
| 12 |
kernel is. |
| 13 |
|
| 14 |
> >>This is duplicating the superb efforts of the kernel team and of |
| 15 |
> >>linux-info eclass. As such I would like to deprecate $KV in favor |
| 16 |
> >>of using linux-info eclass. I don't see the need for portage to |
| 17 |
> >>export $KV into the environment for all packages. |
| 18 |
|
| 19 |
Yes please. linux-info.eclass is great; does (almost) exactly what |
| 20 |
should be done, i.e. depend on user-supplied kernel source & object |
| 21 |
locations. |
| 22 |
|
| 23 |
> >>There are a few packages left that use this. There will be a |
| 24 |
> >>tracker bug shortly. Mostly this mail is just a heads up ;) |
| 25 |
> > |
| 26 |
> > |
| 27 |
> > But any kind of checks against something in $KERNEL_DIR are just |
| 28 |
> > wrong, wrong, wrong. The only exception being when the ebuild is |
| 29 |
> > building something *against* those sources (kernel modules, and |
| 30 |
> > that's it). |
| 31 |
> > |
| 32 |
> > It's annoying to have virtual/linux-sources pulled as a dep of |
| 33 |
> > gnupg, iptables or any other package that can do fine without them. |
| 34 |
|
| 35 |
I do agree virtual/linux-sources shouldn't be a dependency. The |
| 36 |
ebuilds should depend on the existence of the kernel sources or |
| 37 |
objects against which the package will be built, which can only be |
| 38 |
detected in pkg_setup. To this end I think DEPEND should not be set in |
| 39 |
linux-info.eclass. |
| 40 |
|
| 41 |
> In many cases those packages are looking for a specific kernel |
| 42 |
> feature to make sure support is enabled for it. |
| 43 |
> |
| 44 |
> You could argue that in the case where you aren't compiling against |
| 45 |
> the kernel that support being enabled isn't critical, but that is a |
| 46 |
> discussion you need to have with the package maintainers. |
| 47 |
|
| 48 |
I think it's wrong for ebuilds to refuse to build if support is missing |
| 49 |
from the build system kernel. ebuilds should not be using the |
| 50 |
configuration of the build system to decide whether to build pieces for |
| 51 |
the target system (such decisions should be made via USE), and |
| 52 |
certainly shouldn't die if run-time support isn't built on the build |
| 53 |
system (unless the support is actually needed for the build process |
| 54 |
itself, such that the build would fail). With linux-info.eclass you can |
| 55 |
specify the location of the kernel tree to build against |
| 56 |
(KBUILD_OUTPUT) and thus build for different kernel configurations as |
| 57 |
appropriate (the default being the build system kernel, which makes |
| 58 |
things simple for the common case where the target is the build system). |
| 59 |
|
| 60 |
In summary, I agree that $KV should disappear from portage, and that |
| 61 |
anything that depends on kernel configuration should use |
| 62 |
linux-info.eclass. Also I'd like to see the dependency on |
| 63 |
virtual/linux-sources removed from linux-info.eclass. |
| 64 |
|
| 65 |
-- |
| 66 |
Kevin F. Quinn |
Archives