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

["Michał Górny" <mgorny@gentoo.org>]

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

Dnia 2014-06-15, o godz. 07:00:15
Rich Freeman <rich0@gentoo.org> 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.

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.


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. Keeping it
'internal' just means having duplicate code between PM and eclasses.


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.

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.

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 -- putting more commonly used stuff to EAPI so that
many of eutils inherits could be removed. I don't have the numbers but
I'd dare guess inheriting eutils everywhere does come with some
overhead on metadata cache generation.


As far as both eapply & eapply_user are concerned, I believe they both
belong to the group of commonly used functions, so they ought to go
into PM wrt (1).

Moreover, eapply_user pretty much requires you to provide a location
for the patches -- and putting /etc/portage into an eclass is just
wrong. Of course, we could try some new, fancy location but well... I'd
rather keep it as-is and consider it PM-specific, so argument (2).

And if put eapply_user anyway, argument (3) says we gotta add eapply
as well, or otherwise we'll be using two similar functions all the time
-- one in the PM, the other in the eclass.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]