Dnia 2014-06-15, o godz. 07:00:15 Rich Freeman <ri...@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
signature.asc
Description: PGP signature
