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 attachment 123512 [details, diff] 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.
