[gentoo-portage-dev] version management for eclasses

[gentoo-portage-dev] version management for eclasses

[Amit Dor-Shifer]

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.

Thanks,
Amit

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

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)

iEYEARECAAYFAknLsWIACgkQ/ejvha5XGaNRnwCgk5qg9xpvAlgbik81ZqNvFWWb
v4MAnj7lhwH/VMuUeRiD/BKFLv1ILdhS
=yZQQ
-----END PGP SIGNATURE-----

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.

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

[Zac Medico]

-----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-----

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

[Amit Dor-Shifer]

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?