Re: [gentoo-amd64] Re: eselect problems

[Drake Donahue]

----- Original Message ----- 
From: "Mark Knecht" <markknecht@×××××.com>
To: <gentoo-amd64@l.g.o>
Sent: Monday, November 24, 2008 9:35 AM
Subject: Re: [gentoo-amd64] Re: eselect problems


> On Mon, Nov 24, 2008 at 6:12 AM, Tonko Mulder <tonko.mulder@×××××.com>
> wrote:
>> Op maandag 24-11-2008 om 06:00 uur [tijdzone -0800], schreef Mark
>> Knecht:
>>> On Sun, Nov 23, 2008 at 10:26 PM, Duncan <1i5t5.duncan@×××.net> wrote:
>>> > "Mark Knecht" <markknecht@×××××.com> posted
>>> > 5bdc1c8b0811231435y2eea1b1by366c787c983c1089@××××××××××.com, excerpted
>>> > below, on  Sun, 23 Nov 2008 14:35:42 -0800:
>>> >
>>> >> The root cause of this is I wanted to emerge the newest version of
>>> >> Ardour from the pro-audio overlay and ran into a new message about it
>>> >> being masked by something called EAPI 2 which according to the
>>> >> message
>>> >> requires a 'newer' version of portage. (No revision given.) That's
>>> >> all
>>> >> this was about, and there's absoutely no rush to fix it as I'm not
>>> >> likely to really use Ardour. Just wanted to take a look at what sort
>>> >> of
>>> >> headway they are making with their feature set so it's really nothing
>>> >> but pure curiosity.
>>> >
>>> > OK.  FWIW, for EAPI-2, you need the new ~arch portage-2.2-rcX series.
>>> > EAPI-2 is allowed in various overlays and now in ~arch, but not in
>>> > stable
>>> > until a stable portage supports it.  It'll bring a number of new
>>> > features
>>> > including full set support, per-package use-defaults (previously a USE
>>> > flag could be defaulted to on per profile, but not per package, off
>>> > being
>>> > the unset default, of course), and IIRC use dependencies (if a package
>>> > requires say C++ support and gcc has been built without it, it must
>>> > now
>>> > die with an error message telling the user to make the change, with
>>> > use-
>>> > deps, it could force gcc to be recompiled with C++ instead of dying,
>>> > thus
>>> > avoiding somebody leaving a 200-package emerge going overnight, only
>>> > to
>>> > come back the next day to find out it stopped with package #2 due to a
>>> > USE dependency death).
>>> >
>>> > So there are some nice things coming in EAPI-2 and a number of
>>> > packages
>>> > can really use them.  But an EAPI-2 supporting portage, while now in
>>> > the
>>> > tree, remains unstable, as there are still a few bugs to work out
>>> > before
>>> > it goes fully stable.  So if you prefer a stable portage, you'll have
>>> > to
>>> > wait for EAPI-2, and any packages requiring it (which by definition
>>> > can't
>>> > be stabilized until an EAPI-2 portage is stable too).
>>> >
>>> > --
>>> > Duncan - List replies preferred.   No HTML msgs.
>>>
>>> Thanks Duncan. I basically understand the portage stuff, in the sense
>>> that it's a new feature. I read a few eamils form the portage
>>> developers, etc., and got a sense of some of what it is supposed to
>>> do. that part I'm OK with, as I am, I guess, with the idea that
>>> someone who wrote the Ardour ebuild is requiring these new features.
>>>
>>> My real question is what is required to build that portage on an
>>> ~amd64 machine so that I can build Ardour? Is anyone on this list
>>> using portage-2.2.x? If so how did they get it to build?
>>>
>> I run sys-apps/portage-2.2_rc15
>> But that just got installed with the updates. Not sure if there are
>> special requirements or not.
>
> Thanks Tonko.
>
> Watch out for a portage downgrade if you haven't unmasked 2.2-rcX.
> Reading on the 32-bit list there are others who are getting downgraded
> due to developers wanting more testing on 2.1...
>
> Cheers,
> Mark
>
The wisdom of making currently existing and useful packages depend on some 
future incomplete package management system (so that updates become arduous 
and/or impossible)?? Anyone discovered a way to cope with 'masked by eapx '? 
sys-apps/portage-2.2_rc15 did not relieve a 'masked by eap2' ....