1 |
On Fri, Jan 27, 2006 at 08:10:41PM +0100, Dirk Sch??nberger wrote: |
2 |
> > > > Another possible feature in the future (not finished thinking about |
3 |
> > > > yet) |
4 |
> > > > could be to have portage install each (non-system-)package into a |
5 |
> > > > separate prefix within its domain, without need to change prefix-api. |
6 |
> > > > This could help ebuild-devs to detect unknown dependencies, which are |
7 |
> > > > not found implicitly if not specified at configure-line. |
8 |
> > > > Well - only for a testing system, and to be enabled explicitly |
9 |
> > > > by setting FEATURES. |
10 |
> > > |
11 |
> > > This probably isn't as crazy as you might think. With ROOT, and a |
12 |
> > > little more work on PREFIX, it should just be a matter of setting |
13 |
> > > these appropriately on a per package basis. The other possible use |
14 |
> > > for this would be creating package bundles with complete dep trees |
15 |
> > > suitable for distribution. |
16 |
> |
17 |
> > Wow, ideas over ideas, and they all are conceivable! |
18 |
> |
19 |
> Because we are at strange ideas, would it be possible to introduce |
20 |
> something like |
21 |
> $PREFIXES, where this is a list of directories, say |
22 |
> |
23 |
> $PREFIXES=/:/gentoo |
24 |
> |
25 |
> If I want to emerge a package, the package should be installed into the |
26 |
> first matching |
27 |
> PREFIX |
28 |
> If problems occur, say because there exist a un-manged version of some |
29 |
> package, the prefix is black-listed for this packaage, and the next |
30 |
> directory is choosen. |
31 |
|
32 |
Portage currently doeesn't really track prefix in the prefix branch; |
33 |
it's a compile time directive that just makes portage build stuff with an |
34 |
offset. Getting into what you're requesting, means portage will have |
35 |
to be aware of the prefix (and capable of swiveling it), which is |
36 |
getting into the domain side of things. |
37 |
|
38 |
That's getting into interdomain crap; current intentions (and they're |
39 |
just intentions since I haven't yet written any interdomain code) is |
40 |
that you define the domain you wish to manage; this includes a PREFIX |
41 |
definition. During resolution, that domain reaches up to the parent |
42 |
domain (PREFIX=/), and queries it for what's available and where; |
43 |
that's how it would handle satisfying a python dep when you're |
44 |
targetted prefix is home (fex). What you seem to be asking is the |
45 |
ability to state "I want this merged, globally if possible, else in a |
46 |
prefix", which is a resolver decision, and reliant on the domain |
47 |
concept. |
48 |
|
49 |
|
50 |
> This black-listing can also be done by a user. |
51 |
Currently, |
52 |
EAPI="prefix" |
53 |
means that the ebuild can be installed to *any* prefix (implicitly /); |
54 |
the change you're requesting (imo) is beyond the focus of the prefix |
55 |
branch. Prefix branch is strictly having ebuilds merged to an alt |
56 |
prefix- selection of which domain/prefix to merge to is a bit higher |
57 |
up in the design of things. |
58 |
|
59 |
~harring |