On Tue, Jun 28, 2005 at 01:46:06PM +0200, Josselin Mouette wrote: > Le vendredi 24 juin 2005 à 17:21 +0200, Bill Allombert a écrit : > > 2) libfoo and foo-bin, where foo-bin include binaries linked with > > libfoo. Usually libfoo only need to Depends on configuration data > > in foo-bin and not on any binaries linked with libfoo (to avoid infinite > > recursion). In that case it should be possible to split foo-bin in > > foo-bin and foo-common, and change libfoo to depend on foo-common > > instead. > > How would you treat the librsvg case? Currently, librsvg2-2 and > librsvg2-common both depend on each other. The librsvg2-2 package > contains the library, and librsvg2-common contains a loader that allows > gdk_pixbuf to load SVG files. > * librsvg2-common needs to depend on librsvg2-2 because it links to the > library; > * librsvg2-2 depends on librsvg2-common because most applications > linking to librsvg2 also expect the SVG loader to be available.
> Similarly, how would you treat the fontconfig case? Currently, > libfontconfig1 contains the library, while fontconfig contains the > shared configuration and support binaries (including fc-cache). > * fontconfig depends on libfontconfig1 because it links to it; > * libfontconfig1 depends on fontconfig because the applications using > libfontconfig1 are almost unusable if fc-cache isn't run in the font > directories. > The libgtk2.0-0/libgtk2.0-bin case is very similar: without running > update-gdkpixbuf-loaders, applications using libgtk2.0-0 won't work. > > The gconf package contains a daemon that links to libgconf2-4. However > applications linking to libgconf2-4 will require that daemon to be > installed. The same holds for libgnomevfs2-common/libgnomevfs2-0. In all that cases, you can _either_: 1) include the offending binary (e.g. fc-cache) in the library package. 2) document that packages using some extra feature (e.g. SVG loader) needs to depend on an extra package (librsvg2-common) 3) change the shlibs file to document the dependency on the library, e.g change libfontconfig1.shlibs to libfontconfig 1 libfontconfig1 (>= 2.3.0), fontconfig and rebuild every package using libfontconfig. At this point you can remove the circular dependency. 4) split the library in two libraries so that the -common package depend only on the first and is used only by the second. 5) A better solution I trust you to propose. > In short, there are cases where circular dependencies are needed. Fixing > the problem means fixing the tools, not the packages. I disagree. I think we can find technical way to get rid of every circular dependencies, but I have no hope to find even in theory a process to handle them that would be reliable. The process of deciding whether a set of package, when circular dependencies are involved, can be installed together is NP-complete. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]