| 1 |
On Tue, Oct 14, 2008 at 3:34 PM, Petteri Räty <betelgeuse@g.o> wrote: |
| 2 |
> Marius Mauch kirjoitti: |
| 3 |
>> On Tue, 14 Oct 2008 10:59:39 +0200 |
| 4 |
>> Jose Luis Rivero <yoswink@g.o> wrote: |
| 5 |
>> |
| 6 |
>>> On Mon, Oct 13, 2008 at 05:38:34PM -0700, Donnie Berkholz wrote: |
| 7 |
>>>> On 02:03 Tue 14 Oct , Jose Luis Rivero wrote: |
| 8 |
>>>>> There are some others sceneries but are not so common as the one |
| 9 |
>>>>> presented could be. Any decent solution for this case? |
| 10 |
>>>> There are only a few obvious ones, you'll have to pick which one |
| 11 |
>>>> you like best. Most of the other options basically duplicate these |
| 12 |
>>>> in some way or add more work to them for negligible gain: |
| 13 |
>>>> |
| 14 |
>>>> - Backport the ebuild from EAPI=2 to EAPI=0 |
| 15 |
>>> EAPI-2 to EAPI-0 could imply lot of changes (not talking about what is |
| 16 |
>>> going to happen when we release new and more feature rich EAPIs), and |
| 17 |
>>> changes usually come with bugs. The ebuild is committed directly to |
| 18 |
>>> stable implies bugs in stable, which for me is a no-go. |
| 19 |
>> |
| 20 |
>> Assuming the ebuild changes between foo-1 and foo-2 are mainly due to |
| 21 |
>> the change from EAPI=0 to EAPI=2 (which I'd expect to be true in many |
| 22 |
>> cases) you could just reuse the foo-1 ebuild for foo-3. |
| 23 |
>> |
| 24 |
>> If there are major differences between foo-1 and foo-2 not related to |
| 25 |
>> the EAPI change then the maintainer probably didn't want foo-2 to |
| 26 |
>> become stable anytime soon, so it's at least questionable if foo-3 |
| 27 |
>> should go straight to stable in the first place. |
| 28 |
>> |
| 29 |
>> And adding a new version directly to stable always comes with a risk, |
| 30 |
>> you can't eliminate that completely. It's all about risk assessment, |
| 31 |
>> and how much work you're willing to do or time you want to spend to |
| 32 |
>> minimize the risk. |
| 33 |
>> |
| 34 |
> |
| 35 |
> There's no need to commit straight to stable. Just make two different |
| 36 |
> new revisions for each EAPI. Then the arch teams can test it like usual. |
| 37 |
|
| 38 |
Aha a perfect canidate use case for GLEP 55[1] that fends off 'why are |
| 39 |
there multiple versions of the same package' questions and |
| 40 |
complexities. |
| 41 |
|
| 42 |
[1] http://www.gentoo.org/proj/en/glep/glep-0055.html |
| 43 |
|
| 44 |
> |
| 45 |
> Regards, |
| 46 |
> Petteri |
| 47 |
> |
| 48 |
> |
Archives