On Mon, 2020-03-23 at 13:23 -0500, William Hubbs wrote: > Hey all, > > it has been brought to my attention that there have been several > backward-incompatible changes made to the python eclasses lately. > > It is true that everything in ::gentoo has been fixed along with the > changes to the eclasses; however, when a change like this goes into a > widely used eclass it breaks overlays with little to no notice; > especially since we do not require developers to be subscribed to this > mailing list. > > I do agree that overlay authors are on their own to fix things, but we need to > find a way to notify them when a breaking change is going into a widely > used eclass and give them time to adjust their ebuilds. > > If the old way of doing things cannot be supported > along side the new way the correct path forward is a new version of the > eclass then a lastrites on the old version. That would give overlay > authors time to switch to the new eclass. > > If the old and new way can be supported in the same code base, a > reasonable way forward is to allow both ways to exist while ::gentoo is > migrated to the new code path then do the equivalent of a lastrites for > the old code path so overlay authors can adjust their ebuilds. > > Thoughts? > > William >
All of this was announced with a 3 month timeout, using the right channels. Have you checked all python-related eclasses changes submitted to the ML? In this case, eqawarn would not have been possible, because the change involved dereferencing a variable. Check the git-2 debacle: 6.5 years of deprecation, and still a bunch of overlays exploded. There comes a point where you just have to suck it up and move on.
