GNOME Bugzilla – Bug 134718
new gtk+ support creates circular dependency
Last modified: 2004-12-22 21:47:04 UTC
The recent changes to configure.in means 'libgnomeui' is now a dependency of 'gnome-vfs' 'libgnome' is a dependency of 'libgnomeui'. In turn, 'gnome-vfs' is a dependency of 'libgnome'. This creates a circular dependency: libgnomeui -> gnome-vfs -> libgnome -> libgnomeui -> gnome-vfs
I mailed desktop-devel-list about this.
I talked to Alex and Owen about this on IRC today, and they told me to make this modification in gnome-vfs configure.in: From: PKG_CHECK_MODULES(GTK, gtk+-2.0 >= 2.3.1 libgnomeui-2.0 >= 2.5.1, AM_CONDITIONAL(HAVE_GTK, true)) To: PKG_CHECK_MODULES(GTK, gtk+-2.0 >= 2.3.1 libgnomeui-2.0 >= 2.5.1, AM_CONDITIONAL(HAVE_GTK, true),:) Now, if gnome-vfs does not find libgnomeui, it simply disables it and builds correctly. Since I confirmed to Alex that it worked, he told me that he would fix this on CVS. It may be already fixed right now. Can anyone confirm this?
Okay. Shiney happy solution here. As a packager, how do you suppose we should deal with this? Manually split gnome-vfs apart just to accept this case scenario? Trust auto-magic dependencies and have binary packages that arent looking the same each time because of randomized dependency based build order? please, I ask you to reconsider this as it will cause downstream maintainers severe headaches.
Spider: if your complaint is about the auto enabling/disabling of the fileselector stuff depending on libgnomeui availability, there's actually a --with-gtk=yes/no/auto flag in the latest gnome-vfs release. If it's about the circular dependency, the problem will be dealt with before the 2.6 release.
The fileselector code has been moved to libgnomeui, resolving the circular dependency issue.