Ian was having problems sending to the list so I am forwarding this to the list on his behalf.
----- Forwarded message from Ian Delaney <idel...@gentoo.org> ----- From: Ian Delaney <idel...@gentoo.org> To: perfin...@gentoo.org Date: Sat, 28 Feb 2015 11:05:36 +0800 Subject: Fw: [gentoo-dev] [PATCH 1/2] Document policy of not relying on implicit eclass inherits X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.25; x86_64-pc-linux-gnu) Begin forwarded message: Date: Sat, 28 Feb 2015 10:43:52 +0800 From: Ian Delaney <idel...@gentoo.org> To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [PATCH 1/2] Document policy of not relying on implicit eclass inherits On Wed, 25 Feb 2015 16:34:35 +0100 Julian Ospald <hasuf...@gentoo.org> wrote: > --- > ebuild-writing/using-eclasses/text.xml | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/ebuild-writing/using-eclasses/text.xml > b/ebuild-writing/using-eclasses/text.xml index de9ec7f..49ec23b 100644 > --- a/ebuild-writing/using-eclasses/text.xml > +++ b/ebuild-writing/using-eclasses/text.xml > @@ -26,7 +26,15 @@ link="::general-concepts/portage-cache"/>). > </p> > > <p> > -After inheriting an eclass, its provided functions can be used as > normal. Here's an example ebuild, <c>foomatic-0.1-r2.ebuild</c>, which > uses four eclasses: +After inheriting an eclass, its provided > functions can be used as normal. +</p> +<warning> > +You must not rely on provided functions of implicitly inherited > eclasses. +As an example: if you use <c>epatch</c> in your ebuild, > you <b>must</b> +inherit <c>eutils.eclass</c> directly, even if > another eclass (like distutils-r1) +already inherits it. Exceptions > to this policy must be discussed and documented. +</warning> > +<p>Here'san example ebuild, <c>foomatic-0.1-r2.ebuild</c>, which > uses four eclasses: </p> > > <codesample lang="ebuild"> This effectively illegalises the very action I have gone to pains to attempt to declare sane. While the attempt to improve or standardise a practice has merit, this text is objectionable. There are dozens of ebuilds that inherit only distutils-r1 and utilise its functions and or vars. This single change will make my commits of last 2 years a violation of policy, in a retrograde manner ofcourse. While the principle here has some merit (somewhere), this approach is declaring it a generalised policy, and unconditionally. The approach here is dogmatic and unyielding. I decided long ago the inheriting of eutils explicitly to be unwarranted duplication and a waste of bytes on the line of inherit in so many ebuilds. Now in the early stages of attempting mass conversions and with a history of 2 years of an established pattern of use, this change is now proposed which illegitimises it all. The flaw here is that it is using a black and white and reductionist approach. It presumes the validity of reducing all scenarios to a single broad sweeping rule. The impact of implicit inherits by any and all eclasses are therefore presumed to apply under this one policy. The art of programming is an art as much as it is a science, and it comes in shades of grey, at least 50 of them, not to mention rooms of various shades of pastel red. Surely by now we all grasp the variations and subtleties that crop up in writing both ebuilds and eclasses. In doing the conversions I am forced to take the old packages' ebuilds on a case by case basis. While the scenarios don't wholly equate here (those shades of grey again damn them), sweeping generalisations are what frighten me. Do not back gentoo's ebuild writers into a corner where they have to scrap their way out, under the accusing waving finger of qa. We have enough of that already. If the python eclasses or eutils were to be edited in the future, they are duty bound to not break rev dependencies. Sure there are scenarios or rationale that warrant explicit inheriting in the style you're recommending. This change doesn't allow for those that don't. It generalises. There are options. You could make a policy instead that enforces the duplication of the code of an eclass, whole or in part, and therefore avoid the need of it being inherited at all; so much for write once use many. Enough said. Off to the blue room. .-- kind regards Ian Delaney -- kind regards Ian Delaney ----- End forwarded message -----
