On Wed, Feb 25, 2009 at 12:21:23AM +0200, Petteri R??ty wrote: > 1) Status quo > - does not allow changing inherit > - bash version in global scope > - global scope in general is quite locked down
Yuck, I want per-package eclasses and all those other goodies. > 2) EAPI in file extension > - Allows changing global scope and the internal format of the ebuild > a) .ebuild-<eapi> > - ignored by current Portage > b) .<eapi>.ebuild > - current Portage does not work with this > c) .<eapi>.<new extension> > - ignored by current Portage 2a please, though .ebuild.eapi would be fine as well. My reasons are mostly contained in Antarus' glep revision, and the fact that there have been no real valid(IMO) objections. > 3) EAPI in locked down place in the ebuild > - Allows changing global scope > - EAPI can't be changed in an existing ebuild so the PM can trust > the value in the cache > - Does not allow changing versioning rules unless version becomes a > normal metadata variable > * Needs more accesses to cache as now you don't have to load older > versions if the latest is not masked > a) <new extension> > b) new subdirectory like ebuilds/ > - we could drop extension all together so don't have to argue about > it any more > - more directory reads to get the list of ebuilds in a repository > c) .ebuild in current directory > - needs one year wait These are all ugly.(c is the worst). Oh, And I certainly hope this is not Democracy(you know what they say, democracy is two wolves and a sheep deciding who to have for dinner) Looking forward to the council meeting, where there will *hopefully* be a decision. Thomas -- --------- Thomas Anderson Gentoo Developer ///////// Areas of responsibility: AMD64, Secretary to the Gentoo Council ---------
pgpFU0kxFHMxR.pgp
Description: PGP signature
