Hi, I read in #499662 that you propose to remove /usr/lib/libcairo-directfb/lib/libcairo.so.* and only rely on the libcairo-directfb.so.* library. However I’m afraid this is going to break the GTK+ DirectFB build. Currently, it is very hackish, and relies on the availability of those files in /usr/lib/libcairo-directfb.
The reason is that pangocairo can link to each of the two cairo libraries, and therefore we don’t rebuild it for the DirectFB version. Which means, if we only link gdk/gtk to libcairo-directfb, it will also bring libcairo through the pangocairo dependencies. Some symbols would be contained in both libcairo versions, which *may* work, but which opens the door to a large number of very subtle and incomprehensible bugs. A saner solution is probably to enable DirectFB support in the regular cairo build, and to ship the DirectFB-only version only in the udeb. It would add a hard dependency on libdirectfb-1.0-0 and would require some changes to the gtk+2.0 build, but would make things a lot cleaner in this sense - and that would definitely fix #499662. A variant of this is to make the libcairo2-directfb package ship a DirectFB and X-enabled library that comes as a diversion to the one in libcairo2. It avoids installation of libdirectfb-1.0-0 on all systems. I can work on patches if people agree on one of these solutions, and especially if it is accepted by the release team. It will imply changes in the pango1.0, gtk+2.0 and cdebconf builds. Cheers, -- .''`. : :' : 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
