Re: [gentoo-dev] GLEP33: Eclass restructure

[Brian Harring]

On Tue, Feb 22, 2005 at 04:57:50PM +0100, Gustavo de Lama wrote:
> The matter is I cant but give my two cents and say: SLOT.
Not possible, unfortunately :)

The problem is, eclasses aren't installed really- they're just updated alongside ebuilds.  They are _part_ of the 
ebuild in essence, so they're required to be available just to get the metadata out of an ebuild (the SLOT setting 
for example).  So that ixnays it pretty effectively- slot is useful/relevant only for installing packages- since 
eclasses themselves aren't installed (any more then an unmerged ebuild is 'installed'), not possible.

The other issue, and this is why eclasses are proposed to be moved within the tree, is that since eclasses are 
'live', constantly in use, the slotting concept doesn't work- you need some way to transfer over from the existing 
eclasses in the tree, to a point where the eclasses no longer have to maintain the exact api for years on end.  

If you're proposing basically having a 'new' eclass whenever the api is changed, for stable portage, yeah, 
that's the route that would _have_ to be taken for any removals from an eclasses existing api.

For portage cvs head, it's not _required_ though, so instead of it being a req (never remove an eclass, or a func 
from it's api, only add), the decision of 'versioning'/'slotting' via a new eclass name is completely up to the 
eclass maintainer.

Re-iterating, that is the reason why the relocation of eclasses within the tree is required- the 'new' eclasses that don't 
have the non-subtractable api requirements, due to their dynamic nature *cannot* be accessible by older portage 
versions.

If (for example) current stable portage could use one of the 'dynamic' eclasses, it would result in pretty much 
continual borkage/failures for that system, which isn't desirable. :)
~brian
--
gentoo-dev@g.o mailing list