[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    [gentoo-dev]  Re: "active" gcc/kernel/... dependencies (was: tr1 dependencies)
From:       Duncan <1i5t5.duncan () cox ! net>
Date:       2007-01-30 16:38:59
Message-ID: epnsb3$2a1$5 () sea ! gmane ! org
[Download RAW message or body]

Marius Mauch <genone@gentoo.org> posted
20070130164951.1b0215d9.genone@gentoo.org, excerpted below, on  Tue, 30
Jan 2007 16:49:51 +0100:

> On Tue, 30 Jan 2007 14:49:48 +0100
> Matthias Langer <mlangc@gmx.at> wrote:
> 
>> isn't it possible to check the version of gcc that is in _use_ in an
>> ebuild, like i can do in a configure script? if so, one could provide a
>> "old-gcc" use flag that must be enabled when trying to build with
>> <gcc-4.1.0 (that actually pulls in boost etc.) and must not be enabled
>> when using >=gcc-4.1.0 ...
> 
> Sure you can check for it, but not at dependency calculation time. A
> useflag won't help there, would be the same as a || dependency, just
> worse.

What about a USE flag set by the profile (there's a boost
use flag already, however, so that's out unless usage can be made
compatible with the profile-masking bit)?  Archs that don't have >gcc-4.1
can mask the flag and hard-set the dependency to boost.  Those that have
it stable can mask it and hard-set the gcc-4.1 dependency.  Those that
have >gcc-4.1 as unstable can unmask the useflag and default it to boost.

Ebuilds using the flag could set an ewarn or elog that warns appropriately
about having to run revdep-rebuild or emerge -N if the flag is changed or
boost unmerged, and the rest could be handled in profile upgrade
documentation where it applies.

This should certainly be sufficient for non-toolchain.  If there's a
toolchain dependency, things get a bit more hairy, but profile changes and
possibly having an emergency binary tarballed version if appropriate,
preferably built with the dependency static, should still handle it.  With
the transfer to profile-controlled multilib, I know amd64 had a couple
hairy profile upgrades where a multilib gcc binary tarball came in handy. 
IIRC there was a flag set in the profile change that the profile's bashrc
tested for and warned about if the profile switching instructions hadn't
been followed, and emerge wouldn't do much until the profile was switched
back and the profile switched to following the instructions if desired, so
it can be done.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list


[prev in list] [next in list] [prev in thread] [next in thread]