| 1 |
On Mon, 28 Apr 2008 05:57:04 +0100 |
| 2 |
Steve Long <slong@××××××××××××××××××.uk> wrote: |
| 3 |
> Ciaran McCreesh wrote: |
| 4 |
> > On Sun, 27 Apr 2008 10:41:57 +0100 |
| 5 |
> > Steve Long <slong@××××××××××××××××××.uk> wrote: |
| 6 |
> >> Use PDEPEND. |
| 7 |
> > |
| 8 |
> > PDEPEND has a different meaning, and isn't suitable for runtime |
| 9 |
> > dependencies. |
| 10 |
> > |
| 11 |
> "PDEPEND should be avoided in favour of RDEPEND except where this will |
| 12 |
> create circular dependency chains."[1] |
| 13 |
> Sounds very much like it is used for runtime deps, and breaking |
| 14 |
> RDEPEND cycles has often been given as its purpose in #-portage and |
| 15 |
> #-dev-help, as well as in the devmanual. |
| 16 |
|
| 17 |
Yup, but it can't break all circular dependency chains. |
| 18 |
|
| 19 |
> >> While I like labels they need to be discussed more on-list as well |
| 20 |
> >> as on bugzilla (it's not reasonable for you simply to advertise |
| 21 |
> >> them and then close down discussion.) For instance, there is no |
| 22 |
> >> reason everything has to be loaded into just one extant metadatum, |
| 23 |
> >> not do they preclude new metadata (such as a SRC_DEP here.) |
| 24 |
> > |
| 25 |
> > Labels can be discussed on-list whenever there's a chance in hell of |
| 26 |
> > Portage implementing any non-trivial new features. |
| 27 |
> > |
| 28 |
> That's not exactly in the spirit of collaboration (nor are your |
| 29 |
> continuous snipes at portage.) New features should be discussed with |
| 30 |
> a wider audience than bugzilla, not just used to advertise one impl |
| 31 |
> and slipped in via an overlay. Further, having a consensus would |
| 32 |
> allow pkgcore to move ahead with a more solid spec, and that /is/ |
| 33 |
> conducive to quicker implementation in portage, since those two teams |
| 34 |
> do know how to collaborate effectively. |
| 35 |
|
| 36 |
And if there's any chance that labels will ever be usable in the main |
| 37 |
tree, that discussion will happen. |
| 38 |
|
| 39 |
> 2b) seemed better. With use of PDEPEND in the manner outlined, it |
| 40 |
> simply means pkg_{pre,post}inst can't rely on the PDEPEND'ed pkgs, |
| 41 |
> only those in RDEPEND. |
| 42 |
|
| 43 |
2b) isn't an option, since it's wrong. 2) is an option. |
| 44 |
|
| 45 |
> Build-time dependencies wouldn't appear to cover the use-cases |
| 46 |
> brought up, nor are they relevant for binary installs. |
| 47 |
|
| 48 |
Which means in some cases binary packages are unusable where source |
| 49 |
packages wouldn't be. |
| 50 |
|
| 51 |
> I can see how it would be easier for the PM to be able to go for one |
| 52 |
> or the other, but it doesn't give an ebuild author a consistent base. |
| 53 |
> The intersection does but doesn't allow a package to call itself (one |
| 54 |
> of the use case brought up.) |
| 55 |
|
| 56 |
No, it means ebuilds have to be careful with dependencies if calling |
| 57 |
themselves. |
| 58 |
|
| 59 |
-- |
| 60 |
Ciaran McCreesh |
Archives