FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 09-18-2012, 08:51 PM
Michał Górny
 
Default GLEP: gentoo sync based unified deps proposal

On Tue, 18 Sep 2012 20:44:33 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Tue, 18 Sep 2012 12:40:51 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
> > On 09/18/2012 12:29 PM, Ciaran McCreesh wrote:
> > > On Tue, 18 Sep 2012 12:25:57 -0700
> > > Zac Medico <zmedico@gentoo.org> wrote:
> > >> Also, if we change the meaning of RDEPEND in the next EAPI, so
> > >> that it's a hard build-time dep like DEPEND, then
> > >> DEPEND="${RDEPEND} virtual/pkgconfig" can be reduced to
> > >> DEPEND="virtual/pkgconfig". This is what I would like to do for
> > >> the experimental EAPI 5-hdepend which is planned [1].
> > >
> > > What're we going to do about the zillions of unsolvable cycles
> > > that that would create? (Does Portage detect those and error out
> > > yet?)
> >
> > Yeah, it would be treated just like a DEPEND cycle, which is already
> > detected and treated as a fatal error. As a result, when bumping the
> > EAPI of an ebuild, you may have to migrate some deps from RDEPEND to
> > PDEPEND in order to solve the cycles.
>
> What about the large number of RDEPENDs that are required for a
> package to be usable, but not for it to be installed?

They will still be RDEPEND, just installed earlier I believe. Except
for those arising conflicts which will have to be moved to PDEP. But
I think Zac said that already.

--
Best regards,
Michał Górny
 
Old 09-18-2012, 08:53 PM
Ciaran McCreesh
 
Default GLEP: gentoo sync based unified deps proposal

On Tue, 18 Sep 2012 22:51:04 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> On Tue, 18 Sep 2012 20:44:33 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > On Tue, 18 Sep 2012 12:40:51 -0700
> > Zac Medico <zmedico@gentoo.org> wrote:
> > > On 09/18/2012 12:29 PM, Ciaran McCreesh wrote:
> > > > On Tue, 18 Sep 2012 12:25:57 -0700
> > > > Zac Medico <zmedico@gentoo.org> wrote:
> > > >> Also, if we change the meaning of RDEPEND in the next EAPI, so
> > > >> that it's a hard build-time dep like DEPEND, then
> > > >> DEPEND="${RDEPEND} virtual/pkgconfig" can be reduced to
> > > >> DEPEND="virtual/pkgconfig". This is what I would like to do for
> > > >> the experimental EAPI 5-hdepend which is planned [1].
> > > >
> > > > What're we going to do about the zillions of unsolvable cycles
> > > > that that would create? (Does Portage detect those and error out
> > > > yet?)
> > >
> > > Yeah, it would be treated just like a DEPEND cycle, which is
> > > already detected and treated as a fatal error. As a result, when
> > > bumping the EAPI of an ebuild, you may have to migrate some deps
> > > from RDEPEND to PDEPEND in order to solve the cycles.
> >
> > What about the large number of RDEPENDs that are required for a
> > package to be usable, but not for it to be installed?
>
> They will still be RDEPEND, just installed earlier I believe. Except
> for those arising conflicts which will have to be moved to PDEP. But
> I think Zac said that already.

...but you can't move them to be a PDEPEND, since PDEPENDs aren't
guaranteed to be installed when a package is used.

--
Ciaran McCreesh
 
Old 09-18-2012, 09:06 PM
Michał Górny
 
Default GLEP: gentoo sync based unified deps proposal

On Tue, 18 Sep 2012 21:53:55 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Tue, 18 Sep 2012 22:51:04 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > On Tue, 18 Sep 2012 20:44:33 +0100
> > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > > On Tue, 18 Sep 2012 12:40:51 -0700
> > > Zac Medico <zmedico@gentoo.org> wrote:
> > > > On 09/18/2012 12:29 PM, Ciaran McCreesh wrote:
> > > > > On Tue, 18 Sep 2012 12:25:57 -0700
> > > > > Zac Medico <zmedico@gentoo.org> wrote:
> > > > >> Also, if we change the meaning of RDEPEND in the next EAPI,
> > > > >> so that it's a hard build-time dep like DEPEND, then
> > > > >> DEPEND="${RDEPEND} virtual/pkgconfig" can be reduced to
> > > > >> DEPEND="virtual/pkgconfig". This is what I would like to do
> > > > >> for the experimental EAPI 5-hdepend which is planned [1].
> > > > >
> > > > > What're we going to do about the zillions of unsolvable cycles
> > > > > that that would create? (Does Portage detect those and error
> > > > > out yet?)
> > > >
> > > > Yeah, it would be treated just like a DEPEND cycle, which is
> > > > already detected and treated as a fatal error. As a result, when
> > > > bumping the EAPI of an ebuild, you may have to migrate some deps
> > > > from RDEPEND to PDEPEND in order to solve the cycles.
> > >
> > > What about the large number of RDEPENDs that are required for a
> > > package to be usable, but not for it to be installed?
> >
> > They will still be RDEPEND, just installed earlier I believe. Except
> > for those arising conflicts which will have to be moved to PDEP. But
> > I think Zac said that already.
>
> ...but you can't move them to be a PDEPEND, since PDEPENDs aren't
> guaranteed to be installed when a package is used.

But didn't we already point out that we can't have them in RDEPEND
since they introduce conflicts?

Unless you're talking about that group of dependencies which doesn't
introduce conflicts in RDEPEND now but will introduce them after
the change. We should probably do some kind of tree-wide study on how
large the problem is.

A simple solution would be to mandate installing PDEPs as soon
as possible. In case of those dependencies, that would mean installing
them like RDEPENDs are installed now, wouldn't it?

--
Best regards,
Michał Górny
 
Old 09-18-2012, 09:08 PM
Ciaran McCreesh
 
Default GLEP: gentoo sync based unified deps proposal

On Tue, 18 Sep 2012 23:06:06 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> But didn't we already point out that we can't have them in RDEPEND
> since they introduce conflicts?

You are missing a basic and important part of how dependency resolution
works: currently, cycles consisting purely of RDEPENDs are ignorable.

--
Ciaran McCreesh
 
Old 09-18-2012, 09:34 PM
Michał Górny
 
Default GLEP: gentoo sync based unified deps proposal

On Tue, 18 Sep 2012 22:08:43 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Tue, 18 Sep 2012 23:06:06 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > But didn't we already point out that we can't have them in RDEPEND
> > since they introduce conflicts?
>
> You are missing a basic and important part of how dependency
> resolution works: currently, cycles consisting purely of RDEPENDs are
> ignorable.

So, what do we lose? If PDEP comes 'ASAP' officially, I believe that we
actually gain RDEPs which can be actually trusted.

--
Best regards,
Michał Górny
 
Old 09-18-2012, 09:37 PM
Ciaran McCreesh
 
Default GLEP: gentoo sync based unified deps proposal

On Tue, 18 Sep 2012 23:34:29 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> On Tue, 18 Sep 2012 22:08:43 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > On Tue, 18 Sep 2012 23:06:06 +0200
> > Michał Górny <mgorny@gentoo.org> wrote:
> > > But didn't we already point out that we can't have them in RDEPEND
> > > since they introduce conflicts?
> >
> > You are missing a basic and important part of how dependency
> > resolution works: currently, cycles consisting purely of RDEPENDs
> > are ignorable.
>
> So, what do we lose? If PDEP comes 'ASAP' officially, I believe that
> we actually gain RDEPs which can be actually trusted.

"ASAP" is a weaker guarantee that RDEPENDs currently have -- RDEPENDs
currently have the weakest guarantee necessary to ensure that they can
be trusted. It's also a useless guarantee, since "ASAP" can be
arbitrarily late.

--
Ciaran McCreesh
 
Old 09-18-2012, 10:01 PM
Michał Górny
 
Default GLEP: gentoo sync based unified deps proposal

On Tue, 18 Sep 2012 22:37:19 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Tue, 18 Sep 2012 23:34:29 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > On Tue, 18 Sep 2012 22:08:43 +0100
> > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > > On Tue, 18 Sep 2012 23:06:06 +0200
> > > Michał Górny <mgorny@gentoo.org> wrote:
> > > > But didn't we already point out that we can't have them in
> > > > RDEPEND since they introduce conflicts?
> > >
> > > You are missing a basic and important part of how dependency
> > > resolution works: currently, cycles consisting purely of RDEPENDs
> > > are ignorable.
> >
> > So, what do we lose? If PDEP comes 'ASAP' officially, I believe that
> > we actually gain RDEPs which can be actually trusted.
>
> "ASAP" is a weaker guarantee that RDEPENDs currently have -- RDEPENDs
> currently have the weakest guarantee necessary to ensure that they can
> be trusted. It's also a useless guarantee, since "ASAP" can be
> arbitrarily late.

And can't RDEPENDs be arbitrarily late if there is a cycle?

--
Best regards,
Michał Górny
 
Old 09-18-2012, 10:06 PM
Ciaran McCreesh
 
Default GLEP: gentoo sync based unified deps proposal

On Wed, 19 Sep 2012 00:01:21 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> On Tue, 18 Sep 2012 22:37:19 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > On Tue, 18 Sep 2012 23:34:29 +0200
> > Michał Górny <mgorny@gentoo.org> wrote:
> > > On Tue, 18 Sep 2012 22:08:43 +0100
> > > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > > > On Tue, 18 Sep 2012 23:06:06 +0200
> > > > Michał Górny <mgorny@gentoo.org> wrote:
> > > > > But didn't we already point out that we can't have them in
> > > > > RDEPEND since they introduce conflicts?
> > > >
> > > > You are missing a basic and important part of how dependency
> > > > resolution works: currently, cycles consisting purely of
> > > > RDEPENDs are ignorable.
> > >
> > > So, what do we lose? If PDEP comes 'ASAP' officially, I believe
> > > that we actually gain RDEPs which can be actually trusted.
> >
> > "ASAP" is a weaker guarantee that RDEPENDs currently have --
> > RDEPENDs currently have the weakest guarantee necessary to ensure
> > that they can be trusted. It's also a useless guarantee, since
> > "ASAP" can be arbitrarily late.
>
> And can't RDEPENDs be arbitrarily late if there is a cycle?

No. RDEPENDs have to be available when a package is used to satisfy a
dependency. That's the difference between an RDEPEND and a PDEPEND.

--
Ciaran McCreesh
 
Old 09-18-2012, 10:53 PM
Michał Górny
 
Default GLEP: gentoo sync based unified deps proposal

On Tue, 18 Sep 2012 23:06:19 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Wed, 19 Sep 2012 00:01:21 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > On Tue, 18 Sep 2012 22:37:19 +0100
> > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > > On Tue, 18 Sep 2012 23:34:29 +0200
> > > Michał Górny <mgorny@gentoo.org> wrote:
> > > > On Tue, 18 Sep 2012 22:08:43 +0100
> > > > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > > > > On Tue, 18 Sep 2012 23:06:06 +0200
> > > > > Michał Górny <mgorny@gentoo.org> wrote:
> > > > > > But didn't we already point out that we can't have them in
> > > > > > RDEPEND since they introduce conflicts?
> > > > >
> > > > > You are missing a basic and important part of how dependency
> > > > > resolution works: currently, cycles consisting purely of
> > > > > RDEPENDs are ignorable.
> > > >
> > > > So, what do we lose? If PDEP comes 'ASAP' officially, I believe
> > > > that we actually gain RDEPs which can be actually trusted.
> > >
> > > "ASAP" is a weaker guarantee that RDEPENDs currently have --
> > > RDEPENDs currently have the weakest guarantee necessary to ensure
> > > that they can be trusted. It's also a useless guarantee, since
> > > "ASAP" can be arbitrarily late.
> >
> > And can't RDEPENDs be arbitrarily late if there is a cycle?
>
> No. RDEPENDs have to be available when a package is used to satisfy a
> dependency. That's the difference between an RDEPEND and a PDEPEND.

So, if a particular cycle prohibits RDEPENDs being fulfilled when
RDEPEND is needed to satisfy a dependency, we have a failure now,
correct?

Do we have that guarantee somewhere in the PMS?

--
Best regards,
Michał Górny
 
Old 09-18-2012, 11:28 PM
Brian Harring
 
Default GLEP: gentoo sync based unified deps proposal

On Wed, Sep 19, 2012 at 12:53:09AM +0200, Micha?? G??rny wrote:
> On Tue, 18 Sep 2012 23:06:19 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
>
> > On Wed, 19 Sep 2012 00:01:21 +0200
> > Micha?? G??rny <mgorny@gentoo.org> wrote:
> > > On Tue, 18 Sep 2012 22:37:19 +0100
> > > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > > > On Tue, 18 Sep 2012 23:34:29 +0200
> > > > Micha?? G??rny <mgorny@gentoo.org> wrote:
> > > > > On Tue, 18 Sep 2012 22:08:43 +0100
> > > > > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > > > > > On Tue, 18 Sep 2012 23:06:06 +0200
> > > > > > Micha?? G??rny <mgorny@gentoo.org> wrote:
> > > > > > > But didn't we already point out that we can't have them in
> > > > > > > RDEPEND since they introduce conflicts?
> > > > > >
> > > > > > You are missing a basic and important part of how dependency
> > > > > > resolution works: currently, cycles consisting purely of
> > > > > > RDEPENDs are ignorable.
> > > > >
> > > > > So, what do we lose? If PDEP comes 'ASAP' officially, I believe
> > > > > that we actually gain RDEPs which can be actually trusted.
> > > >
> > > > "ASAP" is a weaker guarantee that RDEPENDs currently have --
> > > > RDEPENDs currently have the weakest guarantee necessary to ensure
> > > > that they can be trusted. It's also a useless guarantee, since
> > > > "ASAP" can be arbitrarily late.
> > >
> > > And can't RDEPENDs be arbitrarily late if there is a cycle?
> >
> > No. RDEPENDs have to be available when a package is used to satisfy a
> > dependency. That's the difference between an RDEPEND and a PDEPEND.
>
> So, if a particular cycle prohibits RDEPENDs being fulfilled when
> RDEPEND is needed to satisfy a dependency, we have a failure now,
> correct?

Depends on the cycle, but yes.

Order of depdencies for this converation; depends is strongest,
rdepends is second, pdepend is weak. If a pkg both deps and rdeps on
something, for building (since that's the first op), dep obviously
trumps all other dep forms for that pkg.

pkg1 depends <-> pkg2 depends cycle, we're boned, unsolvable; use dep
toggling at best.

pkg1 rdepends -> pkg2, pkg2 depends on pkg1, strictly speaking, we're
boned; pkg1 isn't considered 'usable' until pkg2 is considered
'usable'. This is the common case where use pdepend instead of rdep.

pkg1 rdepends <-> pkg2 rdepends; this is a contained cycle, and is
mergable.

Now if for pkg1 rdep<->pkg2 rdep, pkg2 rdeps on pkg3 (which neds to
be built), which deps on pkg1 this too, is an unsolvable chain.

you can build pkg1 and pkg2, and even install them. But pkg3 cannot
be built until pkg1 is considered 'usable', which can't be be
considered usable till pkg2 is considered usable, which (take a guess
where I'm going with this) can't be considered usable until pkg3 is
considered usable.


> Do we have that guarantee somewhere in the PMS?

It's not too hard to check in the doc yourself, ya know.

relevant latex chunk:
"""
egin{compactitem}

item Build dependencies ( {DEPEND}). These must be installed and
usable before any of the ebuild {src\_*} phase functions is
executed. These may not be installed at all if a binary package is
being merged.

item Runtime dependencies ( {RDEPEND}). These must be installed and
usable befor the results of an ebuild merging are treated as usable.

item Post dependencies ( {PDEPEND}). These must be installed at some
point before the package manager finishes the batch of installs.
end{compactitem}
"""

keyword there is 'usable'. Wording could be expanded, but the core
notion is there- it just skips going over graph theory/resolver
guts/cycles since they're not explicitly a property of dependecy
types.

Feel free to write a patch expanding the wording htere...

~harring
 

Thread Tools




All times are GMT. The time now is 12:16 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org