On Thu, 2008-10-02 at 14:33 +0200, Josselin Mouette wrote: > 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.
Sort of - certainly public symbols in a /usr/lib/lib*/ directory is a bad idea as far as cross-building is concerned (and a caution in Policy). Directories beneath /usr/lib/ should only be for private libraries like plugins and modules, or pkg-config stuff. Putting public libraries (libcairo.so with compiled support for directfb) into a directory beneath /usr/lib/ turns cairo into a special case (albeit allowed in Policy) and special cases have a habit of breaking in unexpected ways. If we could have /usr/lib/libcairo-directfb.so.* then things would be a lot simpler. Equally, having the default /usr/lib/libcairo.so.* include the directfb symbols and do away with /usr/lib/libcairo-directfb/lib/ completely would fix the problem too. (That method would also not require rebuilding the package in the same buildd run but would make all installs bigger.) > 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. OK - if we can come up with a sane solution instead of /usr/lib/libcairo-directfb/lib/ which itself generates a series of hacks elsewhere, I'm all for it. > 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. Looking ahead to Squeeze, would it be possible to implement the same solution for pango and actually package the full set of libraries with appropriate dependencies such that each branch (with and without DirectFB) can actually build natively and cross without all these hacks? Can we not separate the entire DirectFB question into dedicated packages using predictable filenames and directories - just as if these were actually different source packages? Would the DirectFB support need to conflict with the non-DirectFB and would such a conflict work? If not conflict, maybe we could rename the libraries to sit alongside each other in /usr/lib/ ? We seem to have an improvised system that tries to treat the DirectFB and non-DirectFB trees as special cases when it might make things a lot easier across the board if they were just treated as completely separate packages - completely separate dependency trees. I'm a bit confused about how Cairo and DirectFB work together - the package description describes a DirectFB backend for Cairo. To me, a backend is a dlopen'd plugin or module, in which case I would not expect public symbols and /usr/lib/cairo-directfb/ (without the lib prefix) would seem appropriate, yet there clearly are public symbols. It would be a lot easier if DirectFB support in Cairo really was a plugin or module that could be installed and purged at will. (I use that mechanism for my own upstream library.) If this is not possible, I think we should have separate public libraries in Squeeze, both in /usr/lib/ and named accordingly. I think this will become more of an issue in Emdebian soon because we want to start playing around with modifying dependency trees by changing --enable-foo into --disable-foo in various packages and I've been wondering how this can be encoded into the normal packaging processes. Cairo is an existing example of this kind of problem, GConf is another (for Emdebian) where we want a gconf with and without ldap support. (This is mainly done to further reduce installation sizes by dropping dependencies that are not actually needed for the specific package set supported by a particular type of device.) It necessarily complicates mixing Debian and Emdebian packages but is a worthwhile step to get a system based on Gtk+ and Debian to install within 64Mb. In this situation, Emdebian might want to build other flavours of cairo and gtk with various options disabled. Managing the plethora of new dependency trees will be a difficult task, so I'm just throwing ideas around at the moment. See also http://www.emdebian.org/emdebian/flavours.html (I've just spotted a few typos on that page, so I'll get it updated overnight). What is the situation regarding conflicts for a separate DirectFB tree? - can the entire DirectFB tree conflict with the non-DirectFB tree? (Build-Conflict would not be sufficient if the library itself is not renamed.) I'm probably looking at Conflicts: for the GConf solution and others like it - the non-ldap version would need to conflict with the default Debian/Emdebian version with ldap compiled in. As well as a new library package, a new -dev package would also be required, libgconf-noldap-dev etc. Gtk, Cairo and Pango might be able to do something similar but I haven't delved into the rest of the dependencies yet. As you note below, diversions are also a possible mechanism (although implementing diversions in Emdebian has separate problems that need their own solution) but moving aside a library with a divert and replacing it with a library containing a different list of symbols whilst applications are still using the old symbols could be a problem, that is why we have library transitions after all. Hence either a Conflict: or a renamed library - both with a completely autonomous dependency tree. (At some point, the trees would rejoin so it's only within Gtk/Cairo/Pango and a few others that we could need an alternate tree, AFAICT.) > 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. Agreed, not ideal. So, to me, this argues in favour of a more complete separation between the with-DirectFB and without-DirectFB trees - post Lenny. > 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. Yes, putting the directfb symbols into /usr/lib/libcairo.so.* would be a good fix for Cairo in Lenny. How much extra space will this consume? > 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. libdirectfb-1.0-0 is installed on 24% of systems according to popcon (and brings tslib along with it), compared to 75% with libgtk2.0-0. libdirectfb-1.0-0 is 2Mb installed. It might be acceptable for Lenny but I think we could do better for Squeeze. Using a diversion could mean that 24% of popcon systems run the diverted cairo binary. Currently, only 0.52% actually have it installed and 0.05% appear to use it - i.e. those building things that depend on it. Does this not risk the subtle and incomprehensible bugs described earlier? Typical DD has normal libcairo installed, needs to test an RC bug in some other package that uses DirectFB, installs libcairo-directfb which diverts (the running) Cairo/Gtk/Pango libraries and runs the build. Maybe the user logs out, later logs back in, removes libcairo-directfb and dependencies when the bug fix is uploaded, the diversion is reverted and the DirectFB symbols are in memory but no longer in the undiverted library? > 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. We might want one fix for Lenny and one fix for Squeeze? i.e. a simple fix for Lenny that causes absolute minimal disruption in other packages (particularly Gtk) and then a more robust and flexible solution for Squeeze, incorporating a more complete separation between with-DirectFB and without-DirectFB trees. IMHO, putting the DirectFB symbols into the default Debian /usr/lib/libcairo.so (without the diversion) is the best solution for Lenny. For Squeeze, I think there should be a different solution involving a more-or-less complete separation between the DirectFB tree and without-DirectFB tree, with conflicts or renamed libraries, such that building applications with DirectFB support means always having the DirectFB symbols available in the relevant dependencies - including the udeb builds and udeb cross-builds. Conflicts could make it very difficult to test package builds outside a chroot, so renamed libraries may be the only solution. Maybe clone this bug as wishlist with a view to a different fix in Squeeze? IMHO /usr/lib/libcairo-directfb/ should not exist in Lenny (or Squeeze). -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
signature.asc
Description: This is a digitally signed message part
