Dep resolution screwiness with cycle breaking

[corsair]

Hello,

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)

[ciaranm]

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

[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.

[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:

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
            )"

DEPEND="${RDEPEND}
    >=dev-util/intltool-0.35
    >=dev-util/pkgconfig-0.17
    doc? ( >=dev-util/gtk-doc-1 )"

[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.

[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

[ciaranm]

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?

[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.

[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?

[ciaranm]

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