1 |
On Fri, 2006-01-27 at 09:25 -0800, Brian Harring wrote: |
2 |
> On Thu, Jan 26, 2006 at 06:10:08PM +0100, Michael Haubenwallner wrote: |
3 |
> > Hi, |
4 |
> > |
5 |
> > when talking to a colleague of mine (he's using Gentoo-Linux, and wants |
6 |
> > to use prefixed portage), an idea for the prefix-api came up: |
7 |
> > |
8 |
> > Currently, there's the PREFIX variable (among others) for the ebuilds. |
9 |
> > |
10 |
> > The idea is to substitute this with a bash-function, echoing a prefix. |
11 |
> > |
12 |
> > This function could be defined to get one argument, which is much like |
13 |
> > the same syntax as the *DEPEND settings, but only for a single package. |
14 |
> > If no argument, the current package is used. |
15 |
> > |
16 |
> > Yes, the current implementation would be simple: |
17 |
> > prefix() { |
18 |
> > echo $PREFIX |
19 |
> > } |
20 |
> > |
21 |
> > But the idea behind that is: |
22 |
> > |
23 |
> > Once portage could handle interdomain dependencies, the prefix-api need |
24 |
> > not to be changed to let ebuilds find the prefix of their dependencies. |
25 |
> > |
26 |
> > A sample ebuild-snippet: |
27 |
> > |
28 |
> > DEPEND="<my-dependency-2" |
29 |
> > |
30 |
> > econf-or-src_build() { |
31 |
> > .../configure \ |
32 |
> > --prefix=$(prefix) \ |
33 |
> > --with-my-dependency=$(prefix "<my-dependency-2") |
34 |
> > } |
35 |
> |
36 |
> Dunno about that construct; aside from violating metadata constant |
37 |
> rules (realize it's just an example), the prefix optional arg syntax |
38 |
> seems like an easy way to get bit in the ass if a variable you thought |
39 |
> was set/had a value, turned out to be [ -z ] |
40 |
> |
41 |
> Imo, PREFIX should be "this is where this ebuild is installing", |
42 |
> grabbing prefix/root location for deps should be a seperate function; |
43 |
> avoids the issue of different behaviour if an optional arg is |
44 |
> available (and the potential for people to screw it up). |
45 |
> |
46 |
|
47 |
Accepted: |
48 |
Then keep ${PREFIX} what it is, and have some kind of a |
49 |
$(prefixof "<my-dependency-2") function ? |
50 |
|
51 |
prefixof() { |
52 |
[ $# -eq 1 ] || die "prefixof requires exactly one argument." |
53 |
echo "${PREFIX}" |
54 |
} |
55 |
|
56 |
econf-or-src_build() { |
57 |
.../configure \ |
58 |
--prefix=${PREFIX} \ |
59 |
--with-my-dependency=$(prefixof "<my-dependency-2") |
60 |
} |
61 |
|
62 |
> > Another possible feature in the future (not finished thinking about yet) |
63 |
> > could be to have portage install each (non-system-)package into a |
64 |
> > separate prefix within its domain, without need to change prefix-api. |
65 |
> > This could help ebuild-devs to detect unknown dependencies, which are |
66 |
> > not found implicitly if not specified at configure-line. |
67 |
> > Well - only for a testing system, and to be enabled explicitly |
68 |
> > by setting FEATURES. |
69 |
> > |
70 |
> > What do you think about this ? |
71 |
> |
72 |
> Gnu stow attempted this- would probably be worthwhile poking them for |
73 |
> info on prefix issues. |
74 |
> |
75 |
> Granted, they're doing symlinks to maintain the appearance of a normal |
76 |
> install, but still, probably could raid a few tricks from them |
77 |
> depending on if they ever managed to build up an actual repository of |
78 |
> packages. |
79 |
|
80 |
Having those symlinks, for portage there's no more need to have distinct |
81 |
prefixes for packages, as their executables/libs/headers end up in the |
82 |
common prefix, and configure continues to find them even if not |
83 |
specified by the ebuild... |
84 |
But sure, stow-users should already have found some pitfalls. |
85 |
|
86 |
> |
87 |
> ~brian |
88 |
-- |
89 |
gentoo-osx@g.o mailing list |