Mailing List Archive

Ciaran McCreesh wrote:
> On Fri, 18 Apr 2008 21:45:13 -0700
> Donnie Berkholz <dberkholz@gentoo.org> wrote:
>
>> I'd go with RDEPEND only. Any other interpretation results in
>> installing build-time-only packages along with a binpkg, which
>> doesn't seem to make sense.
>>
>
> That's definitely not what we want. Only a package's DEPENDs have to be
> installed and usable when that package is built. Its RDEPENDs don't
> have to be installed until that package is treated as usable.
>
> For why this matters:
>
> cat/a-1: RDEPEND cat/b
> cat/b-1: RDEPEND cat/a
>
> This is solvable. If package managers can't solve this, they can't
> install Gnome off a stage 3...
>
>
I think Donnie (and I) are both looking for concrete examples here.
You're claiming GNOME can't be installed so please give us an example
with in-tree packages where this breaks.
--
gentoo-dev@lists.gentoo.org mailing list

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.

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

Anyway, I'm going with the second wording in the original email. It
seems fairly clear that most people aren't understanding the issue, and
are jumping in and offering opinions without having looked at the tree
(and no, I'm not going to give examples, because that'll just
degenerate into "oh, so we can change this one particular case to do
$blah", whilst missing the bigger point). Of everything suggested, only
the two original wordings are correct, and of those two, the second is
better defined.

--
Ciaran McCreesh

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

Ciaran McCreesh wrote:

> On Sat, 19 Apr 2008 18:38:06 +0200
> "Marijn Schouten (hkBst)" <hkBst@gentoo.org> wrote:
>> I don't know what the general use of pkg_preinst is, but in
>> pkg_postinst the package itself should be runnable, so its RDEPENDS
>> should be installed and usable at this point. So perhaps we should
>> define that "usable" means "each of its RDEPENDs is installed and has
>> had its pkg_postinst function run". The recursion of that definition
>> then comes from the requirement that RDEPENDs should be usable before
>> pkg_postinst starts running.
>
> No good. That prevents RDEPEND <-> RDEPEND cycles from being solved,
> and the package manager has to be able to solve that.
>
Use PDEPEND.

>> SRC_UNPACK_DEP="app-arch/unzip"
>> SRC_COMPILE_DEP="dev-scheme/bigloo"
>> SRC_INSTALL_DEP=""
>
> Labels are a cleaner solution to this. But again, we're discussing
> current EAPIs here.
>
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.)


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

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