List Archive: gentoo-council
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
Luca Barbato <firstname.lastname@example.org>
Re: Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Mon, 23 Feb 2009 14:21:33 +0100
Tiziano Müller wrote:
>> What is proposed in glep-55 seems to aim to solve both issues at the
>> same time (it isn't stated) by switching file extension every time the
>> eapi is changed. This is slightly against the principle of the least
>> surprise and apparently is disliked by enough people to lead the
>> situation to be discussed in the council.
> Instead of switching file extension every time the eapi is changed you
> could also increment it only when a new EAPI breaks sourcing the ebuild
> compared to the requirements of the prior EAPI.
> (This way you'd in fact split EAPI into a major- and a minor-version.)
Makes you getting to have to do the two stage source again AND you get
another non obvious condition "Should I bump the eapi internally or the
The main point again what is proposed in glep-55 is it that isn't
invasive and non-transparent to users and developers.
As stated in the analysis, the user side is already covered by the fact
users use the cache, the developer side would require a two stage
sourcing when committing to remain transparent.
What we need to balance is if the invasive proposal is simpler than
having a two stage sourcing done.
Gentoo Council Member