Re: Getting rid of circular dependencies
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. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: