Created attachment 365280 [details, diff] games.eclass.patch base.eclass does almost not provide anything special on top of the regular PMS functions. If someone really needs it he can still explicitly inherit base. Currently, base.eclass can and does cause troubles, because of the implicit phase function overrides. Deprecating it when EAPI=6 hits the tree would make things a bit easier and cleaner. So we would have less exported functions and less inherited eclasses without really losing any crucial functionality.
qa is CCed because they are the eclass maintainers...
*** Bug 497028 has been marked as a duplicate of this bug. ***
@QA ...do you plan to remove it entirely? I'd rather have it deprecated with a newer EAPI than cleaning all games ebuilds. There are about 2-3 people actively working on games ebuilds and some ebuilds include proprietary stuff that cannot easily be tested. I'd advise against removing it retroactively.
hello
seems QA cannot help us here, so I will just apply this once EAPI=6 enters the tree
(In reply to Julian Ospald (hasufell) from comment #5) > seems QA cannot help us here, so I will just apply this once EAPI=6 enters > the tree What help from us do you need? We advised to migrate away from base eclass when it's possible as fast as you can. Some eclasses are already migrated, some are still not.
(In reply to Sergey Popov from comment #6) > (In reply to Julian Ospald (hasufell) from comment #5191) > > seems QA cannot help us here, so I will just apply this once EAPI=6 enters > > the tree > > What help from us do you need? Maybe answering my question for example.
(In reply to Julian Ospald (hasufell) from comment #7) > (In reply to Sergey Popov from comment #6) > > (In reply to Julian Ospald (hasufell) from comment #5191) > > > seems QA cannot help us here, so I will just apply this once EAPI=6 enters > > > the tree > > > > What help from us do you need? > > Maybe answering my question for example. The question "do you plan to remove it entirely?" has been answered (eg. in https://bugs.gentoo.org/show_bug.cgi?id=497022#c0); as to how, that depends on some factors to be determined. At this moment, there are other bugs on the tracker and I think that QA should only really evaluate how to proceed with this bug at the moment that it is one of the last remaining bugs; there is no intent in breaking stuff, therefore I think QA should then consider reasons like: > I'd rather have it deprecated with a newer EAPI than cleaning all games ebuilds. There are about 2-3 people actively working on games ebuilds and some ebuilds include proprietary stuff that cannot easily be tested.
(In reply to Tom Wijsman (TomWij) from comment #8) > (In reply to Julian Ospald (hasufell) from comment #7201) > > (In reply to Sergey Popov from comment #6202) > > > (In reply to Julian Ospald (hasufell) from comment #5191203) > > > > seems QA cannot help us here, so I will just apply this once EAPI=6 enters > > > > the tree > > > > > > What help from us do you need? > > > > Maybe answering my question for example. > > The question "do you plan to remove it entirely?" has been answered (eg. in > https://bugs.gentoo.org/show_bug.cgi?id=497022#c0204); No, there is no word about that. > as to how, that > depends on some factors to be determined. At this moment, there are other > bugs on the tracker and I think that QA should only really evaluate how to > proceed with this bug at the moment that it is one of the last remaining > bugs; there is no intent in breaking stuff, therefore I think QA should then > consider reasons like: > I don't see any new information here.
(In reply to Julian Ospald (hasufell) from comment #9) > (In reply to Tom Wijsman (TomWij) from comment #8) > > (In reply to Julian Ospald (hasufell) from comment #7201) > > > (In reply to Sergey Popov from comment #6202) > > > > (In reply to Julian Ospald (hasufell) from comment #5191203) > > > > > seems QA cannot help us here, so I will just apply this once EAPI=6 enters > > > > > the tree > > > > > > > > What help from us do you need? > > > > > > Maybe answering my question for example. > > > > The question "do you plan to remove it entirely?" has been answered (eg. in > > https://bugs.gentoo.org/show_bug.cgi?id=497022#c0204); > > No, there is no word about that. > > > as to how, that > > depends on some factors to be determined. At this moment, there are other > > bugs on the tracker and I think that QA should only really evaluate how to > > proceed with this bug at the moment that it is one of the last remaining > > bugs; there is no intent in breaking stuff, therefore I think QA should then > > consider reasons like: > > > > I don't see any new information here. Base eclass will be eliminated, that's why we strongly suggest to move away from using it. I thought that this is obvious, but if you need clear confirmation on this - here it is.
The change was done retroactively with high risk of package breakage due to exported functions change. I've therefore quickly reverted it on behalf of QA. For more information and review, please see https://archives.gentoo.org/gentoo-dev/message/37094a3177e6a938254173595775521a
I expect some evidence of breakage before a commit reversion.
(In reply to Mr. Bones. from comment #12) > I expect some evidence of breakage before a commit reversion. I'm sorry but I'm not aware of any policy enforcing such a requirement. If you believe there is one, please point me to it. However, there is a policy [1] stating: > When removing a function or changing the API of an eclass, make sure that it > doesn't break any ebuilds in the tree, and post a notice to gentoo-dev > at least 30 days in advance, preferably with a patch included. second part of which you surely didn't follow, and the first one I can only guess you didn't. Nevertheless, I'm going to test for this. However, as you can imagine, doing a tree-wide check like this takes a lot of time, so it is not yet even halfway there. [1]:https://devmanual.gentoo.org/eclass-writing/
Created attachment 417608 [details] Summary of changed phase functions in ebuilds Here's the proof of breakage. 794 ebuilds change used phase functions. In most cases, they are replaced by default which means PATCHES and epatch_user suddenly stop working. In some cases they are replaced by other eclasses, including cmake-utils, java-pkg-2, perl-module...
Yes, changing to the functions other than the ones from base.eclass was the goal. So I agree you've shown (expected) changes, but I'm still not seeing any evidence of breakage. If you have an example of a package that broke because of the change that would be productive.
I'm sorry but you are mistaking me with your servant. It is *you* who wants to change API of the eclass, so it's *your* responsibility to check all packages for potential breakage and *fix* it *before* committing the change. I've did the hardest part for you already. Now you have a list of packages you need to either test or analyze. I suggest you check all that lose src_prepare() for use of PATCHES and user patches on user's systems. For the latter, I think you can skip binary packages. Plus the few packages that have their phases replaced by other eclasses need checking what is going to change.
games.eclass is going away, so nobody is going to port it to EAPI 6. Closing.