-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Amit Dor-Shifer wrote: > That environment.bz relates to the installed package? And "downgrading" > means I'm installing a lesser version instead of the current, and not > necessarily the prev. one in-line. I might be downgrading to a *very* > old version. > > I can see how a/m archive can aid in removing the current version. > However, the replacing package also relies on eclass code, and it might > rely on code which was already gone when I initially created the ebuild > of the current version. > > Here's an example timeline: > 1. Creating myapp-1.0, inheriting myeclass.eclass "version a". > 2. Modifying myeclass.eclass to "version b". myapp-2.0 is created. > eclass is not backward-compatible. > 3. ... > 3. Creating myapp-20.0. > > On a system with myapp-20.0 (and eclass of at-least "version b"), I > don't see how I would be able to downgrade to myapp-1.0, as "version a" > of the eclass is nowhere to be found.
Well, it you're going to break the api and you're not willing to update the api consumers, the logical thing to do is to copy myeclass.eclass to myeclass-2.eclass when you break the api. Doesn't that seem like a logical solution? - -- Thanks, Zac -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAknPLykACgkQ/ejvha5XGaPdogCcDM/k/JfVWl4jqmTzGd7QKl99 YaEAnAg8FXtMe0HwrhBwIOrxEMrS66mW =H2aK -----END PGP SIGNATURE-----
