Steve Long <slong@...> posted
fknh2s$59n$1@..., excerpted below, on  Mon, 24 Dec 2007 05:51:34
+0000:

>> The most basic issue, which we didn't even discuss yet, afaik, is how
>> to make every developer aware which feature belongs to which EAPI. I
>> freely admit, I do not know that. Is there a list somewhere?
>>
> Well the official one is the internal Gentoo PMS repo. The Council
> haven't changed the policy so far this term on what is the
> "authoritative" PMS. (Nor of course have they accepted any of the drafts
> officially.)

The problem right now is that while you are correct, that's the official 
list, due to technical/political issues, the Gentoo-official PMS repo 
doesn't (or didn't as of the last council meeting, according to the log) 
have any EAPI-1 info at all, as it's currently outdated, with the work 
all going into the off-Gentoo repo.  (Apparently, there aren't any 
official Gentoo devs working on PMS ATM. =8^(  Did I mention political 
issues in addition to technical ones?)

Thus, one can get detailed but unofficial specs from the informal non-
Gentoo repo, or a general summary as in the new-version portage 
announcement mentioning EAPI-1 support, now, or look at the code of the 
various PMs. =8^(

>> EAPI issues may lead to a lot of confusion and eclass bloat, especially
>> since we still can't remove stale eclasses afaik.
>>
> Another maintenance headache, agreed.
> 
> Is it possible to remove an eclass if it can be shown that there are no
> apps in the tree using it, say for over 2 years? That would give Gentoo
> equivalence with longer-term "support" from other distros, while
> allowing some breathing space wrt installed ebuilds. It'd be easy enough
> to automate a hook to move deleted eclasses to local overlay as well.

Well... according to the portage devs (as posted on the portage devel 
list) newer portage now stores the complete build environment, including 
the state of all inherited eclasses at the time of the original merge, 
and uses them at unmerge if at all possible.  If the merge was from an 
older version before this info was stored, or if the package database is 
corrupted and thus is otherwise missing the complete eclass info, portage 
can and does still pull from the live tree.

Thus, in theory, a year or so after the first version with that 
functionality working goes/went stable (I don't track stable status as 
I'm on ~arch, so I've no idea if it's stable yet or not, or for that 
matter which version first qualified), it should then be possible to 
start removing old/stale eclasses, keeping in mind that even after they 
are removed, if someone /really/ needs them, they can still fetch them 
out of the source control system attic.

So in any case, it should be possible <2 years from now; just not yet.

-- 
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@g.o mailing list