1 |
Ciaran McCreesh wrote: |
2 |
|
3 |
> On Sun, 27 Apr 2008 10:41:57 +0100 |
4 |
> Steve Long <slong@××××××××××××××××××.uk> wrote: |
5 |
>> Use PDEPEND. |
6 |
> |
7 |
> PDEPEND has a different meaning, and isn't suitable for runtime |
8 |
> dependencies. |
9 |
> |
10 |
"PDEPEND should be avoided in favour of RDEPEND except where this will |
11 |
create circular dependency chains."[1] |
12 |
Sounds very much like it is used for runtime deps, and breaking RDEPEND |
13 |
cycles has often been given as its purpose in #-portage and #-dev-help, as |
14 |
well as in the devmanual. |
15 |
|
16 |
>> While I like labels they need to be discussed more on-list as well as |
17 |
>> on bugzilla (it's not reasonable for you simply to advertise them and |
18 |
>> then close down discussion.) For instance, there is no reason |
19 |
>> everything has to be loaded into just one extant metadatum, not do |
20 |
>> they preclude new metadata (such as a SRC_DEP here.) |
21 |
> |
22 |
> Labels can be discussed on-list whenever there's a chance in hell of |
23 |
> Portage implementing any non-trivial new features. |
24 |
> |
25 |
That's not exactly in the spirit of collaboration (nor are your continuous |
26 |
snipes at portage.) New features should be discussed with a wider audience |
27 |
than bugzilla, not just used to advertise one impl and slipped in via an |
28 |
overlay. Further, having a consensus would allow pkgcore to move ahead with |
29 |
a more solid spec, and that /is/ conducive to quicker implementation in |
30 |
portage, since those two teams do know how to collaborate effectively. |
31 |
|
32 |
> Anyway, I'm going with the second wording in the original email. |
33 |
<snip more insults> |
34 |
> Of everything suggested, only |
35 |
> the two original wordings are correct, and of those two, the second is |
36 |
> better defined. |
37 |
> |
38 |
2b) seemed better. With use of PDEPEND in the manner outlined, it simply |
39 |
means pkg_{pre,post}inst can't rely on the PDEPEND'ed pkgs, only those in |
40 |
RDEPEND. |
41 |
|
42 |
Build-time dependencies wouldn't appear to cover the use-cases brought up, |
43 |
nor are they relevant for binary installs. I can see how it would be easier |
44 |
for the PM to be able to go for one or the other, but it doesn't give an |
45 |
ebuild author a consistent base. The intersection does but doesn't allow a |
46 |
package to call itself (one of the use case brought up.) PDEPENDs are used |
47 |
at ebuild authors' discretion aiui, and in collaboration between the two |
48 |
maintainers: that judgement would seem to be useful to decide which |
49 |
interdependent package can call the other, which is very much dependent on |
50 |
the context. (A classic case of something that can't be solved |
51 |
automatically.) |
52 |
|
53 |
[1] http://devmanual.gentoo.org/general-concepts/dependencies/index.html |
54 |
|
55 |
|
56 |
-- |
57 |
gentoo-dev@l.g.o mailing list |