Simon McVittie, le Thu 03 Oct 2013 11:45:45 +0100, a écrit : > Is there any general documentation on creating udebs/how they should > differ from full-fat debs, or should I base some guesses on another > udeb-enabled package, like glib2.0 or something?
They are basically like debs, except we try to make them as small as reasonably possible, and their postinst have a priority ordering (XB-Installer-Menu-Item). You have documentation in the debian-installer source package, in doc/devel/internals. > How space-constrained are we here? That depends on which images will contain the udeb. Here we are talking about libdbus as a dependency for libatk-bridge, itself a dependency for libgtk, which is only included in the graphical installer. It means size does matter, but not too hardly: it won't be used e.g. for embedded or such. > Should I be compiling the udeb "flavour" > with -Os, disabling API sanity checks (that aren't triggered by correct code) > to save a bit of space, or similar hacks? If it's not too hard to do it, it'd be nice, yes. > The obvious core feature is "enough of the libdbus library that dynamic > linking succeeds", but presumably AT-SPI isn't just linking to libdbus > for fun, and needs some subset of its functionality. > What functionality do you need the libdbus udeb(s) to have? Specifically: > > Does AT-SPI run its own DBusServer in-process (in which case it might > only need the library), or does it execute the dbus-daemon binary? It starts its own dbus-daemon. > Does AT-SPI need the well-known D-Bus system bus to be running from > its init script, or can we leave out that bit? AT-SPI is able to fetch the path to its own dbus-daemon through an X11 property, so I'd say we can leave out the system bus. > dbus-daemon and parts of libdbus require that a unique "machine UUID" (32 > lower-case hex digits + "\n", no punctuation) has been generated and stored > in either /etc/machine-id (systemd-compatible location) or > /var/lib/dbus/machine-id (old location). Should dbus-udeb arrange for that > to happen in its postinst, or would you prefer d-i to set up > /etc/machine-id globally? I don't really have a strong opinion here. I guess for the time being you can generate it in postinst. > Are udebs expected to be robust across a reboot? No :) > Do you want the dbus-launch utility to start/discover a session bus > automatically (packaged as dbus-x11, 28K, adds libX11) or can we omit that? > > Do you want the dbus-send utility for sending messages from the > command line (20K) or can we omit that? > > Do you want the dbus-monitor utility for monitoring D-Bus traffic? (16K) AT-SPI won't need those. It essentially needs dbus-launch, to start dbus-daemon. Something worth noting: follow the same packaging split as the debs: dbus-udeb and libdbus-1-3-udeb. What we actually really need right now is libdbus-1-3-udeb, for the libatk-bridge dependency. Starting an AT-SPI bus etc. (i.e. the dbus-udeb package) will not be used right now, but it's a good step toward actually getting AT-SPI working in the graphical debian installer. Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
