1 |
On Tue, 14 Oct 2008 10:59:39 +0200 |
2 |
Jose Luis Rivero <yoswink@g.o> wrote: |
3 |
|
4 |
> On Mon, Oct 13, 2008 at 05:38:34PM -0700, Donnie Berkholz wrote: |
5 |
> > On 02:03 Tue 14 Oct , Jose Luis Rivero wrote: |
6 |
> > > |
7 |
> > > There are some others sceneries but are not so common as the one |
8 |
> > > presented could be. Any decent solution for this case? |
9 |
> > |
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 |
> |
16 |
> EAPI-2 to EAPI-0 could imply lot of changes (not talking about what is |
17 |
> going to happen when we release new and more feature rich EAPIs), and |
18 |
> changes usually come with bugs. The ebuild is committed directly to |
19 |
> stable implies bugs in stable, which for me is a no-go. |
20 |
|
21 |
Assuming the ebuild changes between foo-1 and foo-2 are mainly due to |
22 |
the change from EAPI=0 to EAPI=2 (which I'd expect to be true in many |
23 |
cases) you could just reuse the foo-1 ebuild for foo-3. |
24 |
|
25 |
If there are major differences between foo-1 and foo-2 not related to |
26 |
the EAPI change then the maintainer probably didn't want foo-2 to |
27 |
become stable anytime soon, so it's at least questionable if foo-3 |
28 |
should go straight to stable in the first place. |
29 |
|
30 |
And adding a new version directly to stable always comes with a risk, |
31 |
you can't eliminate that completely. It's all about risk assessment, |
32 |
and how much work you're willing to do or time you want to spend to |
33 |
minimize the risk. |
34 |
|
35 |
> > - Backport the security patch to the EAPI=0 ebuild |
36 |
> |
37 |
> Which sometimes is going to be impossible, require lot of work, and we |
38 |
> fall into the risk of bad backported patches when non trivial backport |
39 |
> patches are needed (which turns into buggy patches in the stable |
40 |
> branch) |
41 |
|
42 |
And sometimes it's a very viable option when patches are provided by |
43 |
upstream. |
44 |
|
45 |
In the end at least one of the above solutions should work in |
46 |
almost every case. It might sometimes cause a bit more work than a bump |
47 |
that doesn't involve any EAPI changes, but that's life. |
48 |
If you have a real case where both suggested solutions aren't |
49 |
realistic I'd like to hear about it, otherwise I think we're wasting |
50 |
time making up solutions for a non-existant problem |
51 |
|
52 |
Marius |
53 |
|
54 |
-- |
55 |
Public Key at http://www.genone.de/info/gpg-key.pub |
56 |
|
57 |
In the beginning, there was nothing. And God said, 'Let there be |
58 |
Light.' And there was still nothing, but you could see a bit better. |