[gentoo-dev] rfc: eclass issues

[gentoo-dev] rfc: eclass issues

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 845 bytes --]

All,

I spoke with mgorny on IRC and found out what his concerns are about our
current eclasses.

First, he thinks we should get rid of base.eclass.

I know there is work going on to get rid of it, but I haven't really
looked into the status much yet. I do agree though, we shouldn't have a
general-purpose eclass like this that overrides default phase functions.
Things like this belong in PMS; not in an eclass.

The other concern he mentioned was indirectly inherited eclasses being
able to override phase functions.

He said for example that if an ebuild inherits foo and foo inherits bar,
foo should export all of the phase functions bar exports.

This may cause some boilerplating in some of the eclasses, so I'm
wondering if it would be feasible to make EXPORT_FUNCTIONS work only for
the first level of inheritance?

Thoughts?

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] rfc: eclass issues

[Rich Freeman]

On Sun, Aug 17, 2014 at 11:38 AM, William Hubbs <williamh@gentoo.org> wrote:
>
> The other concern he mentioned was indirectly inherited eclasses being
> able to override phase functions.
>

So, while I'm not sure whether getting rid of the ability to inherit
phase functions is practical/good/etc, I do think we need to think
hard on just what the purpose of an eclass is.

This is painting with broad strokes, but I do think there is a case
for distinguishing between eclasses used to simplify a large number of
closely-related packages (kde/x11/etc), and one used to provide
general support to a broad colleciton of packages (python, perl, etc -
just about anything named after a language for starters).

For the specialized case the inheritance usually isn't a problem,
since the packages that inherit it are well-controlled, and while I'm
not sure why multiple inheritance is really needed for phase
functions, it probably won't be problematic since the use is so well
controlled.

For eclasses that are broadly used, I think that even inheritance of
one layer of phase functions is problematic, let alone multiple ones.
What if the same eclass gets pulled in multiple times, etc?

Heck, we didn't even want to override things when implementing user
patches - we agreed to put it in the default function, and require it
to be called when it is overridden, but we didn't aim to automatically
call it when it is overriden because of the risk of problems.

Why do we need multiple inheritance of phase functions at all?  I can
see the convenience of allowing one layer, but I think we should
consider it a best-practice to avoid it in broadly-used eclasses,
unless there is a really good reason not to.

Rich

Re: [gentoo-dev] rfc: eclass issues

[hasufell]

William Hubbs:
> All,
> 
> I spoke with mgorny on IRC and found out what his concerns are about our
> current eclasses.
> 
> First, he thinks we should get rid of base.eclass.
> 
> I know there is work going on to get rid of it, but I haven't really
> looked into the status much yet. I do agree though, we shouldn't have a
> general-purpose eclass like this that overrides default phase functions.
> Things like this belong in PMS; not in an eclass.
> 
> The other concern he mentioned was indirectly inherited eclasses being
> able to override phase functions.
> 
> He said for example that if an ebuild inherits foo and foo inherits bar,
> foo should export all of the phase functions bar exports.
> 
> This may cause some boilerplating in some of the eclasses, so I'm
> wondering if it would be feasible to make EXPORT_FUNCTIONS work only for
> the first level of inheritance?
> 
> Thoughts?

I think the first thing to do and which already happened with e.g.
qmake-utils.eclass is to make a very strong distinction between utility
eclasses and those that export phase functions.

And yeah, disabling indirect exports would at worst cause some minor
boilerplating in eclasses (as in... you have to actually call
foo_src_compile() { base_src_compile ; } AND export it) instead of
ebuilds. That's reasonable IMO and makes them more readable and predictable.

In addition, we should probably fix the manpage format of the eclasses
with an explicit section about exported functions, so you don't have to
search for that info manually.

Re: [gentoo-dev] rfc: eclass issues

[Rich Freeman]

On Mon, Aug 18, 2014 at 8:12 AM, hasufell <hasufell@gentoo.org> wrote:
>
> I think the first thing to do and which already happened with e.g.
> qmake-utils.eclass is to make a very strong distinction between utility
> eclasses and those that export phase functions.
>

Discussion on IRC the other day was moving in this direction as well.
My email was almost contemplating a technical way of doing this, but
I'm not entirely convinced that we could ever make a clean distinction
between these.  Certainly preventing automatic multiple inheritance
would help though.

I think that we should take a utility-vs-"wraparound" approach to
eclass design.  Each eclass should fall into one of the two categories
and follow the principles for that category.  I'm defining
"wraparound" as shorthand for eclasses that export phase functions
because often these eclasses do all the heavy lifting, with the ebuild
just being a wrapper.

Utility eclasses are pretty well-understood.  They generally shouldn't
export phase functions, and they can be used by a broad assortment of
ebuilds (anything that uses an scm, a language, init helpers, manpage
helpers, doc helpers, etc).  They should export functions that do one
thing well, and which stay out of the way unless called on.

Wraparound eclasses are designed more for cases where ebuilds just
declare variables and minimize their functionality by relying on
inherited phase functions - the ebuild might not even implement any
phase functions.  For example, KDE ebuilds all share a lot of common
logic from the eclass and just tell it which package they are
building.  They mostly share the same upstream, and they mostly share
the same maintainers.  This maximizes the upsides and minimizes the
downsides of heavily automated eclasses.

We get into trouble when we use wraparound eclasses:
1.  With a broad assortment of ebuilds.
2.  With many individual ebuild maintainers.
3.  For things like languages or genres.
4.  In situations where multiple wraparound eclasses could apply.

I think in an ideal world we'd only have pure utility and wraparound
eclasses.  Utility eclasses would be used by "procedural" ebuilds
where the execution flow is in the ebuild and it calls down to the
eclass.  Wraparound eclasses would be used by "declarative" ebuilds
where the execution flow is in the eclass, and the ebuild just
provides information that directs this flow.  I think that is
potentially a more powerful model, but only to the extent that you can
write a single eclass that can handle a broad set of build/install
systems/needs.

So, for tomorrow I'm leaning towards:
1.  Let's not ditch the status quo just yet.
2.  Let's not expand eclass phase function logic any further.
3.  Let's have some real discussion around what the actual problems
are, and whether we can start moving towards tagging all our existing
eclasses as utility vs wraparound.

Oh, and I think the term "wraparound" sucks, so if somebody has a
better one please toss it out there...

--
Rich