1 |
Yep. I'd have to maintain the old eclass in the tree, just to |
2 |
facilitate for those special downgrades. |
3 |
Thanks. Wanted to assure myself that I got that one correctly. |
4 |
Amit |
5 |
|
6 |
|
7 |
|
8 |
Zac Medico wrote: |
9 |
> Amit Dor-Shifer wrote: |
10 |
> > That environment.bz relates to the installed package? And "downgrading" |
11 |
> > means I'm installing a lesser version instead of the current, and not |
12 |
> > necessarily the prev. one in-line. I might be downgrading to a *very* |
13 |
> > old version. |
14 |
> |
15 |
> > I can see how a/m archive can aid in removing the current version. |
16 |
> > However, the replacing package also relies on eclass code, and it might |
17 |
> > rely on code which was already gone when I initially created the ebuild |
18 |
> > of the current version. |
19 |
> |
20 |
> > Here's an example timeline: |
21 |
> > 1. Creating myapp-1.0, inheriting myeclass.eclass "version a". |
22 |
> > 2. Modifying myeclass.eclass to "version b". myapp-2.0 is created. |
23 |
> > eclass is not backward-compatible. |
24 |
> > 3. ... |
25 |
> > 3. Creating myapp-20.0. |
26 |
> |
27 |
> > On a system with myapp-20.0 (and eclass of at-least "version b"), I |
28 |
> > don't see how I would be able to downgrade to myapp-1.0, as "version a" |
29 |
> > of the eclass is nowhere to be found. |
30 |
> |
31 |
> Well, it you're going to break the api and you're not willing to |
32 |
> update the api consumers, the logical thing to do is to copy |
33 |
> myeclass.eclass to myeclass-2.eclass when you break the api. Doesn't |
34 |
> that seem like a logical solution? |