1 |
Note: pardon the dual post, resending this since I managed to leave a |
2 |
subject off of... any discussion regarding this, please start the thread |
3 |
from this message... sorry about that :-) |
4 |
|
5 |
Currently portage bundles all do* and new* scripts that ebuilds use with |
6 |
each release. In other words, the current breakage w/ dohtml -R not |
7 |
handling files w/ spaces correctly is tied to a portage version |
8 |
(<=.51_pre13). Prior releases of portage will remain broke, |
9 |
since the fix is tied to a portage release. |
10 |
|
11 |
To head off the 'they should upgrade', yes, having a current portage is |
12 |
important- that doesn't mean we can't split these files out so that they |
13 |
*aren't* tied to a release. |
14 |
|
15 |
Gentoo's pkg system is basically composed of two things; portage, the |
16 |
executor of ebuild instructions, and the tree, the data for |
17 |
compilation/installation of src. Currently portage is basically |
18 |
providing a collection of scripts/functions that are strictly used by |
19 |
the ebuilds, basically a library of functions/scripts- basically 'data' |
20 |
in the exec portion. |
21 |
|
22 |
This 'library' should be placed into the tree, since portage isn't aware |
23 |
of the scripts/functions even existing for the most part. The do* and |
24 |
new* scripts are specific to the customs we have for our tree, not |
25 |
portage. |
26 |
|
27 |
The scripts are kind of a no brainer for moving- what I'm also |
28 |
proposing, is the creation of an ebuild-base eclass that is |
29 |
automatically inherited, and lives in the tree. |
30 |
|
31 |
Same thing, moving functions out of portage that are specific to our |
32 |
tree, into the tree. |
33 |
|
34 |
Fex: the amd64 crew is after being able to overload econf so that they |
35 |
can specify where the 64bit libs should live; as it stands, they're |
36 |
stuck until it's in a portage release. If econf lived in the |
37 |
ebuild-base class, this change could be flipped on regardless of the |
38 |
users portage version. |
39 |
|
40 |
The embedded crew are after something similar- see bug #55476, basically |
41 |
need an addition to econf to do tweaks to configure scripts; as it |
42 |
stands, they must wait for it a release. |
43 |
|
44 |
The point of all of this is that these functions/scripts *aren't* |
45 |
specific to portage the package, they're specific to our tree, |
46 |
specifically the tree *at that moment* I'd assume when it was decided |
47 |
we would have these functions available for our ebuilds, they wound up |
48 |
in the portage src for lack of a better place, which I view as the wrong |
49 |
location. |
50 |
|
51 |
Ebuild-base.eclass would hold econf, emake, ins*, and a few other |
52 |
functions. |
53 |
|
54 |
Assuming people have read this far, and agree, and this is actually |
55 |
undertaken, the scripts/ebuild-base class should be controlled by a |
56 |
herd- those who know the tree in and out would be best for the herd. |
57 |
Basically, grab those who already are already doing serious QA of the |
58 |
ebuilds in the tree. |
59 |
|
60 |
As for actually doing these moves, it's pretty straightforward. |
61 |
Transferring the scripts out of portage pretty much consists of a PATH |
62 |
addition in a portage release, for auto-inheriting ebuild-base.eclass, |
63 |
addition of another src statement. About it. |
64 |
|
65 |
So... thoughts? |
66 |
~brian |