1 |
Dnia 2014-06-15, o godz. 07:00:15 |
2 |
Rich Freeman <rich0@g.o> napisał(a): |
3 |
|
4 |
> The Eclass argument goes like this: |
5 |
> Eclasses already work in every PM. Half of what we're debating is |
6 |
> already in eutils. Why move this code into the PM, where it has to be |
7 |
> re-implemented everywhere? If anything we should be moving more PM |
8 |
> functionality out and into eclasses where we can have competing |
9 |
> implementations and more flexibility. |
10 |
|
11 |
I think this point is a bit tangential. While eclasses are the obvious |
12 |
way of having code common between package managers, I don't think |
13 |
sharing code should be an argument for putting something in an eclass. |
14 |
|
15 |
Please remember that you can create your own base repository without |
16 |
having 'gentoo' as master. Then, putting code in eclasses actually |
17 |
requires you to duplicate it -- unlike code in PM which is shared |
18 |
between all repos. |
19 |
|
20 |
|
21 |
Now, for the overall point. I think there are a few cases when you want |
22 |
something in the PM: |
23 |
|
24 |
1. when it's a common thing to do that doesn't require repository- |
25 |
specific details like relying on some out-of-@system packages, |
26 |
|
27 |
2. when it requires specific interaction with the package manager, |
28 |
|
29 |
3. when it is required by some other PM-specific code. Keeping it |
30 |
'internal' just means having duplicate code between PM and eclasses. |
31 |
|
32 |
|
33 |
I think the only debatable thing here is (1). If we ever decide that |
34 |
having common stuff in an eclass is feasible, we ought to move all |
35 |
the common stuff that's possible -- including econf, emake, possibly |
36 |
some install helpers. |
37 |
|
38 |
This may even have more benefits than that. For example, you would fit |
39 |
the implementation to specific system -- like 'gentoo' repository |
40 |
eclass would be fit for Gentoo-specific tools. Instead of putting |
41 |
requirements for a system in PMS and trying to fit PM and profiles |
42 |
together, we'd just use whatever the repository provides. |
43 |
|
44 |
Of course this brings another argument -- every single ebuild would |
45 |
have to source a specific eclass. For EAPI 6, I've focused on going |
46 |
the opposite way -- putting more commonly used stuff to EAPI so that |
47 |
many of eutils inherits could be removed. I don't have the numbers but |
48 |
I'd dare guess inheriting eutils everywhere does come with some |
49 |
overhead on metadata cache generation. |
50 |
|
51 |
|
52 |
As far as both eapply & eapply_user are concerned, I believe they both |
53 |
belong to the group of commonly used functions, so they ought to go |
54 |
into PM wrt (1). |
55 |
|
56 |
Moreover, eapply_user pretty much requires you to provide a location |
57 |
for the patches -- and putting /etc/portage into an eclass is just |
58 |
wrong. Of course, we could try some new, fancy location but well... I'd |
59 |
rather keep it as-is and consider it PM-specific, so argument (2). |
60 |
|
61 |
And if put eapply_user anyway, argument (3) says we gotta add eapply |
62 |
as well, or otherwise we'll be using two similar functions all the time |
63 |
-- one in the PM, the other in the eclass. |
64 |
|
65 |
-- |
66 |
Best regards, |
67 |
Michał Górny |