Re: [gentoo-dev] Re: Re: Dependencies that're available at pkg_*inst

[Ciaran McCreesh <ciaran.mccreesh@googlemail.com>]

[-- Attachment #1: Type: text/plain, Size: 2553 bytes --]

On Mon, 28 Apr 2008 05:57:04 +0100
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> Ciaran McCreesh wrote:
> > On Sun, 27 Apr 2008 10:41:57 +0100
> > Steve Long <slong@rathaus.eclipse.co.uk> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]