Gentoo Archives: gentoo-dev

From: Brian Harring <ferringb@g.o>
To: gentoo-dev@l.g.o
Cc: carpaski@g.o, solar@g.o, amd64@g.o
Subject: [gentoo-dev] Moving functionality out of portage and into the tree
Date: Thu, 29 Jul 2004 09:35:09
Message-Id: 1091093795.6180.6.camel@6-allhosts
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 :-)
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.
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.
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.
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.
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.
31 Same thing, moving functions out of portage that are specific to our
32 tree, into the tree.
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.
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.
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.
51 Ebuild-base.eclass would hold econf, emake, ins*, and a few other
52 functions.
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.
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.
65 So... thoughts?
66 ~brian


File name MIME type
signature.asc application/pgp-signature