Re: [gentoo-portage-dev] version management for eclasses

[Amit Dor-Shifer]

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.

Thanks,
Amit

Zac Medico wrote:
> Amit Dor-Shifer wrote:
> > I've been through the list, and also read GLEP #33, in search for
> > recommended practices regarding eclasses.
> > the way I understand it, when an eclass is modified to accomodate a new
> > ebuild, old ebuilds are broken. Specifically, downgrading with those
> > broken ebuilds is no longer possible, as the eclass code they used to
> > execute is no longer available.
>
> > So, basically, downgrade is possible only while dependent eclasses
> > haven't changed. And AFAIK, portage doesn't test whether inherited
> > eclasses were modified since the ebuild was signed. This means that
> > there's also no traceability: old ebuilds cannot say "When I was in
> > business, my inherited eclass was THIS".
>
> > I'm wondering how do others address the downgrade issue.
>
> Since portage-2.1.4, it's not a problem because we reuse
> /var/db/pkg/*/*/environment.bz2 which contains code from the
> original version of the eclass.