Steve Long <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], 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 -- [EMAIL PROTECTED] mailing list
