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

[Zac Medico]

On 3/27/20 4:12 PM, Alec Warner wrote:
> On Fri, Mar 27, 2020 at 3:54 PM Patrick McLean <chutzpah@g.o
> <mailto:chutzpah@g.o>> wrote:
>
>     On Fri, 27 Mar 2020 15:51:35 -0700
>     Alec Warner <antarus@g.o <mailto:antarus@g.o>> wrote:
>
>     > On Fri, Mar 27, 2020 at 3:11 PM Patrick McLean
>     <chutzpah@g.o <mailto:chutzpah@g.o>> wrote:
>     >
>     > > On Fri, 27 Mar 2020 14:48:53 -0700
>     > > Matt Turner <mattst88@g.o <mailto:mattst88@g.o>>
>     wrote:
>     > > 
>     > > > On Thu, Mar 26, 2020 at 2:03 PM Patrick McLean
>     <chutzpah@g.o <mailto: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 <mailto: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.

The ebuilds may or may not be usable, depending on the snapshot of
::gentoo eclasses that they're paired with.

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

We do use a frozen snapshot of ::gentoo on older machines. The issue is
that we've got a repository of ebuilds that can be used with many
different snapshots of ::gentoo, but we'd like to be able to support
python implementations that may not be officially supported by a
particular snapshot of ::gentoo eclasses.

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

If you break us then that's fine, we'll deal with it. We're just asking
for a way to tweak the set supported of python implementations, and
whether or not those implementations actually work in practice is not an
upstream gentoo problem.
-- 
Thanks,
Zac