1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Amit Dor-Shifer wrote: |
5 |
> That environment.bz relates to the installed package? And "downgrading" |
6 |
> means I'm installing a lesser version instead of the current, and not |
7 |
> necessarily the prev. one in-line. I might be downgrading to a *very* |
8 |
> old version. |
9 |
> |
10 |
> I can see how a/m archive can aid in removing the current version. |
11 |
> However, the replacing package also relies on eclass code, and it might |
12 |
> rely on code which was already gone when I initially created the ebuild |
13 |
> of the current version. |
14 |
> |
15 |
> Here's an example timeline: |
16 |
> 1. Creating myapp-1.0, inheriting myeclass.eclass "version a". |
17 |
> 2. Modifying myeclass.eclass to "version b". myapp-2.0 is created. |
18 |
> eclass is not backward-compatible. |
19 |
> 3. ... |
20 |
> 3. Creating myapp-20.0. |
21 |
> |
22 |
> On a system with myapp-20.0 (and eclass of at-least "version b"), I |
23 |
> don't see how I would be able to downgrade to myapp-1.0, as "version a" |
24 |
> of the eclass is nowhere to be found. |
25 |
|
26 |
Well, it you're going to break the api and you're not willing to |
27 |
update the api consumers, the logical thing to do is to copy |
28 |
myeclass.eclass to myeclass-2.eclass when you break the api. Doesn't |
29 |
that seem like a logical solution? |
30 |
- -- |
31 |
Thanks, |
32 |
Zac |
33 |
-----BEGIN PGP SIGNATURE----- |
34 |
Version: GnuPG v2.0.11 (GNU/Linux) |
35 |
|
36 |
iEYEARECAAYFAknPLykACgkQ/ejvha5XGaPdogCcDM/k/JfVWl4jqmTzGd7QKl99 |
37 |
YaEAnAg8FXtMe0HwrhBwIOrxEMrS66mW |
38 |
=H2aK |
39 |
-----END PGP SIGNATURE----- |