On Sunday 17 May 2009, Piotr Jaroszyński wrote: > Hello, > > I have just updated GLEP 55 [1], hopefully making it a bit clearer. > > Just FYI, my order of preference of solutions is: > > 1. EAPI-suffixed ebuilds (obviously) > 2. EAPI in the filename with one-time extension change > 3. Easily fetchable EAPI inside the ebuild and one-time extension > change
Judging from this list, fourth option present in the GLEP is
unacceptable for you?
4. Easily fetchable EAPI inside the ebuild
From what I understand, the difference between 3 and 4 is that
(4) would break pre-glep55 Portage versions that see an ebuild with no
metadata cache present if the ebuild uses a future EAPI that
introduces changes as described in the "Current behaviour" section.
(4) would otherwise keep the current workflow the same except
restricting the way the EAPI variable is defined in the ebuild.
I would argue that most people who are be exposed to repositories that
do not carry a metadata cache (overlays) which use new EAPIs also keep
their portage version current. I'd say go with option (4) now and by
the time EAPI 4 is collected, written up, agreed upon and implemented,
enough time went by so we would not have to introduce an artificial
delay.
And after that, there won't be any delay to avoid breakage anymore.
Robert
signature.asc
Description: This is a digitally signed message part.
