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