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

Re: Switching g-i from DirectFB to X11 -- specific issues/comments

Frans Pop <elendil@planet.nl> (19/02/2010):
> I'm saving the switch to console-setup for a last separate reply.

(It's late^Wearly but) Did I miss it?

> >   libx11
> Is /usr/share/X11/locale needed? If it is, could some of its
> contents be excluded because they are not relevant for G-I?

As replied by Julien, some space saving could happen, probably
candidate for the 3rd step of the plan proposed in the last paragraph
of <[🔎] 20100224071921.GA29099@debian.org>[1]?

 1. http://lists.debian.org/debian-boot/2010/02/msg00704.html

> >   xserver-xorg-video-fbdev
> Contains a man page which should be excluded.

Already done in my pu/udeb-clean branches on alioth.

> >   libgpg-error

As per [1], gone.

> The same (.mo files) also goes for xkb-data-udeb.

Will have to check that one.

> >   dmz-cursor-theme       (2 patches, tried to save up some space)
> Could probably be reduced further. A lot of cursor shapes will never
> be displayed. For example: at least currently we have no need for
> window moving and resizing. AFAIK only arrow and text are actually
> used. It would be nice to have "wait" as well (e.g. while building
> dialogs or when progress bars are active), but that would probably
> require changes in cdebconf.

Could you please establish a normative list of the cursors you're
using or going to use (which would then include the “wait” one), so
that we only keep those?

> The directfb G-I displayed a smaller black arrow, which IMO was more
> elegant than the one displayed now.

I for one don't care that much; I only picked this theme since
Josselin mentioned it initially; BTW, there's DMZ-White & DMZ-Black in
the same (regular deb) package, we probably could arrange something,
especially if we're going to ship only a few cursors.

> Keeping the white as option could be useful for e.g. the "dark"
> theme, but that means we'd need a way to change the cursor.

At (d-i, not udeb-providing-source-package) build time, I assume? In
both cases, it's just about a link to create before X starts.

> >   udev                   (maybe a single udeb could be sufficient)
> I suppose the additions really are unavoidable?

Already addressed by Julien in his reply.

> So I'd prefer to concentrate all bits that are only needed for G-I
> to be combined in a separate udeb (udev-gtk-udeb?) and leave the
> existing udev-udeb unchanged. udev-gtk-udeb should then depend on
> udev-udeb and one of the xorg udebs should depend on udev-gtk-udeb.
> Hopefully that's acceptable for Marco.

Whatever works for Marco and -boot folks. Only a few additional items
are needed and have been spotted, so shipping them in this or that
udeb should be trivial.

> This was an important issue. Glad that's resolved for now. But as
> Bastian noted the current workaround can cause problems if a module
> were to be the only user of some libc symbol. So we definitely need
> to look at his suggestion to force all symbols to "weak".

As noted in [1], I'd rather keep library reduction for later, but that
sounds like something we want to do at some point indeed.


Attachment: signature.asc
Description: Digital signature

Reply to: