For a newcomer developer to Gentoo, it is difficult to decide which eclass and functions will be used in an ebuild. kde5.eclass let's say inherits cmake-utils.eclass and in kde releated packages cmake-utils isn't needed. But until I was told that at irc, I wrote the ebuilds in the wrong way. It would be great if there was some kind of tree representation for the eclasses in a diagram or at least information that will make clear which eclass to use and when
(In reply to Petross404(Petros S) from comment #0) > kde5.eclass let's say inherits cmake-utils.eclass and in kde releated > packages cmake-utils isn't needed. But until I was told that at irc, I wrote > the ebuilds in the wrong way. I don't think explicitly inheriting the eclasses that you use in your ebuild is `the wrong way`. Eclasses have include guards anyway, so you don't lose much by stating them explicitly. Adding QA to CC for their opinions on relying on implicit inherits in eclasses.
Actually, I had eclassdoc patches to document which eclasses are included in the API of given eclass, i.e. which ones you shouldn't explicitly inherit. Except that I've lost interest in the topic as a result of the intensive 'I want you to rewrite everything because I like _ more than -' bikeshed.
I think this has been discussed before, but implicit inherits are generally bad, if only for visibility reasons. Otherwise, changing eclass relationships can lead to ebuild breakage -- we saw this a lot, for example, when removing base.eclass, since a lot of ebuilds inherited eutils only through base.eclass and so they broke when we removed their base.eclass inherits.
In general of course one should inherit exactly what they use and not rely on transitive dependencies. There are some grey areas or exceptions of course. Using the example of kde5.eclass from comment #0, cmake-utils is used so heavily that many of the functions it exports are essentially treated as part of kde5.eclass API too. I assume Petros was inherited cmake-utils as well as kde5 and was told not to bother (which is KDE team's preferred style), or didn't inherit it and was told it's necessary (which is often the case for other eclasses like versionator or multilib). I think the solution is to clarify in the devmanual (if it's not already there) that implicit inherits are not to be relied upon unless explicitly documented in the eclass, then do that eclass documentation.
(In reply to Michael Palimaka (kensington) from comment #4) > I assume Petros was inherited cmake-utils as > well as kde5 and was told not to bother (which is KDE team's preferred > style) That is the case. My whole point is how to tell which eclass to use and where. How can we solve this in the documentation?
(In reply to Petross404(Petros S) from comment #5) > How can we solve this in the documentation? Each individual eclass doc would need to be updated. mgorny mentioned he has such patches but it's not clear if they will be shared or not.
(In reply to Michael Palimaka (kensington) from comment #6) > (In reply to Petross404(Petros S) from comment #5) > > How can we solve this in the documentation? > > Each individual eclass doc would need to be updated. mgorny mentioned he has > such patches but it's not clear if they will be shared or not. I meant only adding new @tag for it. And actually, I haven't actually gotten to implementing this one.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/kde.git/commit/?id=3bcc9956ad8f2669d6e6b17f42c5ee541d6dfd34 commit 3bcc9956ad8f2669d6e6b17f42c5ee541d6dfd34 Author: Michael Palimaka <kensington@gentoo.org> AuthorDate: 2017-09-13 13:18:35 +0000 Commit: Michael Palimaka <kensington@gentoo.org> CommitDate: 2017-09-13 13:18:47 +0000 kde5.eclass: improve documentation Bug: https://bugs.gentoo.org/629642 eclass/kde5.eclass | 65 +++++++++++++++++++++++++++++++++++++----------------- 1 file changed, 45 insertions(+), 20 deletions(-)}
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c0a54c9fd461c839f2fe53dd8b5bbfe766e6b6d5 commit c0a54c9fd461c839f2fe53dd8b5bbfe766e6b6d5 Author: Michael Palimaka <kensington@gentoo.org> AuthorDate: 2017-09-13 13:18:35 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2017-10-26 08:22:31 +0000 kde5.eclass: improve documentation Bug: https://bugs.gentoo.org/629642 eclass/kde5.eclass | 65 +++++++++++++++++++++++++++++++++++++----------------- 1 file changed, 45 insertions(+), 20 deletions(-)}
(In reply to Michael Palimaka (kensington) from comment #4) > I think the solution is to clarify in the devmanual (if it's not already > there) that implicit inherits are not to be relied upon unless explicitly > documented in the eclass, then do that eclass documentation. Could you provide a patch for the devmanual? The ebuild-writing/using-eclasses/ chapter might be a good place for it.
