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

[Chris Gianelloni]

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