Le jeudi 02 octobre 2008 à 15:21 +0100, Neil Williams a écrit : > > 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/ ?
It’s not that simple. The problem is that cairo and GTK+ have different
approaches on how to treat DirectFB.
* When you add X11 or DirectFB support, libcairo gains some
related symbols that you can actually use in cairo-using
libraries. The cairo library soname does not change. This is why
cairo has currently a X11-enabled build in /usr/lib and a
DirectFB-enabled build in /usr/lib/libcairo-directfb. Nothing
prevents us from building a version with support for both,
though.
* Pango (actually, pangocairo) only uses symbols from cairo that
are independent from the backend. Which means it will work when
linked to whichever of the two versions. When you run a GTK
+DirectFB application, the rpath makes the cairo library being
loaded from /usr/lib/libcairo-directfb, which means the symbols
from the DirectFB version are used by pangocairo.
* GDK and GTK+ build two different libraries depending on the
backend (X11 or DirectFB), with different sonames.
The approach you are suggesting is to make Cairo behave like GTK+, but
it contradicts what the Cairo API says, and it breaks the GTK+DirectFB
build system.
> What is the situation regarding conflicts for a separate DirectFB tree?
> - can the entire DirectFB tree conflict with the non-DirectFB tree?
That would make it almost impossible to work on GTK+DirectFB
applications while running X11. It even makes it impossible to build
GTK+ and cdebconf if both versions can’t be installed together.
> 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.
Not if the diversion is guaranteed (through dependencies) to divert the
very same version of the library, only providing another version with
more symbols.
> > 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?
The added space for cairo would be barely measurable. What it adds is a
hard dependency on libdirectfb-1.0-0 and libts-0.0-0, so ~2 MB.
> 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.
No, it would mean 0.52% of systems running the diverted cairo. You don’t
have to install it together with each directfb installation.
> 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?
This would really be the very same version of the library, with more
symbols. Nothing can break more than when you simply upgrade the library
to a new version.
> > 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.
I’m not sure we need to do that. In all cases, it causes a problem with
pangocairo. We’d need two versions of pangocairo, one linking to cairo
and one to cairo-directfb, with zero differences in the code, symbols
provided and symbols used.
> IMHO, putting the DirectFB symbols into the default
> Debian /usr/lib/libcairo.so (without the diversion) is the best solution
> for Lenny.
That, I agree with. But it can also become a long-term solution.
> IMHO /usr/lib/libcairo-directfb/ should not exist in Lenny (or Squeeze).
Yes, it’s a bit late, but I think we should remove it.
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
