Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 494208 - games.eclass: deprecate base.eclass inherit for EAPI=6
Summary: games.eclass: deprecate base.eclass inherit for EAPI=6
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: Gentoo Games
URL:
Whiteboard:
Keywords:
: 497028 (view as bug list)
Depends on:
Blocks: 497022 games.eclass
  Show dependency tree
 
Reported: 2013-12-13 20:51 UTC by Julian Ospald
Modified: 2021-04-07 10:29 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
games.eclass.patch (games.eclass.patch,1.11 KB, patch)
2013-12-13 20:51 UTC, Julian Ospald
Details | Diff
Summary of changed phase functions in ebuilds (phase-changes.txt,55.85 KB, text/plain)
2015-11-22 21:43 UTC, Michał Górny
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Julian Ospald 2013-12-13 20:51:38 UTC
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.
Comment 1 Julian Ospald 2013-12-13 20:52:49 UTC
qa is CCed because they are the eclass maintainers...
Comment 2 Julian Ospald 2014-01-04 22:24:54 UTC
*** Bug 497028 has been marked as a duplicate of this bug. ***
Comment 3 Julian Ospald 2014-01-04 23:10:02 UTC
@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.
Comment 4 Julian Ospald 2014-03-17 17:18:50 UTC
hello
Comment 5 Julian Ospald 2014-03-22 22:37:06 UTC
seems QA cannot help us here, so I will just apply this once EAPI=6 enters the tree
Comment 6 Sergey Popov gentoo-dev 2014-03-25 16:23:30 UTC
(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.
Comment 7 Julian Ospald 2014-03-25 16:42:53 UTC
(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.
Comment 8 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2014-03-26 02:14:50 UTC
(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.
Comment 9 Julian Ospald 2014-04-01 12:07:30 UTC
(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.
Comment 10 Sergey Popov gentoo-dev 2014-04-07 11:29:15 UTC
(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.
Comment 11 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-11-22 08:43:16 UTC
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
Comment 12 Mr. Bones. (RETIRED) gentoo-dev 2015-11-22 14:34:52 UTC
I expect some evidence of breakage before a commit reversion.
Comment 13 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-11-22 19:39:04 UTC
(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/
Comment 14 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-11-22 21:43:06 UTC
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...
Comment 15 Mr. Bones. (RETIRED) gentoo-dev 2015-11-23 06:08:13 UTC
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.
Comment 16 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-11-23 16:05:07 UTC
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.
Comment 17 Ulrich Müller gentoo-dev 2021-04-07 10:29:21 UTC
games.eclass is going away, so nobody is going to port it to EAPI 6. Closing.