[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    [gentoo-dev]  Re: Re: Dependencies that're available at pkg_*inst
From:       Steve Long <slong () rathaus ! eclipse ! co ! uk>
Date:       2008-04-28 4:57:04
Message-ID: fv3lgm$p0i$1 () ger ! gmane ! org
[Download RAW message or body]

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.

>> 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.

> Anyway, I'm going with the second wording in the original email. 
<snip more insults>
> Of everything suggested, only 
> the two original wordings are correct, and of those two, the second is
> better defined.
> 
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.

Build-time dependencies wouldn't appear to cover the use-cases brought up,
nor are they relevant for binary installs. 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.) PDEPENDs are used
at ebuild authors' discretion aiui, and in collaboration between the two
maintainers: that judgement would seem to be useful to decide which
interdependent package can call the other, which is very much dependent on
the context. (A classic case of something that can't be solved
automatically.)

[1] http://devmanual.gentoo.org/general-concepts/dependencies/index.html


-- 
gentoo-dev@lists.gentoo.org mailing list

[prev in list] [next in list] [prev in thread] [next in thread]