On Tue, Oct 14, 2008 at 3:34 PM, Petteri Räty <[EMAIL PROTECTED]> wrote:
> Marius Mauch kirjoitti:
>> On Tue, 14 Oct 2008 10:59:39 +0200
>> Jose Luis Rivero <[EMAIL PROTECTED]> wrote:
>>
>>> On Mon, Oct 13, 2008 at 05:38:34PM -0700, Donnie Berkholz wrote:
>>>> On 02:03 Tue 14 Oct     , Jose Luis Rivero wrote:
>>>>> There are some others sceneries but are not so common as the one
>>>>> presented could be. Any decent solution for this case?
>>>> There are only a few obvious ones, you'll have to pick which one
>>>> you like best. Most of the other options basically duplicate these
>>>> in some way or add more work to them for negligible gain:
>>>>
>>>> - Backport the ebuild from EAPI=2 to EAPI=0
>>> EAPI-2 to EAPI-0 could imply lot of changes (not talking about what is
>>> going to happen when we release new and more feature rich EAPIs), and
>>> changes usually come with bugs. The ebuild is committed directly to
>>> stable implies bugs in stable, which for me is a no-go.
>>
>> Assuming the ebuild changes between foo-1 and foo-2 are mainly due to
>> the change from EAPI=0 to EAPI=2 (which I'd expect to be true in many
>> cases) you could just reuse the foo-1 ebuild for foo-3.
>>
>> If there are major differences between foo-1 and foo-2 not related to
>> the EAPI change then the maintainer probably didn't want foo-2 to
>> become stable anytime soon, so it's at least questionable if foo-3
>> should go straight to stable in the first place.
>>
>> And adding a new version directly to stable always comes with a risk,
>> you can't eliminate that completely. It's all about risk assessment,
>> and how much work you're willing to do or time you want to spend to
>> minimize the risk.
>>
>
> There's no need to commit straight to stable. Just make two different
> new revisions for each EAPI. Then the arch teams can test it like usual.

Aha a perfect canidate use case for GLEP 55[1] that fends off 'why are
there multiple versions of the same package' questions and
complexities.

[1] http://www.gentoo.org/proj/en/glep/glep-0055.html

>
> Regards,
> Petteri
>
>

Reply via email to