Hi, Le vendredi 14 décembre 2007 à 18:51 +0100, Bas Wijnen a écrit : > For the usual case, where the library uses the other library internally, > the relation should be written as "Requires.private:".
We have already moved a lot of these dependencies to Requires.private, but some are more questionable. Those removals should be done very carefully, especially because C++ packages will FTBFS if they don’t explicitly link to a library they require. * gdk-pixbuf-2.0.pc This is the only one requiring gobject-2.0 and gmodule-no-export-2.0. Which is highly questionable, because all libraries should require gobject, and gtk should require gmodule. I suspect other libraries require gdk-pixbuf only to get these dependencies. * gdk-x11-2.0.pc Here, the dependency on gdk-pixbuf-2.0 should probably be moved to Requires.privates, but replacing it with gobject-2.0. Only remain pango and pangocairo. The GdkPango primitives heavily rely on pango types and functions, and any code using them is bound to use pango functions as well. However it can be argued that in these cases the application should already depend on pangocairo by itself, so it looks fine to remove them. * gtk+-x11-2.0.pc I think it is hopeless to remove gdk-x11-2.0. GTK+ relies so heavily on GDK that most applications using both are probably requiring only GTK+. Removing it will only break many applications. Atk only looks accessible by functions returning Atk types, so I guess it could be removed. I don't understand why cairo is here. It should be in gdk-x11-2.0, because this is where the cairo interface lies. * gtk+-unix-print-2.0.pc This is merely a wrapper that always bring gtk+-x11-2.0. Anything else should be removed. * gdk-pixbuf-xlib-2.0.pc gobject and gdk-pixbuf-2.0 should be kept. I don’t think there’s any point for gmodule, even in Requires.privates. * gtk+-directfb-2.0.pc Same as gtk+-x11. * gdk-directfb-2.0.pc This one is a giant mess, and the reason is the rpath. Everything fails if the rpath isn’t propagated to *all* binaries linking to the library, even indirectly. The real solution is, before any other fix, to get rid of this rpath and give the directfb version of cairo a different soname. Because all these dependencies are created by the configure script, it is a lot of work to remove them properly, so don’t expect this to be done in a snap. I also think we should prepare a package in experimental and ask for a full archive rebuild with it. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `- our own. Resistance is futile.
signature.asc
Description: Ceci est une partie de message numériquement signée
