Petteri Räty wrote:
Let's try something new. I would like to get opinions from as many people as possible about GLEP 55 and alternatives listed here in order to get some idea what the general developer pool thinks. Everyone is only allowed to post a single reply to this thread in order to make it easy to read through. The existing thread should be used for actual discussion about the GLEP and the alternatives. This should be a useful experiment to see if we can control ourselves :)My notes so far: 1) Status quo - does not allow changing inherit - bash version in global scope - global scope in general is quite locked down 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 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 Regards, Petteri
Thanks for gathering input from the dev community. I do not wish to respond to the monster thread (and won't).
Personally, I don't need the flexibility that glep55 provides for *my* ebuilds. The current scheme doesn't bother me. And actually, after doing some testing, I found that at least one of that packages/projects that I am involved in will need updating every time the extension changes (or some more broad change - I don't have time to investigate too much tbh). So, I would prefer that the file extension did not change [much/every eapi]. However, I can roll with the punches if it truely is needed. I also understand that some change is good in the long run even if it has some upfront cost to it.
However, in case that this discussion gets deferred until later, I would like to express that the Council should "request" (not demand) that portage adds support for the leading 2 ideas that result from the current discussion. This will allow us to not wait even longer when we are having this discussion in 2010 (hypothetically).
Thanks for listening, Petteri. -Jeremy
