Ticket #397 (closed defect: wontfix)

Opened 10 years ago

Last modified 7 years ago

Dep resolution screwiness with cycle breaking

Reported by: corsair Owned by: ciaranm
Priority: Sometime Milestone:
Component: core/paludis Version: 0.24.6
Keywords: Cc:
Blocked By: Blocking:
Distribution: Gentoo



I'm not sure, if this is a problem with paludis, but I'll report it anyway:

While setting up a new system (as in 'no gnome stuff installed') I ran into this issue while compiling gnome-base/libgnome-2.18.0:

(...) checking for LIBGNOME... configure: error: Package requirements ( glib-2.0 >= 2.8.0 gobject-2.0 >= 2.0.0 gmodule-2.0 >= 2.8.0 gobject-2.0 >= 2.8.0 gnome-vfs-2.0 >= 2.5.3 libbonobo-2.0 >= 2.13.0 gconf-2.0 >= 1.1.11 ) were not met:

No package 'libbonobo-2.0' found (...)

the problem is that libgnome has an RDEPEND on >=gnome-base/libbonobo-2.13, and the DEPEND reads like this "DEPEND="${RDEPEND} (...)". The packages in RDEPEND aren't installed before libgnome although they should.

(this happens while 'paludis -i brasero' by the way)


brasero_full_output.txt Download (16.0 KB) - added by corsair 10 years ago.

Change History

Changed 10 years ago by corsair

comment:1 follow-up: ↓ 3 Changed 10 years ago by ciaranm

I strongly doubt that that's the issue... paludis --query --metadata libgnome please?

comment:2 Changed 10 years ago by ciaranm

Also note the circular dependency breaking being done. Are you sure that all the build dependencies are set in DEPEND, and not merely RDEPEND? Paludis will drop an RDEPEND to a PDEPEND if necessary to resolve a circular dependency chain.

comment:3 in reply to: ↑ 1 Changed 10 years ago by corsair

Replying to ciaranm:

I strongly doubt that that's the issue... paludis --query --metadata libgnome please?

$ paludis --query --metadata libgnome Usage error: Error handling command line: Bad argument '--metadata'

some new stuff?

Replying to ciaranm:

Are you sure that all the build dependencies are set in DEPEND, and not merely RDEPEND?

I am not sure what you mean. this is the relevant part from libgnome-2.18.0.ebuild:

    esd?    (

    doc? ( >=dev-util/gtk-doc-1 )"

comment:4 Changed 10 years ago by corsair

I have installed libbonobo manualy to continue the compile process, but I just ran into the same issue with gnome-base/gail-1.18.0:

checking for DEPS... configure: error: Package requirements (atk >= 1.13.0      gtk+-2.0 >= 2.9.4       libgnomecanvas-2.0 >= 2.0.0) were not met:

No package 'libgnomecanvas-2.0' found

DEPEND and RDEPEND look similar.

comment:5 Changed 10 years ago by corsair

heh.. it's --show-metadata, not --metadata. sorry for bugspam..

$ paludis --query --show-metadata libgnome
* gnome-base/libgnome
    gentoo:            2.14.1 2.16.0 2.18.0 (2.20.0)KR {:0}
    installed:         2.18.0* {:0}
    HOMEPAGE:          http://www.gnome.org/
    DESCRIPTION:       Essential Gnome Libraries
    LICENSE:           ( LGPL-2 )
    DEPEND:            ( >=gnome-base/gconf-2 >=dev-libs/glib-2.8 >=gnome-base/gnome-vfs-2.5.3 >=gnome-base/libbonobo-2.13 >=dev-libs/popt-1.7 esd? ( >=media-sound/esound-0.2.26 >=media-libs/audiofile-0.2.3 ) >=dev-util/intltool-0.35 >=dev-util/pkgconfig-0.17 doc? ( >=dev-util/gtk-doc-1 ) =sys-devel/automake-1.10* >=sys-devel/autoconf-2.61 sys-devel/libtool >=sys-apps/sed-4 =sys-devel/automake-1.10* >=sys-devel/autoconf-2.61 sys-devel/libtool >=sys-apps/sed-4 )
    RDEPEND:           ( >=gnome-base/gconf-2 >=dev-libs/glib-2.8 >=gnome-base/gnome-vfs-2.5.3 >=gnome-base/libbonobo-2.13 >=dev-libs/popt-1.7 esd? ( >=media-sound/esound-0.2.26 >=media-libs/audiofile-0.2.3 ) )
    SOURCE_ORIGIN:     gnome-base/libgnome-2.18.0::gentoo
    INSTALLED_TIME:    1192003159
    IUSE:              doc esd debug debug
    KEYWORDS:          *
    SRC_URI:           mirror://gnome/sources/libgnome/2.18/libgnome-2.18.0.tar.bz2

Key to mask reasons:

* K: keyword
* R: repository mask

comment:6 Changed 10 years ago by ciaranm

  • Summary changed from "DEPEND="${RDEPEND} (...)" messed up? to Dep resolution screwiness with cycle breaking

I have a suspicion that I know what's happening... Paludis gets this wrong:

index b02c4db..2a4797e 100644
--- a/paludis/dep_list_TEST.cc
+++ b/paludis/dep_list_TEST.cc
@@ -1392,6 +1392,28 @@ namespace test_cases
     } test_dep_list_65;

+    struct DepListTestCase397 : DepListTestCase<397>
+    {
+        void populate_repo()
+        {
+            repo->add_version("cat", "a", "1")->build_dependencies_key()->set_from_string("cat/b cat/c cat/d cat/e");
+            repo->add_version("cat", "b", "1")->build_dependencies_key()->set_from_string("cat/c");
+            repo->add_version("cat", "c", "1")->run_dependencies_key()->set_from_string("cat/a cat/d cat/e");
+            repo->add_version("cat", "d", "1");
+            repo->add_version("cat", "e", "1");
+        }
+        void populate_expected()
+        {
+            merge_target = "cat/a";
+            expected.push_back("cat/d-1:0::repo");
+            expected.push_back("cat/e-1:0::repo");
+            expected.push_back("cat/c-1:0::repo");
+            expected.push_back("cat/b-1:0::repo");
+            expected.push_back("cat/a-1:0::repo");
+        }
+    } test_dep_list_397;

The cycle breaking for c drops run to post. Paludis then goes on to check the rest of a's deps, and sees d and e already on the list, without realising they're too late on.

Does this situation match what you're seeing?

comment:7 Changed 10 years ago by corsair

I don't have solid knowledge about all this, but looking a few minutes on the problem I think this is what happens here.

comment:8 Changed 9 years ago by jmacdonagh

I can report the same error while trying to merge monodevelop on a system without any gnome libraries.

Somewhere in the dependency list was the need for libgnomeui, which as a DEPEND on gnome-keyring. Actually, gnome-keyring is a RDEPEND, but libgnomeui's DEPEND brings in all of RDEPEND.

I had three different circular dependencies, all on libgnomeui. Paludis was able to go forward, but it tried to merge libgnomeui before gnome-keyring. Gnome-keyring wasn't mentioned anywhere in the reverse dependency issues. In fact, I tried a simple palidus -i1 gnome-keyring, and it was able to merge (and in fact, it didn't have any dependencies at all, only that single package). After that, libgnomeui was able to configure correctly.

So perhaps any packages that have circular dependencies are merged first and foremost, without any thought to their dependencies?

comment:9 Changed 7 years ago by ciaranm

  • Status changed from new to closed
  • Distribution set to Gentoo
  • Resolution set to wontfix

The new resolver doesn't have this issue. It won't get fixed in the legacy resolver.

Note: See TracTickets for help on using tickets.