On Mon, 28 Apr 2008 05:57:04 +0100 Steve Long <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > On Sun, 27 Apr 2008 10:41:57 +0100 > > Steve Long <[EMAIL PROTECTED]> wrote: > >> Use PDEPEND. > > > > PDEPEND has a different meaning, and isn't suitable for runtime > > dependencies. > > > "PDEPEND should be avoided in favour of RDEPEND except where this will > create circular dependency chains."[1] > Sounds very much like it is used for runtime deps, and breaking > RDEPEND cycles has often been given as its purpose in #-portage and > #-dev-help, as well as in the devmanual.
Yup, but it can't break all circular dependency chains.
> >> While I like labels they need to be discussed more on-list as well
> >> as on bugzilla (it's not reasonable for you simply to advertise
> >> them and then close down discussion.) For instance, there is no
> >> reason everything has to be loaded into just one extant metadatum,
> >> not do they preclude new metadata (such as a SRC_DEP here.)
> >
> > Labels can be discussed on-list whenever there's a chance in hell of
> > Portage implementing any non-trivial new features.
> >
> That's not exactly in the spirit of collaboration (nor are your
> continuous snipes at portage.) New features should be discussed with
> a wider audience than bugzilla, not just used to advertise one impl
> and slipped in via an overlay. Further, having a consensus would
> allow pkgcore to move ahead with a more solid spec, and that /is/
> conducive to quicker implementation in portage, since those two teams
> do know how to collaborate effectively.
And if there's any chance that labels will ever be usable in the main
tree, that discussion will happen.
> 2b) seemed better. With use of PDEPEND in the manner outlined, it
> simply means pkg_{pre,post}inst can't rely on the PDEPEND'ed pkgs,
> only those in RDEPEND.
2b) isn't an option, since it's wrong. 2) is an option.
> Build-time dependencies wouldn't appear to cover the use-cases
> brought up, nor are they relevant for binary installs.
Which means in some cases binary packages are unusable where source
packages wouldn't be.
> I can see how it would be easier for the PM to be able to go for one
> or the other, but it doesn't give an ebuild author a consistent base.
> The intersection does but doesn't allow a package to call itself (one
> of the use case brought up.)
No, it means ebuilds have to be careful with dependencies if calling
themselves.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
