[gentoo-dev] [PATCH 1/2] Document policy of not relying on implicit eclass inherits]

[Jason Zaman]

Ian was having problems sending to the list so I am forwarding this to
the list on his behalf.

----- Forwarded message from Ian Delaney <idella4@g.o> -----

From: Ian Delaney <idella4@g.o>
To: perfinion@g.o
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 <idella4@g.o>
To: gentoo-dev@l.g.o
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 <hasufell@g.o> 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 -----