Gentoo Archives: gentoo-council

From: Luca Barbato <lu_zero@g.o>
To: gentoo-dev@l.g.o
Cc: Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>, gentoo-council@l.g.o
Subject: Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Date: Mon, 23 Feb 2009 13:21:37
Message-Id: 49A2A2DD.7080706@gentoo.org
In Reply to: Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009) by "Tiziano Müller"
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 filename?" 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. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero

Replies