Steve Long <slong@...> posted
fknh2s$59n$1@..., excerpted below, on Mon, 24 Dec 2007 05:51:34
>> 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
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
firstname.lastname@example.org mailing list