[gentoo-dev] Re: Eclass vs EAPI For Utility Functions (Patching/etc)

[Steven J. Long]

On Sun, Jun 15, 2014 at 03:30:10PM +0200, Michał Górny wrote:
> Dnia 2014-06-15, o godz. 07:00:15
> Rich Freeman napisał(a):
>
> > The Eclass argument goes like this:
> > Eclasses already work in every PM.  Half of what we're debating is
> > already in eutils.  Why move this code into the PM, where it has to be
> > re-implemented everywhere?  If anything we should be moving more PM
> > functionality out and into eclasses where we can have competing
> > implementations and more flexibility.
>
> I think this point is a bit tangential. While eclasses are the obvious
> way of having code common between package managers, I don't think
> sharing code should be an argument for putting something in an eclass.

Er, it's the most fundamental argument for using an eclass.

Thought not between package managers, since they don't factor into the
equation, so long as they provide EAPI conformance (theoretically.)

> Please remember that you can create your own base repository without
> having 'gentoo' as master. Then, putting code in eclasses actually
> requires you to duplicate it -- unlike code in PM which is shared
> between all repos.

Well that's an argument for certain base functionality being in the PM
although I'd note that "in the PM" in most cases, and this one, means
"in ebuild.sh or one of its associated BASH modules."

It's not an argument for sharing script across ebuilds in general, by
putting it in the the context for every ebuild.

As for different master repos, that's an appropriate discussion at
at the package-manager code level, but not at the distro level, imo.

> Now, for the overall point. I think there are a few cases when you want
> something in the PM:
>
> 1. when it's a common thing to do that doesn't require repository-
> specific details like relying on some out-of-@system packages,
>
> 2. when it requires specific interaction with the package manager,
>
> 3. when it is required by some other PM-specific code.

That's enforced by the requirement.

> Keeping it
> 'internal' just means having duplicate code between PM and eclasses.

No: it also means you don't expose it until it's needed. The worst
thing in the world is having to rely on variant behaviour according
to the phase of the moon, which is about what you get when internal
APIs are exposed without cause and consensus.

Since you're speaking in general terms.

> I think the only debatable thing here is (1). If we ever decide that
> having common stuff in an eclass is feasible, we ought to move all
> the common stuff that's possible -- including econf, emake, possibly
> some install helpers.

I'm not sure what that's got to with out-of-@system packages, but it
sounds like a bad idea, and counter to your argument about sharing
code via the PM, and not eclasses.

> This may even have more benefits than that. For example, you would fit
> the implementation to specific system -- like 'gentoo' repository
> eclass would be fit for Gentoo-specific tools. Instead of putting
> requirements for a system in PMS and trying to fit PM and profiles
> together, we'd just use whatever the repository provides.

That sounds insane to me. What happened to reproducible builds? Let
alone a robust user experience.

Perhaps at the package-manager code level, but not at the distro level.
And it's the Gentoo PMS, so I don't see any conflict.

Though this appears to be the same "tangent" Rich brought up.

> Of course this brings another argument -- every single ebuild would
> have to source a specific eclass. For EAPI 6, I've focused on going
> the opposite way

So which way do you actually prefer?

You appear to be arguing for, and implementing, common code by EAPI,
in the rest of your mail. Since that's always been the point of
them, based on developer consensus about what is truly essential,
and what is only needed for a subset of the tree, that's fine by me.

Just so long as they are essential, and you do have consensus on
that.

> As far as both eapply & eapply_user are concerned

Why can't we just have epatch and upatch?


=
I'm on record as wanting this in the PM, btw, back when we were
discussing how it should deal with patches not being applied.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)