Hi, 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 support. 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. Bye, -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]