Re: [Libguestfs] another GTK3 regression...

This is the same terrible "push" (or "registration") model (rather than the "pull") model that plagues systemd: if a kernel module is missing from the initrd that's needed for driving a device or a filesystem, the boot gets stuck without any indication of what *should* happen (i.e. what dependency is not being satisfied). There is no technical dependency whatsoever, it's just that an event does not occur that "might" otherwise "cause progress" from a global perspective. The exact same silly pattern exists in UEFI, with PPI and protocol GUID dependencies. Very powerful as long as you are developing a particular module. Once you forget about it, *and* a particular protocol GUID is provided outside of your current repository (so you can't simply grep for it), heaven help you resolve the stuck boot (as, of course, it is not easy to all to get the set of those protocol GUIDs that *might* get the DXE dispatcher unstuck via their registration in the protocol database). How is it better that the librsvg2 package, which is a *low level package*, includes a *semantic dependency* (basically: *knowledge*) of one of its high-profile comsumers (namely, gdk-pixbuf) -- a high level package --, and not the other way around? Since when is it a good idea to encode reverse dependencies in packages? The mind boggles. All of this registration stuff is for the 5% more comfort of programmers, at the 90% more discomfort of sysadmins / users.