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? > 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. 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. > 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. -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
