1 |
On Thu, 2006-01-26 at 21:27 -0600, Kito wrote: |
2 |
> On Jan 26, 2006, at 11:10 AM, Michael Haubenwallner wrote: |
3 |
> |
4 |
> > The idea is to substitute this with a bash-function, echoing a prefix. |
5 |
> > |
6 |
> > This function could be defined to get one argument, which is much like |
7 |
> > the same syntax as the *DEPEND settings, but only for a single |
8 |
> > package. |
9 |
> > If no argument, the current package is used. |
10 |
> > |
11 |
> > Yes, the current implementation would be simple: |
12 |
> > prefix() { |
13 |
> > echo $PREFIX |
14 |
> > } |
15 |
> > |
16 |
> > But the idea behind that is: |
17 |
> > |
18 |
> > Once portage could handle interdomain dependencies, the prefix-api |
19 |
> > need |
20 |
> > not to be changed to let ebuilds find the prefix of their |
21 |
> > dependencies. |
22 |
> |
23 |
> So really, portage needs to imitate pkgconfig on some level, probably |
24 |
> just start by looking in the vdb, shouldn't be too hard in a single |
25 |
> domain/vdb situation. The interdomain bit is going to depend on many |
26 |
> factors unknown to me, and not something we should pursue in the |
27 |
> current 2.x codebase, but I assume saviour has at least the entry |
28 |
> points to make this possible. |
29 |
|
30 |
Sure, not in 2.x, just to be prepared. |
31 |
|
32 |
> |
33 |
> > |
34 |
> > Another possible feature in the future (not finished thinking about |
35 |
> > yet) |
36 |
> > could be to have portage install each (non-system-)package into a |
37 |
> > separate prefix within its domain, without need to change prefix-api. |
38 |
> > This could help ebuild-devs to detect unknown dependencies, which are |
39 |
> > not found implicitly if not specified at configure-line. |
40 |
> > Well - only for a testing system, and to be enabled explicitly |
41 |
> > by setting FEATURES. |
42 |
> |
43 |
> This probably isn't as crazy as you might think. With ROOT, and a |
44 |
> little more work on PREFIX, it should just be a matter of setting |
45 |
> these appropriately on a per package basis. The other possible use |
46 |
> for this would be creating package bundles with complete dep trees |
47 |
> suitable for distribution. |
48 |
|
49 |
Wow, ideas over ideas, and they all are conceivable! |
50 |
|
51 |
-haubi |
52 |
-- |
53 |
gentoo-osx@g.o mailing list |