Bugzilla Bug 180045

I was installing kde-meta and I kept getting failures for things missing
libkdnssd. kdelibs has a PDEPEND on kdnssd-avahi when USE=avahi, but I don't
think it's guaranteed that PDEPEND is pulled in immediately after kdelibs, just
at any point before the end of the emerge. So it could fail to get pulled in by
the time other kde* packages require it.

It might be a good idea to change that PDEPEND to an RDEPEND in a different
package.

I ve had the same problem. Ksysguard failed to compile, missing the ssd
library. I ve ran "emerge -pv kdelibs" to check the USE flags and I realize
that kdnssd-avahi was not compiled yet (marked as New) but was scheduled to be
compiled AFTER kdelibs. The problem was it hasn't been compiled just after
kdelibs but was scheduled to be compiled after Ksysguard.

Emerging kdnssd-avahi with the oneshot flag manually before continuing the
upgrade solved the problem.

I had the same problem too. Whilst doing an emerge update that included
upgrading to kde 3.5.7. I had also added "avahi" to use flags. 
kdnssd-avahi was put at the bottom of the list and errorred when merging
kdnssd. I emerged kdnssd-avahi manually and then tried emerge -uD world
again.... It worked.

Confirm this bug on stable amd64 kde 3.5.5.  Emerge of kde-meta failed on
libkdegames of all places.  LOL.  Solved by emerging kdnssd-avahi manually as
previously stated.

*** Bug 183513 has been marked as a duplicate of this bug. ***

*** Bug 183511 has been marked as a duplicate of this bug. ***

(In reply to comment #0)
> It might be a good idea to change that PDEPEND to an RDEPEND in a different
> package.

Which one that should be (considering that it must not depend on kdelibs)???
And on that note, what's kdelibs even doing here?

<snip>        
        if ! use avahi; then
                myconf="${myconf} --enable-dnssd"
        else
                myconf="${myconf} --disable-dnssd"
        fi

...

   # Get rid of the disabled version of the kdnsd libraries
    if use avahi; then
            rm -rf "${D}/${PREFIX}"/$(get_libdir)/libkdnssd.*
    fi
</snip>

So, it doesn't actually respect --disable-dnssd? And it doesn't actually need
mDNSResponder to built that functionality? Well, in that case why are we
deleting the libs when it obviously breaks other stuff?

(In reply to comment #0)
> I was installing kde-meta and I kept getting failures for things missing
> libkdnssd. kdelibs has a PDEPEND on kdnssd-avahi when USE=avahi, but I don't
> think it's guaranteed that PDEPEND is pulled in immediately after kdelibs, just
> at any point before the end of the emerge. So it could fail to get pulled in by
> the time other kde* packages require it.

I'd say this is a Portage dependency resolution problem. Giving it at Portage
team wrt this possibility, otherwise it's a local issue (e.g. building with
--nodeps) or invalid.


> It might be a good idea to change that PDEPEND to an RDEPEND in a different
> package.

Not possible, since kdnssd-avahi depends on kdelibs and Portage builds runtime
dependencies before (and even if after, we'd run into the same problem as with
PDEPEND. That said, fixing this (installing RDPENDs "directly" afterwards
(speak: caring for the correct order the packages are built), we wouldn't need
PDEPEND at all).



And guys, please don't come with 3.5.5, we know it's broken. Also sidestepping
Portage's dependency resolution e.g. using --nodeps or package.provided, is
your private problem.

(In reply to comment #7)

carlo - you failed to address Comment #6 completely; what's the kdelibs ebuild
doing in there?

Jakub: kdelibs provides the library, when built with USE=-avahi

(In reply to comment #9)
> Jakub: kdelibs provides the library, when built with USE=-avahi

So why are you deleting the library when it breaks other stuff? See all the
duplicate bugs, they are all about missing this lib.

Jakub: Please stop spamming this bug. The ebuild is correct.

(In reply to comment #11)
> Jakub: Please stop spamming this bug. The ebuild is correct.

Thanks for detailed explanation - the ebuild is correct because it deletes libs
other stuff needs link to. Are you joking?

(In reply to comment #12)
> the ebuild is correct because it deletes libs other stuff needs link to.

But kde-misc/kdnssd-avahi-0.1.2 installs:
/usr/lib/libkdnssd.la
/usr/lib/libkdnssd.so
/usr/lib/libkdnssd.so.1
/usr/lib/libkdnssd.so.1.0.0

the solution would be to merge kdnssd-avahi into kdelibs?

carlo: and if not could you please explain, why the ebuild is correct?
Something is broken somewhere...

(In reply to comment #13)
> But kde-misc/kdnssd-avahi-0.1.2 installs:
> /usr/lib/libkdnssd.la
> /usr/lib/libkdnssd.so
> /usr/lib/libkdnssd.so.1
> /usr/lib/libkdnssd.so.1.0.0

Then kde-misc/kdnssd-avahi should delete the stuff installed by kdelibs, or it
shouldn't be a separate ebuild when it doesn't make any sense.

(In reply to comment #14)
> the solution would be to merge kdnssd-avahi into kdelibs?

Well, didn't thought about merge the packages. Good idea as a workaround.


> carlo: and if not could you please explain, why the ebuild is correct?
> Something is broken somewhere...

In the first place wrt Jakubs pointless nagging, but in the end this bug is
about one of the many shortcommings of current Portage's dependency resolver.

(In reply to comment #7)
> Not possible, since kdnssd-avahi depends on kdelibs and Portage builds runtime
> dependencies before (and even if after, we'd run into the same problem as with
> PDEPEND. That said, fixing this (installing RDPENDs "directly" afterwards
> (speak: caring for the correct order the packages are built), we wouldn't need
> PDEPEND at all).

It seems like you should move it to RDEPEND.  The resolver tries to install
RDEPEND first, but in the case of circular RDEPEND, RDEPEND will be installed
immediately after.  PDEPEND has no hard order requirement, see bug #172511.

Everything needed to solve this bug is already fixed in portage-2.1.2.x.

*** This bug has been marked as a duplicate of bug 147766 ***

Bug 147766 can probably *resolve* this one but this one's neither its dupe,
IMHO, nor is this fixed yet, so I'm re-opening.

Thanks, Zac, for your help!

(In reply to comment #17)
> It seems like you should move it to RDEPEND.  The resolver tries to install
> RDEPEND first, but in the case of circular RDEPEND, RDEPEND will be installed
> immediately after. 

Well, then the fix doesn't work, see Bug 179736 (both DEPEND and RDEPEND
produce unsolvable circular dependency). I'm afraid this is not a solution.

Circular RDEPEND works fine, but if a DEPEND is mixed in then it will cause a
circular dependency panic as shown in bug 179736.  I'll see about making a
patch for that.

After thinking about this a little more, it seems like it would be paradoxical
to try and allow a relationship like that in bug 179736.  Consider the state
after kdelibs is installed.  At this point, kdelibs can not necessarily be
relied upon as a build time dependency since it has an unsatisfied runtime
dependency.  While it may work for some dependency relationships, it's not
guaranteed to work for all of them.

On possible alternative solution to this to create a virtual/avahi and have
packages that need the library depend on that.  Unfortunately, USE deps aren't
implemented yet, so the only way to enforce the state of the avahi flag on
kdelibs is the built_with_use() function from eutils.  I suppose that function
could run inside the pkg_setup() function of virtual/avahi.

(In reply to comment #7)
> Not possible, since kdnssd-avahi depends on kdelibs and Portage builds runtime
> dependencies before (and even if after, we'd run into the same problem as with
> PDEPEND. That said, fixing this (installing RDPENDs "directly" afterwards
> (speak: caring for the correct order the packages are built), we wouldn't need
> PDEPEND at all).

As I explained in comment #22, there are issues with circular relationships
that are DEPEND in one direction and RDEPEND in the other (like bug 179736). 
Another alternative solution, besides the virtual/avahi idea, would be to make
PDEPEND behave more like RDEPEND.  If a PDEPEND is installed "directly"
afterwards whenever possible, then it will make the current relationship
between kdelibs and kdnssd-avahi behave as intended.  This kind of change in
the PDEPEND behavior might be a nice way to add more flexibility in the way
that dependencies may be specified (and easier that creating a virtual/avahi).

Created an attachment (id=123512) [edit]
try to merge PDEPEND as soon as possible so that it behaves more like RDEPEND

This patch isn't completely optimal but it should do what's intended most of
the time.

This has been released in 2.1.3_rc7.

Any chance to have a 2.1.2.10 with this fix? When we stabilise KDE everyone
with USE=avahi will hit this...

I wasn't planning to do another 2.1.2.x release.  2.1.3 is pretty stable so
I'll see about making that into a final release (can have it in the tree today
or tomorrow).

We were hoping to have KDE stable this weekend but it looks like this PDEPEND
issue is a blocker due to the avahi stuff as far as I can see. What kind of
time line are we looking at to get a stable portage with this fix in?

I think I can get it done tomorrow.