[gentoo-dev] Re: EAPI placement
Steve Long [EMAIL PROTECTED] posted [EMAIL PROTECTED], 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 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
[gentoo-dev] Re: EAPI placement
Carsten Lohrke wrote: On Mittwoch, 12. Dezember 2007, Ciaran McCreesh wrote: * Eclasses may not set EAPI. * Eclasses may not assume a particular EAPI. I disagree here. It would be annoying and possibly even hindering in future not being able to use higher EAPI features in eclasses. Point is the eclass has to check, if the author of an ebuild sets another EAPI and throw an error, in this case. Agreed. There's no problem from the bash side of this, only the PM specific code. 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.) 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. On Mittwoch, 12. Dezember 2007, Santiago M. Mola wrote: Nobody said that eclasses can't use new features. Using new features in ebuilds or eclasses relates. EAPI A using ebuild with EAPI B using eclass (but not defining any EAPI) is your hard nut. Shouldn't happen, but will. And bugs in eclasses unfortunately don't have a minor impact. Just that they cannot _set_ EAPI or assume they are working with any EAPI. And I say they can - under the condition that you have a defined subset of ebuilds belonging to that eclass. And it's a major loss of flexibility in addition to the maintenance problems you highlight. A dynamic EAPI declaration in an ebuild is foolish, but testing the EAPI value in an eclass and taking alternative action, or indeed allowing dynamic setting in that context (which would require additional metadata-- in this case i think the overhead is worth it, given that eclasses are much less numerous than ebuilds, and it's actually *adding* to what we can do already) makes a lot more sense. zlin the kde4 eclasses in the kde4-experimental overlay set eapi=1. zmedico it's fine to do that, it's just too early to do that on lots of eclasses in the main tree, because EAPI=1 is too new So there's no technical reason not to to, apart from some concern about signalling die()? Cardoe I think putting EAPI above inherit is bad Cardoe because you're relying on the ebuild author to audit all the eclass code to know which EAPI version is required Ouch. Well at least EAPI anything is still experimental atm. Thank heavens for peer review :D -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: EAPI placement
Doug Klima schrieb: Cardoe zmedico: what if I have EAPI=2 above the inherit but an eclass has EAPI=1 if an eclass sets EAPI, then the ebuild shouldn't... make it two eclasses if needed or plain bump them if really really needed. Greetz Jokey signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: EAPI placement
On Tuesday 11 December 2007 18:21:31 Markus Ullmann wrote: Doug Klima schrieb: Cardoe zmedico: what if I have EAPI=2 above the inherit but an eclass has EAPI=1 if an eclass sets EAPI, then the ebuild shouldn't... make it two eclasses if needed or plain bump them if really really needed. Greetz Jokey That doesn't sound right. What happens if the eclass sets an EAPI(say 1), but you need to use say X feature(which is in EAPI 2). By what you said, this would prevent the ebuild from using the features in EAPI 2. It also isn't smart to bump eclasses' EAPI--EAPI should be set to the lowest common denominator that that feature being used is in. If that made sense ;) -- 2.6.23-gentoo-r3 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: EAPI placement
Thomas Anderson wrote: On Tuesday 11 December 2007 18:21:31 Markus Ullmann wrote: Doug Klima schrieb: Cardoe zmedico: what if I have EAPI=2 above the inherit but an eclass has EAPI=1 if an eclass sets EAPI, then the ebuild shouldn't... make it two eclasses if needed or plain bump them if really really needed. Greetz Jokey That doesn't sound right. What happens if the eclass sets an EAPI(say 1), but you need to use say X feature(which is in EAPI 2). By what you said, this would prevent the ebuild from using the features in EAPI 2. It also isn't smart to bump eclasses' EAPI--EAPI should be set to the lowest common denominator that that feature being used is in. If that made sense ;) The issue additionally is that future EAPIs may remove deprecated features and may also have conflicting actions. So running an ebuild that's designed for say EAPI=2, which conflicts with EAPI=1, as EAPI=1 may be broken. -- Doug Klima [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ -- [EMAIL PROTECTED] mailing list
