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"
1 Tiziano Müller wrote:
2 >> What is proposed in glep-55 seems to aim to solve both issues at the
3 >> same time (it isn't stated) by switching file extension every time the
4 >> eapi is changed. This is slightly against the principle of the least
5 >> surprise and apparently is disliked by enough people to lead the
6 >> situation to be discussed in the council.
7 >>
8 >
9 > Instead of switching file extension every time the eapi is changed you
10 > could also increment it only when a new EAPI breaks sourcing the ebuild
11 > compared to the requirements of the prior EAPI.
12 > (This way you'd in fact split EAPI into a major- and a minor-version.)
13
14 Makes you getting to have to do the two stage source again AND you get
15 another non obvious condition "Should I bump the eapi internally or the
16 filename?"
17
18 The main point again what is proposed in glep-55 is it that isn't
19 invasive and non-transparent to users and developers.
20
21 As stated in the analysis, the user side is already covered by the fact
22 users use the cache, the developer side would require a two stage
23 sourcing when committing to remain transparent.
24
25 What we need to balance is if the invasive proposal is simpler than
26 having a two stage sourcing done.
27
28 lu
29
30 --
31
32 Luca Barbato
33 Gentoo Council Member
34 Gentoo/linux Gentoo/PPC
35 http://dev.gentoo.org/~lu_zero

Replies