On Thu, 26 Mar 2020 21:11:11 +0100 Michał Górny <mgo...@gentoo.org> wrote:
> On Thu, 2020-03-26 at 14:13 -0500, William Hubbs wrote: > > There are situations in which downstream overlays need to have versions > > of python which Gentoo no longer supports in the tree. > > > > Currently, the only way to do this is for the overlay author to fork > > python-utils-r1.eclass. This is highly undesirable since it creates a > > very significant maintenance burden for the overlay author. > > Is it preferable to create the maintenance burden on Gentoo developers > instead? Is it fair that paid company developers shift the burden > on people who work on Gentoo in their free time, and already have their > plate full? We have no intention of shifting maintenance burdens anywhere, we want to make minor changes to make it easier for us to keep up. It's the same as a Gentoo developer asking an upstream project to make minor changes to their build system to support DESTDIR or a sandbox fix. > > > The simplest way would be to apply the following patch. > > In this situation, all the overlay author > > would have to do is adjust the PYTHON_COMPAT_ALLOW_EXTRA_IMPLS variable. > > ...which solves exactly zero problems because the eclass still doesn't > support the implementation in question. The best it could do is sweep > part of the problem under the carpet. We don't care if it *actually* supports it, the ebuilds in question aren't going to be installed on modern machines. We just want it to not blow up in the global scope. > Even if it miraculously works right now at all, it will probably fail or > misbehave randomly. Any eclass change might break it. Then one cheap > hack will serve as an excuse to add one more, and another.\ > > > The other option would be to move _PYTHON_ALL_IMPLS and the > > implementation of _python_impl_supported to a separate eclass, e.g. > > python-impls-r1.eclass. This eclass could be forked freely downstream > > without worrying about the other python eclasses. > > Again, this doesn't solve the problem. It just moves the problem > elsewhere. > How does this not solve the problem? Overlays could trivially support different implementations, without maintaining a lot of forks. We are quite happy to do the work to split it out to a separate eclass. > > Thoughts? > > I've already told you that if you want to fork, fork all eclasses. Then > you wouldn't have to worry about internal API going out of sync. > > Or don't autoupdate ::gentoo when eclasses change. >
