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

Re: Towards X11-based d-i: v2, final report


Frans Pop <elendil@planet.nl> (15/03/2010):
> I did look at the new image and udebs earlier, but did not get
> around to doing a full review until now.

In the meantime, NEW was hit several times, and almost every new or
reworked udeb is, or is going to be, available soon. I'll send a
report in a few hours or days.

> Things I did notice:
> - libx11-6-udeb: still contains a man page
> - libx11-6-udeb: some (most/all?) of the included locales are probably not
>   needed; the en_US Compose file is huge and the one for Finnish is insane
>   considering it's only for a single language - what if all langs had a
>   file like that...

Getting rid of unneeded things in that lib is on my post-masive-upload

> - xserver-xorg-video-fbdev-udeb: depends on libc6 instead of libc6-udeb

Shouldn't be the case for the one I uploaded. Will check what happens
on the buildds.

> - udev-gtk-udeb: long description is a bit weird; I'd expect the last
>   sentence together with the first sentence and not dangling at the end,
>   and the "additionally" does not really make any sense

udev has been ACCEPTED a few minutes ago, I guess Marco fixed my dodgy
half-thought-about wording.

> It's much better always to build against sid when doing development
> work for D-I. For our purposes testing is much less reliable.

OK, fine.

> It would only make sense for libs
> - that are only depended on by one other udeb

There are some of them…

> - that's of a non-trivial size
> - for which most of its symbols are not actually used

… but that has to be checked; that's the reason why I chose to
postpone that step after massive-upload.

> I think that with libgcrypt we've already got the most obvious
> candidate, although the gain seems to have been less than I would
> have expected.

In the end I used libnettle, statically linked (that's amd64 this
time, but you'll see the huge overhead of linking statically):
| Installed-Size: [-2204-] {+2208+}

libmatrixssl's headers were a mess, nettle is much cleaner, and
directly usable as it is, while the former needed some work and we had
no replies from its maintainer yet.

> IMO the default cursor is fine. Theme support is more relevant, but
> as mentioned before I think it's realistic to ask the accessibility
> people to look into that.


> > * Probably get rid of refresh_keymap() in cdebconf.
> I would make me very unhappy if we don't have correct keymap setup
> in both the graphical (or D-I) environment and on the VTs for the
> debug consoles.  I can see that refresh_keymap() is maybe not the
> correct implementation to achieve this, but something should.

I understood that from previous mails yeah. My point was just that
looking very quickly at it that's something done automatically through
the setxkbmap call, and we shouldn't need anything more for the X

> Debug shells are an essential feature of D-I, for both development
> and rescue.

Yeah, even for the mere newcomer I am, they were pretty useful.

> >  * Dive into mklibs.
> I've thought of that a bit more and come up with a snag. mklibs
> will only work if the pic files 100% match the library that is being
> reduced. So there's a problem when libs in D-I are configured
> differently from the regular libs, or if they have other libs
> compiled in statically.
> It can be solved in two ways:
> - have special *-udeb-pic debs (which should conflict with normal -pic debs
> - do library reduction in a chroot of the image instead of using the host
>   system
> The second option has the added advantage of making a build less
> dependent on the host system (for official builds it could pull -pic
> *udebs* from testing instead of installing them on the host system),
> but it also means a fair complication of the build process and
> probably that builds would always need to be run as root (either
> real or sudo).


> * Reduce the duplication that exists between console-setup and X.org udebs.
>   As per: http://lists.debian.org/debian-boot/2010/02/msg00771.html

That wasn't in my mail but that wasn't forgotten about.


Attachment: signature.asc
Description: Digital signature

Reply to: