Yep. I'd have to maintain the old eclass in the tree, just to
facilitate for those special downgrades.
Thanks. Wanted to assure myself that I got that one correctly.
Amit
Zac Medico wrote:
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?
