Created attachment 354684 [details] wakeonlan-0.41-r1.ebuild EAPI=5 Attached ebuild is updated to EAPI=5. No changes to installed files are made, so I do not believe a revbump (which would require future stabilization) is necessary. If okay, I'll commit.
Created attachment 354688 [details, diff] ebuild patch you could provide ebuild diff, so people will know what changed, also for better review ;-)
also you set DEPEND, RDEPEND empty, I think at least we should put dev-lang/perl in RDEPEND, since wakeonlan is perl script. (is dev-lang/perl belong to @system?)
(In reply to Dennis 'dlan' Lan from comment #1) > Created attachment 354688 [details, diff] [details, diff] > ebuild patch > > you could provide ebuild diff, so people will know what changed, also for > better review ;-) People complain if you attach and ebuild. People complain if you attach a diff.
(In reply to Dennis 'dlan' Lan from comment #2) > also you set DEPEND, RDEPEND empty, I think at least we should put > dev-lang/perl in RDEPEND, since wakeonlan is perl script. (is dev-lang/perl > belong to @system?) wakeonlan inherit perl-app, perl-app inherit perl-module, quote from perl-module 2|3|4|5) PERL_EXPF+=" src_prepare src_configure" [[ ${CATEGORY} == "perl-core" ]] && \ PERL_EXPF+=" pkg_postinst pkg_postrm" case "${GENTOO_DEPEND_ON_PERL:-yes}" in yes) DEPEND="dev-lang/perl[-build]" RDEPEND="${DEPEND}" ;; esac ;; so we already have DEPEND,RDEPEND correctly set? the line of DEPEND,RDPEND in ebuild could be removed?
I'll be perfectly honest, and say that no I don't want to bump this to EAPI5 without a revbump -- since the ebuild is going from pre-EAPI to 5, and there have been many a VDB change, I would rather see this revbumped and go through stabilization than the changes committed directly with stable keywords and have systems with unmatching VDB. Alternatively, unless there is something in particular requiring EAPI5 here (and I can't see anything, given there are no other deps), imo this can probably stay at zero until the perl eclasses obtain the sub-slot/slot-operator functionality that will make perl-cleaner obsolete. At which point, a revbump -will- be necessary anyhow. (I'll look into it more, though -- it's been quite a while since I ran my slot-operator patches against the tree)
(In reply to Ian Stakenvicius from comment #5) > Alternatively, unless there is something in particular requiring EAPI5 here > (and I can't see anything, given there are no other deps), imo this can > probably stay at zero until The whole purpose of the tracker (and this bug) is to get packages inheriting perl-module updated to EAPI=5...
But to what end? Bumping ebuilds to EAPI5 isn't useful in and of itself, it's only useful if there's a reason. The tracker just needs EAPI >= 4. Adding sub-slot/slot-operator support for auto-rebuilds in the eclasses -is- a reason, but that needs to be done -first- otherwise all the consumers of those eclasses need to be revbumped afterwards anyhow so that everyone's VDB syncs up with the right metadata. So since EAPI4 doesn't seem to affect VDB the same way EAPI5 does, if you're OK with that, I would be comfortable doing an in-place EAPI4 bump with {R}DEPEND unset, same as now. Alternatively, if you do really want EAPI5, I would be even more comfortable though doing it via revbump and re-stabilizing, especially given perl-5.16 isn't stable yet and so the dependency change mentioned in the tracker bug isn't needed there yet either.
You know, so far you're the only one that's put up any resistance. EAPI=4 is fine if you'll do that.
I'm also probably the only one that spent 3+ months playing with EAPI5 bumps on perl packages (and others) to deprecate perl-cleaner, and know fairly well how the VDB can end up getting messed up and how that can cause strange behaviour for end users on "emerge -uDN". :) It also relates to the recent thread on gentoo-dev@ ; essentially, that installed-files-on-disk changing isn't the only thing that needs to be taken into account during the revbump-or-not process. Now, that said, I just finished an evaluation of current vs EAPI4 vs EAPI5 vs EAPI5-with-perl-subslotted , and it seems that the end result is indeed the same no matter what. So I've just committed an EAPI5 bump in-place to portage. + 31 Jul 2013; Ian Stakenvicius <axs@gentoo.org> wakeonlan-0.41-r1.ebuild: + fixed missing dep and bumped to EAPI5 per bug 479050 +
