Re: [gentoo-dev] [PATCH] Split python implementations definition to separate eclass

[Alec Warner]

On Fri, Mar 27, 2020 at 3:54 PM Patrick McLean <chutzpah@g.o> wrote:

> On Fri, 27 Mar 2020 15:51:35 -0700
> Alec Warner <antarus@g.o> wrote:
>
> > On Fri, Mar 27, 2020 at 3:11 PM Patrick McLean <chutzpah@g.o>
> wrote:
> >
> > > On Fri, 27 Mar 2020 14:48:53 -0700
> > > Matt Turner <mattst88@g.o> wrote:
> > >
> > > > On Thu, Mar 26, 2020 at 2:03 PM Patrick McLean <chutzpah@g.o>
>
> > > wrote:
> > > > >
> > > > > This patch splits the definition of _PYTHON_ALL_IMPLS and
> > > > > _python_impl_supported to a separate eclass, this allows overlays
> > > > > to easily support a different set of python implementations than
> > > > > ::gentoo without having to fork the entire suite of eclasses.
> > > >
> > > > (I think the issue is that you have some packages that still need
> > > > Python 3.4. Correct me if I'm wrong)
> > > >
> > > > How many packages do you need to work with Python 3.4? Presumably
> just
> > > > a couple and then a pile of dependencies in ::gentoo?
> > > >
> > >
> > > For our particular purpose, it's more complicated than that. We do not
> > > expect or want ::gentoo to try support Python 3.4 in any way. We have
> an
> > > overlay that is shared on a lot of machines, some of those machines are
> > > older than others. As such we still have ebuilds that only support
> > > python3_4 that still exist in the overlay. We would like it if the
> > > existence of these packages in the overlay, do not cause metadata
> > > generation or dependency calculation to explode on the more up-to-date
> > > machines.
> > >
> >
> > > We do not need Python 3.4 packages to be installable on the newer
> > > machines, we just need them not to explode.
> > >
> >
> > Couldn't you simply remove the ebuilds from the overlay entirely in this
> > case? It's my understanding that on the machines with the packages
> > installed, the merged package metadata is being used (which is why those
> > machines work) and since the newer machines don't have this merged
> package
> > metadata, they don't work properly.
> >
>
> Sometimes we have to fix the older machines, so we have to keep
> everything around until none of our machines are using it any more.
>

+Zac Medico <zmedico@g.o>

I'm not following something then. One of the proposals earlier was "do not
generate metadata for these ebuilds" which to me reads as "keep these
ebuilds in the repo, but the ebuilds themselves will not be usable[0]."
Then you go on to say that old machines need to be fixed occasionally, so
either you need to reinstall a package or update it. The reinstall might be
strictly possible from the vdb metadata, but the upgrade would require
working repository metadata, which we said earlier we didn't want to
generate.

(There is a different question of whether you could use a binpkg binhost to
basically build versions of these packages and use those for reinstalls,
because at least the binpkg metadata *is* nominally fixed in time and can
be re-used easily and doesn't require eclass magic in theory, as the
eclasses are bound in the environment.tar?) I suspect in essence it might
be easier to just do what Robin suggested and use a frozen ::gentoo on the
older machines.

-A

[0] Perhaps the earlier proposals were ..slightly off. With more
information it seems like what you want is to be able to easily maintain
some python-3.4 ebuilds in your overlay, even though Gentoo is on to 3.6
(and soon 3.7). I personally think the conversation would have gone much
better had you just come out and said "hey we have a bunch of internal
overlays with 3.4 and we need to keep the packages for another N months,
how can we do this easily?" Instead of whatever happened. I tend to agree
with mgorny that it's not simply carrying this single patch, but in reality
it's a stronger commitment to build some kind of method to let you continue
to support older python versions. Future changes might impact your ability
to support your ebuilds and we have no real way of knowing if we broke
you..so I can see why (irrespective of the tone of the conversation) he
would be reticent to pick that up.


>
> > >
> > > I am trying to come up with a solution that *any* overlay can use, I
> > > am happy to do work towards that end. Basically, it would be very
> > > nice if there was a minimal eclass that handles all the python
> > > version compatibility. Almost everything in the eclasses does not care
> > > about versions.
> > >
> > > This is not meant to be something just for our usage, we want this to
> > > be usable for *any* overlay, and are more than happy to make things as
> > > generic as possible. If some overlay wants to support Python 3.10
> alpha,
> > > resurrect jython support, or add Ironpython support, without forking
> > > all the eclasses, I would like to think that could be doable as well.
> > >
> > >
>
>