On 3/27/20 4:12 PM, Alec Warner wrote: > On Fri, Mar 27, 2020 at 3:54 PM Patrick McLean <chutz...@gentoo.org > <mailto:chutz...@gentoo.org>> wrote: > > On Fri, 27 Mar 2020 15:51:35 -0700 > Alec Warner <anta...@gentoo.org <mailto:anta...@gentoo.org>> wrote: > > > On Fri, Mar 27, 2020 at 3:11 PM Patrick McLean > <chutz...@gentoo.org <mailto:chutz...@gentoo.org>> wrote: > > > > > On Fri, 27 Mar 2020 14:48:53 -0700 > > > Matt Turner <matts...@gentoo.org <mailto:matts...@gentoo.org>> > wrote: > > > > > > > On Thu, Mar 26, 2020 at 2:03 PM Patrick McLean > <chutz...@gentoo.org <mailto:chutz...@gentoo.org>> > > > 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:zmed...@gentoo.org> > > 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
signature.asc
Description: OpenPGP digital signature
