New PDEPEND behaviour.

HELLO,

AS A RESULT OF BUG #180045 PDEPENDS CAN BE NOW MERGED EVEN
BEFORE THE PACKAGE 
THAT PULLS THEM. ZMEDICO SAYS THAT'S INTENDED BEHAVIOUR AND
PDEPEND IS REALLY 
A RDEPEND, BUT WITH A ABILITY TO RESOLVE CIRCULAR DEPS:
CIRCULAR DEPEND <-> RDEPEND CAN'T BE RESOLVED WHILE
CIRCULAR DEPEND <-> 
PDEPEND CAN.
RANDOM BEHAVIOUR OCCURS WHEN THERE IS A CIRCULAR RDEPEND
<-> PDEPEND, E.G. BUG 
#186517.

WE NEED TO UPDATE DOCS OR HARASS ZMEDICO TO FORCE PDEPEND TO
BE PULLED AS SOON 
AS POSSIBLE BUT NOT BEFORE THE PKG THAT PULLS IT.

-- 
BEST REGARDS,
PIOTR JAROSZY?SKI
--
GENTOO-DEVGENTOO.ORG MAILING LIST

On Wed, Jul 25, 2007 at 02:08:39PM +0200, Piotr Jaroszy??ski
wrote:
> Hello,
> 
> As a result of bug #180045 PDEPENDs can be now merged
even before the package 
> that pulls them. Zmedico says that's intended behaviour
and PDEPEND is really 
> a RDEPEND, but with a ability to resolve circular
deps:
> circular DEPEND <-> RDEPEND can't be resolved
while circular DEPEND <-> 
> PDEPEND can.
> Random behaviour occurs when there is a circular
RDEPEND <-> PDEPEND, e.g. bug 
> #186517.
> 
> We need to update docs or harass zmedico to force
PDEPEND to be pulled as soon 
> as possible but not before the pkg that pulls it.

PDEPEND (just like RDEPEND), can, and always has been *able*
to be 
satisfied prior to the node that requires it- the name may
suck, but 
it's better then BREAK_RDEPEND_CYCLES, thus PDEPEND; it's
never been 
viewed as a literal "it must be post" however. 
Semi curious when the 
ebuild manpage picked up that description also- would expect
its just 
a bad choice of words.

If in doubt, suggest you do some experiments with earlier
portage 
versions, explicitly trying to force a node that is
PDEPEND'd upon to 
come prior- ought to occur fine.  Basically, you're arguing
based upon 
*most* PDEPEND'd nodes dep'ing on the original PDEPENDer (a
cycle, 
thus with PDEPEND breaking it, the PDEPEND target coming
first due to 
resolution rules) - not on rules of PDEPEND.

Either way, proposing that PDEPEND (a cycle breaking
RDEPEND), be 
literal post is likely going trigger some fun fallout with
the 
existing consumers of it.  Suggest you investigate those
before 
pushing this idea further.

On the offchance there isn't nasty fallout from your
proposal, still 
view it as -1 for the change.

~harring

Piotr Jaroszyński wrote:
> Hello,
> 
> As a result of bug #180045 PDEPENDs can be now merged
even before the package 
> that pulls them. Zmedico says that's intended behaviour
and PDEPEND is really 
> a RDEPEND, but with a ability to resolve circular
deps:
> circular DEPEND <-> RDEPEND can't be resolved
while circular DEPEND <-> 
> PDEPEND can.
> Random behaviour occurs when there is a circular
RDEPEND <-> PDEPEND, e.g. bug 
> #186517.
> 
> We need to update docs or harass zmedico to force
PDEPEND to be pulled as soon 
> as possible but not before the pkg that pulls it.
> 

Now how in the world do you pull a depend that needs to be
merged AFTER 
the original package?

i.e. Package ABC and Package XYZ... Package XYZ is a series
of config 
files and data for Package ABC. The files of XYZ need to be
owned by 
user abc which gets created by Package ABC. Those files also
need to be 
installed in /usr/share/abc, which gets created by Package
ABC.

-- 
Doug Goldstein <cardoegentoo.org>
http://dev.gentoo.org/
~cardoe/

--
gentoo-devgentoo.org mailing list

ON MITTWOCH, 25. JULI 2007, PIOTR JAROSZY?SKI WROTE:
> AS A RESULT OF BUG #180045 PDEPENDS CAN BE NOW MERGED
EVEN BEFORE THE
> PACKAGE THAT PULLS THEM. ZMEDICO SAYS THAT'S INTENDED
BEHAVIOUR

WELL, THEN WHAT OUR PORTAGE DEVS THINK THE INTENDED
BEHAVIOUR SHOULD BE IS A 
BUG. E.G. IN THE CASE THE BUG REFERS TO, WE RELY ON PORTAGE
BUILDING  
KDNSSD-AVAHI AFTER KDELIBS (OTHERWISE IT SIMPLY WOULD FAIL),
BUT BEFORE ANY 
OTHER EBUILD THAT MIGHT NEED KDNSSD-AVAHI. AND I'M PRETTY
SURE NEARLY 
EVERYONE USING PDEPEND IN HIS EBUILDS RELIES ON PORTAGE
BUILDING THE PDEPEND 
NOT BEFORE THE EBUILD, WHICH LISTS IT.

> WE NEED TO UPDATE DOCS OR HARASS ZMEDICO TO FORCE
PDEPEND TO BE PULLED AS
> SOON AS POSSIBLE BUT NOT BEFORE THE PKG THAT PULLS IT.

THE LATTER.


CARSTEN

On Wed, 25 Jul 2007 08:46:43 -0400
Doug Goldstein <cardoegentoo.org> wrote:
> Now how in the world do you pull a depend that needs to
be merged
> AFTER the original package?

You make the after package DEPEND upon the before package.

-- 
Ciaran McCreesh

On Wed, 25 Jul 2007 14:51:55 +0200
Carsten Lohrke <carlogentoo.org> wrote:
> And I'm pretty sure nearly everyone using PDEPEND in
his ebuilds
> relies on Portage building the PDEPEND not before the
ebuild, which
> lists it.

And I'm pretty sure they don't, since they have the post
package
DEPENDing upon the pre package anyway.

-- 
Ciaran McCreesh

Piotr Jaroszyński wrote:
> Hello,
>
> As a result of bug #180045 PDEPENDs can be now merged
even before the package 
> that pulls them. Zmedico says that's intended behaviour
and PDEPEND is really 
> a RDEPEND, but with a ability to resolve circular
deps:
> circular DEPEND <-> RDEPEND can't be resolved
while circular DEPEND <-> 
> PDEPEND can.
> Random behaviour occurs when there is a circular
RDEPEND <-> PDEPEND, e.g. bug 
> #186517.
>
> We need to update docs or harass zmedico to force
PDEPEND to be pulled as soon 
> as possible but not before the pkg that pulls it.
>
>   
Actually in a follow up...

I've read the bugs you've referenced and it just sounds like
a bug in 
the Paludis ebuilds not having the proper depends.

This e-mail was just some fear mongering on behalf of
Paludis devs.
-- 
gentoo-devgentoo.org mailing list

ON WED, 25 JUL 2007 14:08:39 +0200
PIOTR JAROSZY?SKI <PEPERGENTOO.ORG> WROTE:
> WE NEED TO UPDATE DOCS OR HARASS ZMEDICO TO FORCE
PDEPEND TO BE
> PULLED AS SOON AS POSSIBLE BUT NOT BEFORE THE PKG THAT
PULLS IT.

GIVE ONE EXAMPLE OF A LEGITIMATE USE OF DEPENDENCIES THAT
WILL BREAK BY
THIS CHANGE. IN YOUR ANSWER, CONSIDER THAT SOMEONE MIGHT
INSTALL THE
POST PACKAGE AS A TARGET WITHOUT HAVING ITS DEPENDENCIES
INSTALLED.

-- 
CIARAN MCCREESH

On Wed, Jul 25, 2007 at 02:51:55PM +0200, Carsten Lohrke
wrote:
> On Mittwoch, 25. Juli 2007, Piotr Jaroszyński wrote:
> > As a result of bug #180045 PDEPENDs can be now
merged even before the
> > package that pulls them. Zmedico says that's
intended behaviour
> 
> Well, then what our Portage devs think the intended
behaviour should be is a 
> bug. E.g. in the case the bug refers to, we rely on
Portage building  
> kdnssd-avahi after kdelibs (otherwise it simply would
fail), but before any 
> other ebuild that might need kdnssd-avahi.

I suggest you in the future check out what actually was
changed, and 
do some testing- both the original poster, and yourself are
missing 
what is occuring here (if it's any consolation, I missed the
real 
cause of 186517 initially too .  The
portage change is to shift the 
placement of PDEPENDed nodes as early as possible-
specifically to 
fix cases where deps are a bit screwed up (like 180045, 
kdnssd-avahi/kdelibs).

Note I said 'shift'.  It tries to place it earlier in the
graph, while 
*still* maintaining the constraints of kdnssd-avahi- namely
the 
kdelibs dependency.

Via that dep, kdnssd-avahi *requires* kdelibs to be
installed first, 
and portage honors that- it just now tries to get
kdnssd-avahi merged 
as soon as possible after kdelibs due to their PDEPEND
relationship 
(try it if in doubt, it lineralizes it properly).

The cases where it doesn't, are when the constraints are
already 
satisfied- kdelibs already is merged, basically.  There is a
change in 
placement there, but considering the data involved, wouldn't
label it 
a regression- same issue can, and does occur in multiple
other ways.


> And I'm pretty sure nearly 
> everyone using PDEPEND in his ebuilds relies on Portage
building the PDEPEND 
> not before the ebuild, which lists it.

No one has relied on that in my experience.  They've relied
on PDEPEND 
being satisfied, but not required to be satisfied by the
time the 
PDEPENDer is considered 'satisfied' buildplan wise.

I strongly suspect folks echoing that sentiment are missing
that a 
PDEPEND'ed nodes' DEPEND/RDEPEND *must* be satisfied prior
to it being 
merged, and are missing what PDEPEND means to the resolver.


> > We need to update docs or harass zmedico to force
PDEPEND to be pulled as
> > soon as possible but not before the pkg that pulls
it.
> 
> The latter.

Former.  The ebuild manpage is a bit loose in it's
description of what 
PDEPEND does.

As cardoe commented, the flaw that folks are hitting in
186517 is a 
data flaw (the data is bad); it's not a flaw in the resolver

behaviour.

Feed it bad data, it's going to do stupid things basically


~harring

Piotr Jaroszyński wrote:
> We need to update docs or harass zmedico to force
PDEPEND to be pulled as soon 
> as possible but not before the pkg that pulls it.

There is another problem with PDEPEND that I've run into: if
you are
doing an emerge that fails some time after the package
containing the
PDEPEND builds but *before* the depended-on package builds
successfully,
the dependency will not be "remembered" as needed
on the next emerge
(unless you do a resume, of course).  So, basically, the
dependency gets
forgotten.  The new behavior discussed here makes this
scenario less
likely but does not eliminate it.

						-Joe


-- 
gentoo-devgentoo.org mailing list