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>
Thomas Anderson <email@example.com>
Re: Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Mon, 23 Feb 2009 08:40:08 -0500
On Mon, Feb 23, 2009 at 02:21:33PM +0100, Luca Barbato wrote:
> 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 glep is quite clear on that point.
> The main point again what is proposed in glep-55 is it that isn't invasive
> and non-transparent to users and developers.
It's not all that invasive. All that changes is that the EAPI goes at
the end of the filename and you don't set it in the ebuild. Developers
should be able to keep up with this, and if a user asks it's easy enough
to say that "it's a new version of ebuild, it has newer features see
www.blah.org/blah for details". And really, users already ask what EAPI
is so it's not that much headache.
Areas of responsibility:
AMD64, Secretary to the Gentoo Council