[gentoo-dev] linux-info.eclass and $CONFIG_CHECK

[gentoo-dev] linux-info.eclass and $CONFIG_CHECK

[Georgi Georgiev]

[-- Attachment #1: Type: text/plain, Size: 2810 bytes --]

The linux-info.eclass is used by a few packages to check for appropriate
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.  (
 )    chutz@gg3.net     ) -- Henry Spencer                              )
(   +81(90)2877-8845   (                                               (

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] linux-info.eclass and $CONFIG_CHECK

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]

On Wed, 21 Sep 2005 16:42:49 +0900
Georgi Georgiev <chutz@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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] linux-info.eclass and $CONFIG_CHECK

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 820 bytes --]

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.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] linux-info.eclass and $CONFIG_CHECK

[Georgi Georgiev]

[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]

maillog: 21/09/2005-10:27:21(+0200): Paul de Vrieze types
> 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   (*
*)    chutz@gg3.net    *) eleven.                                      *)
(*  +81(90)2877-8845   (*                                              (*

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] linux-info.eclass and $CONFIG_CHECK

[Alin Nastac]

[-- Attachment #1: Type: text/plain, Size: 628 bytes --]

Georgi Georgiev 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? 
>
>  
>
see https://bugs.gentoo.org/show_bug.cgi?id=103878
I am still waiting for a response.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [gentoo-dev] linux-info.eclass and $CONFIG_CHECK

[Henrik Brix Andersen]

[-- Attachment #1: Type: text/plain, Size: 821 bytes --]

On Wed, Sep 21, 2005 at 04:42:49PM +0900, Georgi Georgiev wrote:
> The linux-info.eclass is used by a few packages to check for appropriate
> kernel configuration options.
[snip]

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 <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: Type: application/pgp-signature, Size: 211 bytes --]

Re: [gentoo-dev] linux-info.eclass and $CONFIG_CHECK

[Andrew Gaffney]

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` :)

-- 
Andrew Gaffney                            http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer                                   Installer Project
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] linux-info.eclass and $CONFIG_CHECK

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1088 bytes --]

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` :)

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] linux-info.eclass and $CONFIG_CHECK

[Daniel Drake]

Quoting Georgi Georgiev <chutz@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.

Daniel
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] linux-info.eclass and $CONFIG_CHECK

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 719 bytes --]

On Wednesday 21 September 2005 15:11, Chris Gianelloni wrote:
> 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` :)
>
> Also, that only works if ppp is a module.  What if it is compiled into
> 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.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] linux-info.eclass and $CONFIG_CHECK

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1714 bytes --]

On Wed, 2005-09-21 at 14:17 +0100, Daniel Drake wrote:
> Quoting Georgi Georgiev <chutz@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.

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.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] linux-info.eclass and $CONFIG_CHECK

[Alin Nastac]

[-- Attachment #1: Type: text/plain, Size: 317 bytes --]

Chris Gianelloni wrote:

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [gentoo-dev] linux-info.eclass and $CONFIG_CHECK

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 752 bytes --]

On Wed, 2005-09-21 at 16:57 +0300, Alin Nastac wrote:
> Chris Gianelloni wrote:
> 
> >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.

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.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] linux-info.eclass and $CONFIG_CHECK

[Henrik Brix Andersen]

[-- Attachment #1: Type: text/plain, Size: 981 bytes --]

On Wed, Sep 21, 2005 at 10:22:08AM -0400, Chris Gianelloni wrote:
> 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?

Regards,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: Type: application/pgp-signature, Size: 211 bytes --]

Re: [gentoo-dev] linux-info.eclass and $CONFIG_CHECK

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1257 bytes --]

On Wed, 2005-09-21 at 10:27 +0200, Paul de Vrieze wrote:
> 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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] linux-info.eclass and $CONFIG_CHECK

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1679 bytes --]

On Wed, 2005-09-21 at 09:26 -0400, Chris Gianelloni wrote:
> On Wed, 2005-09-21 at 14:17 +0100, Daniel Drake wrote:
> > Quoting Georgi Georgiev <chutz@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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] linux-info.eclass and $CONFIG_CHECK

[Mike Frysinger]

On Wednesday 21 September 2005 10:33 am, Henrik Brix Andersen wrote:
> 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
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] linux-info.eclass and $CONFIG_CHECK

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 537 bytes --]

On Wed, 2005-09-21 at 16:33 +0200, Henrik Brix Andersen wrote:
> 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
Release Engineering - Strategic Lead
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] linux-info.eclass and $CONFIG_CHECK

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1225 bytes --]

On Wed, 2005-09-21 at 17:05 +0200, Martin Schlemmer wrote:
> > > 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.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] linux-info.eclass and $CONFIG_CHECK

[John Mylchreest]

[-- Attachment #1: Type: text/plain, Size: 1873 bytes --]

On Wed, 2005-09-21 at 12:03 -0400, Chris Gianelloni wrote:
> 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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] linux-info.eclass and $CONFIG_CHECK

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]

On Wed, 2005-09-21 at 17:47 +0100, John Mylchreest wrote:
> 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.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] linux-info.eclass and $CONFIG_CHECK

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1658 bytes --]

On Wednesday 21 September 2005 19:52, Chris Gianelloni wrote:
> On Wed, 2005-09-21 at 17:47 +0100, John Mylchreest wrote:
> > 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.

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.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] linux-info.eclass and $CONFIG_CHECK

[Henrik Brix Andersen]

[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]

On Wed, Sep 21, 2005 at 05:47:09PM +0100, John Mylchreest wrote:
> 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.

Regards,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: Type: application/pgp-signature, Size: 211 bytes --]

Re: [gentoo-dev] linux-info.eclass and $CONFIG_CHECK

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1978 bytes --]

On Thu, 2005-09-22 at 10:46 +0200, Paul de Vrieze wrote:
> On Wednesday 21 September 2005 19:52, Chris Gianelloni wrote:
> > On Wed, 2005-09-21 at 17:47 +0100, John Mylchreest wrote:
> > > 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.
> 
> 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.

That would still bomb out release building, as we install the binpkg
immediately before starting the next package.

So far, the *only* solution that doesn't break release building is
another check that is non-fatal.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]