[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Gtk 2.10 (DirectFB) progress report - update


On Sat, Sep 02, 2006, Dave Beckett wrote:
> I already said that I won't change/bloat the cairo+directfb udebs
> that are for the installer.  They don't need PDF and PS support
> and do need lib/dev debs that match the udeb so that other udebs
> can be built against them, such as the gtk+directfb udeb.

 I agree that we don't need the PDF/PS support in cairo's udebs because
 we don't need printing support in gtk's udebs, but since I can't easily
 cut away printing support in gtk, I now need cairo udeb with PDF/PS

 I don't know whether it's an useful measure of the final real runtime
 memory consumption, but the *.so sizes are:
 316K    usr-nopdf/lib/libcairo-directfb/lib/libcairo.so.2.9.1
 364K    usr/lib/libcairo-directfb/lib/libcairo.so.2.9.1

 which is a non-negligible 15% indeed.

> Is this gtk bump is really required for the etch release?
> At this stage I'm not seeing why gtk+directfb is a priority to have
> versus having stability of libraries.

 That's a good question, but I think we at least need to try, and that
 involves building stuff in experimental, and testing.

> If necessary we'll have to make a 3rd rebuild of cairo.  I'm wondering
> about having two source packages, one that builds the udeb+deb
> cairo+directfb minimal (which can be subjected to release freezes)
> and the other that builds the cairo/cairo+directfb with full features.

 That's a bit risky, but we can try; I guess we will immediately see
 whether some symbols are missing.

> Or can I just enable directfb in the main cairo build?  Do you really
> want a cairo with no X?

 I prefer the current approach; it bloats less DirectFB only apps.  I
 don't know any app which would benefit from a DirectFB+X cairo.

Loïc Minier <lool@dooz.org>

Reply to: