1 |
> This is all almost certainly portage v2 stuff. However I'd like everyone |
2 |
> working on portage (e.g. Bevin, with whom I've spoken) to know where we |
3 |
> stand, to coordinate our efforts. As always, any ideas, forecasts, |
4 |
> suggestions etc. are always welcome. |
5 |
|
6 |
I like the idea. If its documentation becomes part of the ebuild howto, |
7 |
it will get adopted fairly quickly. |
8 |
|
9 |
The main concern Hallski and me (and possibly others, such as John |
10 |
Stalker, if memory serves) was that the current ebuild system mirrors |
11 |
the manual build process so closely that external contributors have |
12 |
little or no difficulty sending us ebuilds. |
13 |
|
14 |
I think this can be solved somewhat if it is clearly documented _what_ |
15 |
is assumed by the various eclasses and perhaps a motivation when the |
16 |
assumptions are less than crystal clear. |
17 |
|
18 |
What plagues many non-kde ebuilds is that their build systems are fairly |
19 |
non-standard. And even packages with seemingly standard build systems |
20 |
quickly turn out to have both minor and major flaws (Mailman is a good |
21 |
example of a horrible build system that on the surface looks nice, but |
22 |
in practice turns out to be a real bitch). |
23 |
|
24 |
The minor nuisances of the various build systems mean that we might find |
25 |
it easier to patch the generated Makefiles instead of the Makefile.in or |
26 |
Makefile.am files, thus requiring an intermediate step between |
27 |
configure and make (ie, patching in src_unpack is too troublesome). |
28 |
|
29 |
Consequently a simple wrapper for src_compile will only work a certain |
30 |
percentage (possibly relatively low; <= 50%) of the time, and a |
31 |
full-blown manual src_compile() function must be written for the rest of |
32 |
the ebuilds. |
33 |
|
34 |
The situation for src_install() is even more dire, as it would appear |
35 |
that close to all packages have trouble conforming to any kind of FHS, |
36 |
and installing in a temporary directory is completely foreign. |
37 |
|
38 |
Now, for our regular ebuild writers, the 50% saving is a big deal. For a |
39 |
new submitter, it means he has to figure out which eclasses are |
40 |
available (+ what they are), which criteria his package must meet to be |
41 |
able to avail himself of the various eclasses, and finally test that |
42 |
this is really so. |
43 |
|
44 |
In conclusion, I am very positive about eclasses for our regular |
45 |
contributors; it would possibly give us yet another advantage to our |
46 |
package system that would allow us to add more ebuilds more quickly (one |
47 |
could argue that quantity in itself is not a good thing, and of course I |
48 |
agree ;). But if our intention is that "regular" users should easily |
49 |
be able to submit ebuilds, and more easily so than writing a debian |
50 |
package or an rpm spec, then we must be very careful to consider the |
51 |
result eclasses have on our "regular" users. |
52 |
|
53 |
</rant> |
54 |
|
55 |
Kind regards, |
56 |
|
57 |
Karl T |