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

Towards X11-based d-i: v2, progress report

Hi folks.

Sorry, no patches, sources, or udebs, at least for now. (Yes, this is
a teaser; booh, bad bad bad KiBi.)

I just wanted to keep you posted about my latest hacks. Please note
the following numbers are based on my IRC backlog between successive
builds, so they might not be the exact figures for the final v1 → v2
update; they should give a clue though. (There could be typos, too.)

(If you want to quick-read it, bottom-line available for each source
package after the ‘⇒’ sign.)

Already done:

 * xorg-server: We can link statically against libgcrypt &
   libgpg-error for the time being. That means a 2016 → 2460 increase
   for the Installed-Size, but also 2 udebs we don't need to
   add. While this is a huge increase, we should be able to link
   statically against libmatrixssl only, once its -dev package ships
   all needed headers so that we can use its matrixSha1*
   functions. The increase I noted when building statically against
   libmatrixssl was 2012 → 2032, which seems much more reasonable. In
   all cases, that means we don't need to deal with extra udebs for
   just SHA1 computations (!), and that we could start shipping an
   xserver-xorg-core-udeb right now, there's (AFAICT) no more doubt
   about udebs we might try to get rid of (at least based on the
   previous observations).

   ⇒ Less udebs needed, less space used.

 * udev: The previous patch set wasn't really good indeed. I've left
   udev-udeb untouched this time, and put input_id, the needed rule
   and libudev.so.0.6.1 in the new one, and registered it as shlibs
   through --add-udeb. It additionally Depends: udev-udeb, meaning
   once the xserver-xorg-core-udeb built against the new libudev-dev,
   it get a Depends on udev-gtk-udeb, which in turn pulls
   udev-udeb. (I'm not sure we should name it udev-gtk-udeb since
   there's nothing gtk-related in there, it'd rather be X11-related,
   but frankly, I don't care. :))

   ⇒ Fixed relationships and contents for udev's udebs.

 * gtk+2.0: Julien's patch against its configure.in did the trick and
   a few X libraries got dropped: libxcomposite1, libxdamage1,
   libxfixes3, libxrandr2. That means fewer udebs to add (although
   libxfixes3 is still pulled by libxcursor1), which is what we tried
   to achieve. That also means I'm back to using an additional flavour
   (shared_udeb but the name isn't really important) instead of the
   regular flavour (shared), since there are now additional flags;
   anyway, gtk+2.0 folks are already in favour of this flavour

   ⇒ Less udebs needed, less space used.

 * xkb-data: Stripping the *.mo files got the Installed-Size down for
   real: 4700 → 3068. As I said in a comment in my initial patch, I
   really considered the udeb an exact copy as a first guess, and
   moved on to the interesting parts which were Xorg itself and the
   whole Cairo/Pango/Gtk stack, which sounded like the real
   challenge back then. :)

   ⇒ Less space used.

Now on my todolist:

 * Wait for some feedback about the cursors, and tweak the cursor
   package accordingly.

   ⇒ Possibly better look, less space used.

 * Have a look at cleanly generating the stripped-down XML file for
   gtk+2.0 (a few lines of xslt should do, although we don't really
   need this *right now*, since I've put a manually-built minimal XML
   file in both my initial and updated gtk+2.0 patches).

   ⇒ Cleaner approach.

 * Publish a v2 of all patches, source packages, and udebs, so that
   people can have another look. If no blocker is found, I guess we
   may want to start adding the udebs for real at this point? From my
   point of view, only xorg-server might be a bit of a moving target
   depending on how and when the gcrypt/gpg-error → matrixssl switch

   ⇒ I don't like keeping stuff for myself.

 * Maybe look into mklibs. It might be easier for people familiar with
   this tool to dig into it once I've published my updated patches,

   ⇒ Possibly drastically reduce space.

As always, I take comments, ideas, flames, whatever you throw. :)


Attachment: signature.asc
Description: Digital signature

Reply to: