Created attachment 397148 [details, diff] diff -u gquilt-0.25.ebuild gquilt-0.25-r1.ebuild gquilt-0.25.ebuild inherits distutils and requires a conversion to the new eclass and EAPI upgrade. Patches to be commited if there is no response in 2 weeks." || ( dev-util/quilt dev-util/mercurial eix outputs No matches found. for dev-util/mercurial, I hope it's dev-vcs/mercurial The python-r equiv to python_convert_shebangs -r 2 . is never normally required in ebuilds inheriting either the old or the new distutils eclass. You can double check this. gquilt-0.25-r1/work/gquilt-0.25/ has NO files normally installed to usr/share/doc/${PF}, a rarity.
This causes /usr/bin/gquilt to have an incorrect shebang
Created attachment 397172 [details, diff] gquilt-0.25-r1.ebuild.patch I propose this patch instead
(In reply to Julian Ospald (hasufell) from comment #2) > Created attachment 397172 [details, diff] [details, diff] > gquilt-0.25-r1.ebuild.patch > > I propose this patch instead Julian; inherit eutils distutils-r1 This is contentious. While it's not wrong, it's also totally superfluous. distutils-r1 implicitly inherits eutils. The only justification for adding it is on the prediction that in the future it may not, which is, well, as unlikely as ......... Your herd you choose. The split into python_install_all and python_install is perfectly correct and what I normally do. Seeing the use of python_doscript ${PN} is required, your patch is good to go, +- eutils.
oh can you also ensure purging the old on the revbump, please.
(In reply to Ian Delaney from comment #3) > (In reply to Julian Ospald (hasufell) from comment #2) > > Created attachment 397172 [details, diff] [details, diff] [details, diff] > > gquilt-0.25-r1.ebuild.patch > > > > I propose this patch instead > > Julian; > > inherit eutils distutils-r1 > This is contentious. While it's not wrong, it's also totally superfluous. > distutils-r1 implicitly inherits eutils. The only justification for adding > it is on the prediction that in the future it may not, which is, well, as > unlikely as ......... Your herd you choose. It is gentoo policy to generally not rely on implicit inherits. Not doing so caused mass commits and silent breakage in the past. If there is a group of eclasses that represents one design concept (like the new python eclasses), then that may be a different story to some extent. However, eutils isn't part of that design concept. > The split into python_install_all and python_install is perfectly correct > and what I normally do. Seeing the use of python_doscript ${PN} is > required, your patch is good to go, +- eutils. Feel free to commit it either way, I don't intend to maintain this.
(In reply to Julian Ospald (hasufell) from comment #5) > > It is gentoo policy to generally not rely on implicit inherits. I have generally committed so many ebuilds inheriting only distutils-r1 I wouldn't care to even estimate. Never heard mention of this before today. While adding it is the safest thing to do, it's also predictable that it's there to stay. > Not doing so > caused mass commits and silent breakage in the past. If there is a group of > eclasses that represents one design concept (like the new python eclasses), > then that may be a different story to some extent. However, eutils isn't > part of that design concept. may be yes may be no > Feel free to commit it either way, I don't intend to maintain this. *gquilt-0.25-r1 (23 Feb 2015) 23 Feb 2015; Ian Delaney <idella4@gentoo.org> +gquilt-0.25-r1.ebuild, -gquilt-0.25.ebuild: revbump; convert -> distutils-r1, rm old, fixes Bug #540916, endorsed in said bug
(In reply to Ian Delaney from comment #6) > (In reply to Julian Ospald (hasufell) from comment #5) > > > > It is gentoo policy to generally not rely on implicit inherits. > > I have generally committed so many ebuilds inheriting only distutils-r1 I > wouldn't care to even estimate. Never heard mention of this before today. > While adding it is the safest thing to do, it's also predictable that it's > there to stay. > > > Not doing so > > caused mass commits and silent breakage in the past. If there is a group of > > eclasses that represents one design concept (like the new python eclasses), > > then that may be a different story to some extent. However, eutils isn't > > part of that design concept. > > may be yes may be no > Definitely no. The python eclasses do not and cannot make any guarantees about the API of eutils, simply because those are different maintainers. E.g. the distutils-r1 maintainer may decide to use an internal implementation of epatch (and we already had heated discussions about the epatch implementation). When that happens, the PATCHES array of distutils-r1 will still work, but the implicit eutils inherit may suddenly be gone. Now you have lots of broken ebuilds.
Discussed with comrel, they don't agree. The eclasses are a set.
(In reply to Ian Delaney from comment #8) > Discussed with comrel, they don't agree. The eclasses are a set. I have no idea how comrel is involved in QA policies that are used since years.
caused breakage by people not following this policiy: http://thread.gmane.org/gmane.linux.gentoo.devel/77143
(In reply to Julian Ospald (hasufell) from comment #10) > caused breakage by people not following this policiy: > http://thread.gmane.org/gmane.linux.gentoo.devel/77143 caused breakage in dev-python / python herd 0 I knew you'd pick up on comrel. I was trying to not say pacho who is in comrel. It was in planning with him this whole making of bugs to unresponsive devs herds/ to do conversions came about. It was with him I discussed it, now if you're inclined, go tell him. You're being a right fighter. Pick your battles. Remember the pertinence of compromise. Now, IF the maintainers ever decided to change the structure of the long established eclass eutils and cause such mass breakage, it is they who have a case to answer for causing such mass breakage. Such a revision would require reversal, on the spot, unconditionally. They would essentially be fixing something that isn't broken and just breaking something that was perfectly fixed. Alternately, go tell mgorny to re-write the eclass to stop implicitly inheriting elcasses
