[gentoo-amd64] Re: eselect problems

[Duncan]

"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