Re: Bug#723948: libatk-bridge-2.0-0-udeb: uninstallable; depends on missing libatspi2.0-0 (>= 2.9.4)
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
Reply to: