Redefining src_install() into pimped variant of default is rather a bad idea, especially that 'readme.gentoo' ends up pretty late on 'inherit' line. Long story short, it redefines src_install() of multilib-minimal and distutils-r1. Since those eclasses define sub-phase functions for ebuilds, ebuilds scarcely need to redefine them.
I agree... but would prefer to wait for eapi6 to change the behavior :/
Could this bug please be fixed, soon, so that readme.gentoo can be used in EAPI=6? I don't care in which way - whether by removing the phase functions for EAPI=6 or not. However, I have a bunch of ebuilds in my local (and public) overlays I would like to bump to EAPI=6, finally.
@mgorny, I won't have time for looking into this until weekend. If you want to go ahead and add the eapi6 support, please go. The idea is to, instead of getting the phase exported, die with an error pointing people to explicitly call create_doc (I am unsure about how to ensure people don't forget to also call print_log in postinst :S)
[master 87ac40c] eclass/readme.gentoo.eclass: Add EAPI6 support, stop exporting functions for that EAPI as explained at bug #520094 1 file changed, 6 insertions(+), 3 deletions(-)
Anyway, if anyone know about how to remind people that they need to take care of calling the functions manually when bumping eapi... please let me know :/
(In reply to Pacho Ramos from comment #5) > Anyway, if anyone know about how to remind people that they need to take > care of calling the functions manually when bumping eapi... please let me > know :/ As far as I can see, the only way is the one suggested by ulm -- readme.gentoo-r1, and ban readme.gentoo in EAPI 6. This will give people a nice explanatory message that they need to update their ebuilds rather than silent failure on EAPI bump.
OK, thanks for the suggestion: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=efe8736bf3c14b3fe693493d4fdb2b33a4ec7f10 https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b7a859392b35066cb39b04de1c35ca55ad5ff2ff https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d0fdc3ad8814f9e1e218f809021fc5ba35e01de5
That's not the proper way of doing things, updating a general purpose eclass without any discussion in -dev. You didn't even bother to CC me to this bug. Anyway, I am now going to revert readme.gentoo.eclass to the version that I was posted to and discussed in -dev.
I did what you suggested later in gentoo-dev (this bug is opened for years) This is a complete nonsense Following gentoo-dev ML is not a must (we are not even obligued to be subscribed) What it's not a way for doing things is to completely bypass the maintained of the eclass, go to gentoo-dev ML and commit things directly without even notifying
CCing comrel for preventing a stupid commit war
This is the thread that I even wasn't CCed http://thread.gmane.org/gmane.linux.gentoo.devel/98911/focus=98913 But even with that, I finally went with your approach as discussed here with mgorny as it looked the best option On the other hand you now pretend to revert to the changes that weren't even consulted with the maintainer of the eclass and you committed directly even if it was noticed the issue of the phases by mgorny in the eclass
(In reply to Pacho Ramos from comment #9) > Following gentoo-dev ML is not a must (we are not even obligued to be > subscribed) > > What it's not a way for doing things is to completely bypass the maintained > of the eclass, go to gentoo-dev ML and commit things directly without even > notifying Sure, you are not obliged. However, we have a council's statement about this (see 2014-04-08 meeting summary): "While it is any developer's choice not to participate on the gentoo-dev and gentoo-project mailing lists, they nevertheless serve as main communication channels. If something has been discussed there, and then action has been taken, the council regards ignorance of the discussion not as a good foundation for protests against the actions." (In reply to Pacho Ramos from comment #11) > http://thread.gmane.org/gmane.linux.gentoo.devel/98911/focus=98913 Right, and I replied to it that an eclass should not make API changes under an EAPI conditional unless it is related to changes in that EAPI: http://article.gmane.org/gmane.linux.gentoo.devel/98916 There was no further reply to that, so after waiting for 3 days I committed my changes, and I believe that I followed procedure there. Therefore your revert (commit df279f7) was completely uncalled for. Policy reference: https://devmanual.gentoo.org/eclass-writing/index.html#adding-and-updating-eclasses
You didn't notify my about going to change that in three days. I am subscribed to the list but I was simply unable to read the tons of mail I had pending there. You should have simply notified me (the maintainer of the eclass) instead of: 1. Send a mail to gentoo-dev ML 2. See that there were concerns 3. Even with that, go ahead after 3 days I reverted a commit that was done without my approval and was only causing to people to start relying on the old behavior we want to avoid for new eapis
We were able to meet in IRC and talk about this :)
Closing this again. Please add EAPI 4 and 5 support to -r1, as discussed (I hope the following snippet from #gentoo-dev is not too much out of context): <ulm> but probably -r1 should support EAPIs 4 and 5, otherwise things could get nasty in other eclasses <K_F> and yeah, having support for older EAPIs makes it easier to do migration <ulm> e.g. nvidia-driver.eclass also inherits readme.gentoo <pacho2> ulm: I don't see any problem with adding support for eapis4 and 5 <pacho2> K_F: +1 <ulm> pacho2: please do
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e81e95bfd07d34b01192f4b650fcce72f0f88f50 -> done
