[gentoo-dev] linux-info.eclass and $CONFIG_CHECK
Georgi Georgiev
kernel configuration options.
Now, packages that install kernel modules, i.e. packages that inherit
linux-mod.eclass are right to check for those options in pkg_setup and
abort unless these are available. After all, these packages are most
often unable to even compile properly without them and they merge
against a particular kernel version. They also require a remerge when
the kernel is changed -- all reasonable.
However, I have a problem with these checks in packages that inherit
linux-info.eclass. With net-dialup/ppp in particular, though there are
others -- cpufreqd for example. So, "emerge ppp" checks if I have
CONFIG_PPP and dies unless this is the case (fact is, the eclass dies
after being unable to find the kernel sources). Naturally the quesiton
WHY comes. ppp does not require recompilation when the kernel changes.
And in my particular case, where I am building binary packages in a
chroot on a completely different machine this check is absolutely
unnecessary. In fact, I have nothing in "world" in that chroot that has
a dependency on the kernel sources.
And last, if all packages that inherit linux-info are going to die with
* Determining the location of the kernel source code
* Unable to find kernel sources at /usr/src/linux
* This package requires Linux sources.
* Please make sure that /usr/src/linux points at your running kernel,
* (or the kernel you wish to build against).
* Alternatively, set the KERNEL_DIR environment variable to the kernel sources location
then the least they can do is depend on virutal/linux-sources so I can
see it coming ahead of time. Of course, I'd then bitch about packages
having an unnecessary dependency on the sources, as they do in fact
compile and merge just fine.
( Shouldn't the BSD teams also care about this? As it is, portage cannot
merge ppp on a *BSD, even though it appears to be supported by the
package itself (well, it needs to patch the BSD kernel, so I guess
nobody would ever try to do it... not a good argument). )
I can only think of a couple of solution:
- Remove these unnecessary checks completely: Follow the example of all
other distributions and do not depend on anything kernel-ish for such
packages. A recompilation of the kernel with different options can
easily cause what the checks are trying to avoid anyway.
- Make the checks in linux-info non-fatal. I.e., don't die but issue
warnings instead. That's the *least* that I'd be happy with.
What do you people think the proper solution is?
--
( Georgi Georgiev ( MSDOS is not dead, it just smells that way. (
) ch...@gg3.net ) -- Henry Spencer )
( +81(90)2877-8845 ( (
Marius Mauch
Georgi Georgiev <ch...@gg3.net> wrote:
> I can only think of a couple of solution:
>
> - Remove these unnecessary checks completely: Follow the example of
> all other distributions and do not depend on anything kernel-ish for
> such packages. A recompilation of the kernel with different options
> can easily cause what the checks are trying to avoid anyway.
>
> - Make the checks in linux-info non-fatal. I.e., don't die but issue
> warnings instead. That's the *least* that I'd be happy with.
>
> What do you people think the proper solution is?
Not much better than your suggestions:
Move the check to pkg_preinst so it's run when the package is merged,
not when build. Of course only if it's not required for compilation.
Has the disadvantage that people who want that check will only see it
after the package is built and will need to rebuild it or run 'ebuild
foo.ebuild preinst qmerge postinst clean'.
Marius
--
Public Key at http://www.genone.de/info/gpg-key.pub
In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.
Paul de Vrieze
>
> * Determining the location of the kernel source code
> * Unable to find kernel sources at /usr/src/linux
> * This package requires Linux sources.
> * Please make sure that /usr/src/linux points at your running kernel,
> * (or the kernel you wish to build against).
> * Alternatively, set the KERNEL_DIR environment variable to the kernel
> sources location
I kindof wonder why it doesn't try the sources of the running kernel. They
are easilly found at "/lib/modules/`uname -v`/build". Of course as a
final result as someone might want to build against different sources,
but it's a better fallback than an error message.
Paul
--
Paul de Vrieze
Gentoo Developer
Mail: pau...@gentoo.org
Homepage: http://www.devrieze.net
Georgi Georgiev
> On Wednesday 21 September 2005 09:42, Georgi Georgiev wrote:
> >
> > * Determining the location of the kernel source code
> > * Unable to find kernel sources at /usr/src/linux
> > * This package requires Linux sources.
> > * Please make sure that /usr/src/linux points at your running kernel,
> > * (or the kernel you wish to build against).
> > * Alternatively, set the KERNEL_DIR environment variable to the kernel
> > sources location
>
> I kindof wonder why it doesn't try the sources of the running kernel. They
> are easilly found at "/lib/modules/`uname -v`/build". Of course as a
> final result as someone might want to build against different sources,
> but it's a better fallback than an error message.
Well, this is not exactly on topic, but packages should not assume they
are compiling against the running kernel (be it a fallback or not).
After a kernel upgrade I usually remerge all the stuff listed in
/var/lib/modules-rebuild/ *before* restarting. There is also a
reasonable workaround -- set KERNEL_DIR to the proper location of the
sources.
However, in my case I do not have the sources anywhere (nor I need them)
and I do not have /lib/modules either.
--
(* Georgi Georgiev (* If it pours before seven, it has rained by (*
*) ch...@gg3.net *) eleven. *)
(* +81(90)2877-8845 (* (*
Henrik Brix Andersen
> The linux-info.eclass is used by a few packages to check for appropriate
> kernel configuration options.
This is basically bug #103878 :)
> What do you people think the proper solution is?
I suggest adding a $CONFIG_WARN variable for the options that are not
critical for compilation, but only are run-time dependancies. This
should work similar to $CONFIG_CHECK, except it will use ewarn()
instead eerror() and not call die().
I was in the progress of preparing such a patch when my laptop died
last week... I will pick it up again when I get it back from the shop
- or somebody impatient could do it instead ;)
Regards,
Brix
--
Henrik Brix Andersen <br...@gentoo.org>
Gentoo Metadistribution | Mobile computing herd
Alin Nastac
>I can only think of a couple of solution:
>
>- Remove these unnecessary checks completely: Follow the example of all
> other distributions and do not depend on anything kernel-ish for such
> packages. A recompilation of the kernel with different options can
> easily cause what the checks are trying to avoid anyway.
>
>- Make the checks in linux-info non-fatal. I.e., don't die but issue
> warnings instead. That's the *least* that I'd be happy with.
>
>What do you people think the proper solution is?
>
>
>
see https://bugs.gentoo.org/show_bug.cgi?id=103878
I am still waiting for a response.
Andrew Gaffney
> I kindof wonder why it doesn't try the sources of the running kernel. They
> are easilly found at "/lib/modules/`uname -v`/build". Of course as a
You mean `uname -r` :)
--
Andrew Gaffney http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer Installer Project
--
gento...@gentoo.org mailing list
Daniel Drake
> I can only think of a couple of solution:
>
> - Remove these unnecessary checks completely: Follow the example of all
> other distributions and do not depend on anything kernel-ish for such
> packages. A recompilation of the kernel with different options can
> easily cause what the checks are trying to avoid anyway.
>
> - Make the checks in linux-info non-fatal. I.e., don't die but issue
> warnings instead. That's the *least* that I'd be happy with.
>
> What do you people think the proper solution is?
In my opinion, the way it is currently done (require those options which are
required for the package to function correctly) is the right way to do it.
Just because other distributions do it differently doesn't justify us changing.
I've seen and recieved various reports of positive feedback about the way we
handle this.
The only real argument is that it makes it difficult for people who cross
compile packages for use on other systems only, in which case it might make
sense for the possibility to override the behaviour.
Daniel
--
gento...@gentoo.org mailing list
Paul de Vrieze
> On Wed, 2005-09-21 at 06:43 -0500, Andrew Gaffney wrote:
> > Paul de Vrieze wrote:
> > > I kindof wonder why it doesn't try the sources of the running
> > > kernel. They are easilly found at "/lib/modules/`uname -v`/build".
> > > Of course as a
> >
> > You mean `uname -r` :)
>
> the kernel?
Nah, it works if you used plain make or installed any module. It's not
related to the modules installed, but the new way to find the source of
the current kernel.
Chris Gianelloni
> > I kindof wonder why it doesn't try the sources of the running kernel. They
> > are easilly found at "/lib/modules/`uname -v`/build". Of course as a
>
> You mean `uname -r` :)
Also, that only works if ppp is a module. What if it is compiled into
the kernel?
My suggestion is to agree with Henrik. We should have a warning
instead, that first checks the kernel type (no point in making a stink
on *BSD), then the config. If it isn't found, give some nasty beeps and
a pause with a big fat warning, then continue.
By the way, this breaks the current way we build a livecd. While we can
move the ppp compile to after the kernel is configured, it means we need
to move anything that relies on ppp also. This really is a PITA when it
isn't necessary, as ppp compiles perfectly fine without a configured
kernel, as witnessed by every release up unto and including 2005.1's
release.
--
Chris Gianelloni
Release Engineering - Strategic Lead
Games - Developer
Gentoo Linux
Chris Gianelloni
Cross-compiling, embedded systems, and release-building all suffer from
this.
While it can be worked around for the releases, it is a serious pain to
have to constantly change how we build our releases to match with new
"functionality" in packages that impose artificial restrictions, such as
this.
CONFIG_PPP is *not* required to build ppp, so it shouldn't be in the
ebuild as a requirement.
Alin Nastac
>CONFIG_PPP is *not* required to build ppp, so it shouldn't be in the
>ebuild as a requirement.
>
>
>
I agree with this statement but I also see the warning as a must.
user should be warned that its kernel does not support CONFIG_PPP or,
depending on activefilter flag, CONFIG_PPP_FILTER.
Chris Gianelloni
I see absolutely no problem with that, so long as it is a warning.
I mean, you can make it beep, pause, display in flashing red lights and
email root@localhost about it for all I care, but it shouldn't *die* on
something that isn't a requirement.
Henrik Brix Andersen
> I see absolutely no problem with that, so long as it is a warning.
>
> I mean, you can make it beep, pause, display in flashing red lights and
> email root@localhost about it for all I care, but it shouldn't *die* on
> something that isn't a requirement.
I think we all agree by now that we need a way to warn about missing
CONFIG_ options in addition to the current implementation. Now we just
need someone to implement it, and have the affected ebuilds changed
accordingly.
What about the other issue which was brought up? Ebuilds enheriting
linux-info.eclass requires a configured kernel source? Personally, I
don't see anything wrong with that, if the above solution is
implemented (non-fatal checks remain non-fatal). Releng,
cross-compilers - what are your thoughts on this?
Martin Schlemmer
> On Wednesday 21 September 2005 09:42, Georgi Georgiev wrote:
> >
> > * Determining the location of the kernel source code
> > * Unable to find kernel sources at /usr/src/linux
> > * This package requires Linux sources.
> > * Please make sure that /usr/src/linux points at your running kernel,
> > * (or the kernel you wish to build against).
> > * Alternatively, set the KERNEL_DIR environment variable to the kernel
> > sources location
>
> I kindof wonder why it doesn't try the sources of the running kernel. They
> are easilly found at "/lib/modules/`uname -v`/build". Of course as a
> final result as someone might want to build against different sources,
> but it's a better fallback than an error message.
>
There are very good reasons why it should build against /usr/src/linux,
or at least try that first. The reasoning being that you might
cross-compile, or be in a chroot where /lib/modules/... is not valid,
etc. I guess with the variables to set it these days it might be
easier, but that is the expected way. Maybe changing it to first look
in /usr/src/linux (or KERNEL_DIR if set), and then for the running
kernel.
--
Martin Schlemmer
Martin Schlemmer
> On Wed, 2005-09-21 at 14:17 +0100, Daniel Drake wrote:
> > Quoting Georgi Georgiev <ch...@gg3.net>:
> > > I can only think of a couple of solution:
> > >
> > > - Remove these unnecessary checks completely: Follow the example of all
> > > other distributions and do not depend on anything kernel-ish for such
> > > packages. A recompilation of the kernel with different options can
> > > easily cause what the checks are trying to avoid anyway.
> > >
> > > - Make the checks in linux-info non-fatal. I.e., don't die but issue
> > > warnings instead. That's the *least* that I'd be happy with.
> > >
> > > What do you people think the proper solution is?
> >
> > In my opinion, the way it is currently done (require those options which are
> > required for the package to function correctly) is the right way to do it.
> >
> > Just because other distributions do it differently doesn't justify us changing.
> > I've seen and recieved various reports of positive feedback about the way we
> > handle this.
> >
> > The only real argument is that it makes it difficult for people who cross
> > compile packages for use on other systems only, in which case it might make
> > sense for the possibility to override the behaviour.
>
> Cross-compiling, embedded systems, and release-building all suffer from
> this.
>
I cannot remember .. does release-building (iow catalyst) set ROOT ? If
so, maybe just make it error if root is not set, as most if not all
cross compiling of such things (not talking toolchain) is done with ROOT
set as far I know.
--
Martin Schlemmer
Chris Gianelloni
> What about the other issue which was brought up? Ebuilds enheriting
> linux-info.eclass requires a configured kernel source? Personally, I
> don't see anything wrong with that, if the above solution is
> implemented (non-fatal checks remain non-fatal). Releng,
> cross-compilers - what are your thoughts on this?
non-fatal being non-fatal == approved by releng... ;]
Chris Gianelloni
> > > The only real argument is that it makes it difficult for people who cross
> > > compile packages for use on other systems only, in which case it might make
> > > sense for the possibility to override the behaviour.
> >
> > Cross-compiling, embedded systems, and release-building all suffer from
> > this.
> >
>
> I cannot remember .. does release-building (iow catalyst) set ROOT ? If
> so, maybe just make it error if root is not set, as most if not all
> cross compiling of such things (not talking toolchain) is done with ROOT
> set as far I know.
Only stage1 tarballs. Everything else is built in a chroot. Even
stage1 is funny since it is built in a chroot *and* uses ROOT (within
the chroot).
Nothing should be using uname for determining what to build against, as
it is quite common to build releases on machines with drastically
different kernels (and even arches).
The current /usr/src/linux method works quite well for releases. The
only issue we're having is a non-fatal check being fatal, which is going
to be fixed.
John Mylchreest
> The current /usr/src/linux method works quite well for releases. The
> only issue we're having is a non-fatal check being fatal, which is going
> to be fixed.
OK, so being the huy who wrote and looks after all this stuff, here is
my 2c and reasoning.
First of all, falling back on `uname -r` isn't going to happen for
several reasons. I can understand for some why this might seem sensible
(what happens if you remove your kernel sources for example). But the
fact remains that testing the currently running kernel is not a viable
option in my mind. Why? well, 1: the running kernel bares absolutely no
relevance on the environment which you're building this for. 2: you can
pass KERNEL_DIR manually, so if you refuse to work in the expected way
then set KERNEL_DIR to point to the right location.
Secondly, I have thought about this some more during the day, just as I
did at initial implementation (The code could do with a tidy-up
anyways). After much deliberation I feel the actual best way to deal
with this, is to have an override envvar which will bypass a die, and
simply warn instead. This will mean that those people who cross-compile
regularly, or building stages etc will work fine, and normal operation
would continue to refuse a build if the environment its building for
doesn't seem sane. At the end of the day, the true root cause of
something die'ing when it shouldn't is at the ebuild. That.. and if its
really not that important, then surely the ebuild can call the config
check itself, and handle it as it feels fit.
I'll update the bug also with this.
--
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
Chris Gianelloni
> anyways). After much deliberation I feel the actual best way to deal
> with this, is to have an override envvar which will bypass a die, and
> simply warn instead. This will mean that those people who cross-compile
> regularly, or building stages etc will work fine, and normal operation
> would continue to refuse a build if the environment its building for
> doesn't seem sane. At the end of the day, the true root cause of
This will not work. Anything environment-wise used to build the stages
makes its way *into* the stages. The stages are just builds within a
chroot. If I disable it for stage building, then it'll be disabled for
anyone that uses those stages by default.
The best solution is still a separate check that only throws a warning
state, as having a die on the check *is* valid for packages that require
a kernel to compile. Also, there's no way in stage building to use a
particular environment for only one package, so it would have to be
enabled globally. Not something good for packages that really *do*
require kernel sources to be present and configured.
Mike Frysinger
> What about the other issue which was brought up? Ebuilds enheriting
> linux-info.eclass requires a configured kernel source? Personally, I
> don't see anything wrong with that, if the above solution is
> implemented (non-fatal checks remain non-fatal). Releng,
> cross-compilers - what are your thoughts on this?
it's just as easy to configure a kernel for another architecture as it is for
a native one (assuming you got the hard part of generating a
cross-toolchain), so cross-compiling should be covered
-mike
--
gento...@gentoo.org mailing list
Paul de Vrieze
Of course this is kind of up to the portage developers, but wouldn't it
make sense to allow an ebuild to know that it was building a binary
package or with a ROOT environment. In the case of a binary package
building these checks could then be postponed to pre_install.
Henrik Brix Andersen
> First of all, falling back on `uname -r` isn't going to happen for
> several reasons. I can understand for some why this might seem sensible
> (what happens if you remove your kernel sources for example). But the
> fact remains that testing the currently running kernel is not a viable
> option in my mind. Why? well, 1: the running kernel bares absolutely no
> relevance on the environment which you're building this for. 2: you can
> pass KERNEL_DIR manually, so if you refuse to work in the expected way
> then set KERNEL_DIR to point to the right location.
People who prefer building against /lib/modules/`uname -r`/build/ can
just set KERNEL_DIR=/lib/modules/`uname -r`/build/ and all will be
dandy.
I agree that the current solutions with /usr/src/linux and KERNEL_DIR
overriding is the optimal solution - at least I have yet to hear about
a better solution.