* Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
@ 2009-02-25 8:16 99% ` Alexis Ballier
0 siblings, 0 replies; 1+ results
From: Alexis Ballier @ 2009-02-25 8:16 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 2150 bytes --]
I have no strong opinion about this.
> 2) EAPI in file extension
> - Allows changing global scope and the internal format of the ebuild
> a) .ebuild-<eapi>
> - ignored by current Portage
simple, straightforward but ugly
> b) .<eapi>.ebuild
> - current Portage does not work with this
this only has disadvantages in front of a)
> c) .<eapi>.<new extension>
> - ignored by current Portage
same as a) but maybe less ugly
> 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
This doesn't need a locked down place, just some strict way of setting
it, like at most one EAPI="constant_string_without_space" so that grep
& friends can catch it.
> - Does not allow changing versioning rules unless version becomes a
> normal metadata variable
I'm not entirely sure about this and would need some real
example/argument in order to be convinced
> * Needs more accesses to cache as now you don't have to load older
> versions if the latest is not masked
true but this "more" would need to be measured and opposed to the
number of metadata loads in a dep resolution procedure.
> a) <new extension>
doesn't have the one year wait drawback and doesn't mess with pm
implementation details (eapi) with package names that shall represent
upstream ones.
> 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
I see no advantage there vs 3.a)
> c) .ebuild in current directory
> - needs one year wait
That could have been done one year ago and would be done now; I think
it's still fine now because I don't expect major behavior changes in
the ebuild format within one year.
To summarize, I would retain 3.a as best solution, having the "usable
right now" advantage of current glep55 and keeping the ebuild's file
names (more or less) consistent with upstream ones.
Alexis.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2009-02-24 22:21 [gentoo-dev] Collecting opinions about GLEP 55 and alternatives Petteri Räty
2009-02-25 8:16 99% ` Alexis Ballier
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox