Re: [gentoo-amd64] Re: eselect problems

[Mark Knecht]

On Mon, Nov 24, 2008 at 11:59 AM, Duncan <1i5t5.duncan@×××.net> wrote:
> "Drake Donahue" <donahue95@×××××××.net> posted
> 414A2586925347C7BCFA0A784EC2A8FE@iwillxp333, excerpted below, on  Mon, 24
> Nov 2008 12:19:04 -0500:
>
>> 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' ....
>
> It should be 2.2_rc16, now.  rc15 has a circular logic bug on unsolved
> dependencies.
>
> But unless you happened to hit that bug, EAPI-2 should have worked, at
> least for anything in-tree and at least ~arch unmasked.  I'm not sure why
> it wouldn't have and if it didn't it's certainly a bug, either in the
> package or in portage.  Of course, overlays are an entirely different
> matter.  In part, they are /intended/ to allow experimentation, and for
> the more experimental overlays, all bets and all guarantees are off.  See
> below.
>
> But to answer your question, the EAPI restrictions work in stages, as
> follows:
>
> (1) Overlays can use whatever weird features they want, including ones
> only (for example) paludis supports, not portage at all.  That's one of
> the reasons they are there, to allow the testing of experimental features.
>
> (2) In ordered to be unmasked to ~arch in the tree, the features used
> must be in a Gentoo council approved EAPI.  The council has decided that
> it will only approve an EAPI (E-API, e being the traditional Gentoo
> prefix for package manager stuff and API having the traditional meaning)
> once it is concretely defined such that all three package managers agree
> on the definition, and when the official Gentoo PM, portage, supports it,
> at the same ~arch level as the packages depending on that EAPI.
>
> (3) No package using a new EAPI can go stable until the official package
> manager, portage, supports it in a stable version as well.
>
> If you are using overlay ebuilds, it's assumed you know how experimental
> that overlay is allowed to be and that you are willing to run an equally
> experimental package manager implementation of whatever features it
> uses.  Gentoo neither can nor does attempt to make guarantees at that
> level.  If you are using ~arch packages, there are limited guarantees
> attempted, but as the express purpose of ~arch is to allow packages
> intended for stable to be tested, but it's understood to be unstable and
> thus there will be bugs from time to time.  Again, if you choose to use
> such packages, it's assumed you have your reasons and can manage to live
> with the consequences of the bugs that will occur.
>
> If you don't like those terms, only use stable, but be prepared to live
> with packages somewhat behind the times.  In some cases, particularly
> with new hardware or with software that just added a very popular new
> feature, this will mean you'll simply do without support if you require
> that hardware support or feature to use the package, until the package
> works its way thru the system and is stabilized.
>
> Personally, I default to ~arch, and unmask hard-masked packages either in-
> tree or from various overlays from time to time as well.  But in general,
> I'm prepared for them to fail once in awhile, and to spend sometimes
> significant time tracing and reporting bugs, then working around them or
> rolling back to an earlier version without the bug, should I need the
> bugged functionality.  But YMMV definitely applies in this area, and
> while I'd not be satisfied running what I'd consider long outdated
> versions that may be the latest stable in many cases, other people may
> prefer that stability even if it does mean being maybe a year behind at
> times, possibly even more in some cases.
>
> --
> 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
>
>
>