1 |
On 06:33 Sat 19 Apr , Ciaran McCreesh wrote: |
2 |
> On Fri, 18 Apr 2008 22:27:21 -0700 |
3 |
> Donnie Berkholz <dberkholz@g.o> wrote: |
4 |
> > My interpretation is pkg_* counts as runtime (I can imagine a package |
5 |
> > wanting to run itself at this point), so packages in RDEPEND should |
6 |
> > be usable at that point. |
7 |
> |
8 |
> Which would be fine, except it makes the tree unusable. |
9 |
|
10 |
Isn't this part of the first situation offered (RDEPEND+DEPEND, rather |
11 |
than RDEPEND|DEPEND)? |
12 |
|
13 |
I don't think I understand the difference between the effects of these |
14 |
two options. Could you describe a scenario where one would make things |
15 |
possible and the other wouldn't? Here's my attempt from an ebuild dev's |
16 |
POV, not from an ebuild dependency POV: |
17 |
|
18 |
The way I'm thinking, the RDEPEND|DEPEND case means an ebuild developer |
19 |
would have no idea which list would be used, so you'd have something |
20 |
like COMMON_DEPEND to describe the pkg_*-used dependency, which would be |
21 |
in both RDEPEND and DEPEND. This would allow both RDEPEND and DEPEND to |
22 |
have unique dependencies, which seems like it could be beneficial. It |
23 |
would probably require fixing the tree for packages that currently |
24 |
assume RDEPEND will be available, although I don't expect that many |
25 |
packages will have unique RDEPEND settings (mainly binaries). |
26 |
|
27 |
I guess the RDEPEND+DEPEND case would save an ebuild dev the work of |
28 |
specifying the COMMON_DEPEND list, but other than that, I can't think of |
29 |
any benefits. It would force both RDEPEND and DEPEND to be installed for |
30 |
binpkgs, which sucks. |
31 |
|
32 |
Thanks, |
33 |
Donnie |
34 |
-- |
35 |
gentoo-dev@l.g.o mailing list |