On 09/30/22 15:35, Daniel P. Berrang? wrote:> On Fri, Sep 30, 2022 at 03:23:31PM +0200, Laszlo Ersek wrote: >> On 09/30/22 14:11, Richard W.M. Jones wrote: >>> On Fri, Sep 30, 2022 at 12:56:40PM +0200, Laszlo Ersek wrote: >> >>>> (2d) I started icewm with "icewm --replace" (as recommended by the error >>>> message from (2c)), and lo and behold, two changes had come into effect: >>>> >>>> - the spinner started working >>> >>> This is strange ..? Did librsvg get installed at some point? >> >> So, "ldd `which icewm`" reports that icewm depends on librsvg-2.so.2; >> therefore it's not surprising that RPM generated the proper Requires: >> directive for the binary icewm package. I guess with Metacity, this is >> not the case -- which should be fine, if Metacity itself does not use >> librsvg2. >> >> So it looks like a package dependency bug somewhere in or around gtk3; I >> guess it has a kind of plugin architecture, and the SPEC file does not >> properly capture the (dynamic) dependency. >> >> Interestingly, in the usptream gtk repository, on the gtk-3-24 branch, >> the file ".gitlab-ci/fedora-gtk3.Dockerfile" spells out >> "librsvg2-common" and "librsvg2", from commit 81c4fa5d505ec (which is >> quite non-descript in this regard). So it is a *known* hidden dependency >> in a way. Sigh. Packaging bug then? :/ > > "its complicated" :-) > > GTK doesn't directly know about any image formats. It is built on top > of GDK-Pixbuf which is a library that provides an API for loading images, > with plugins for various formats, most outsourced to other packages. > librsvg2 provides a plugin for GDK-Pixbuf for SVG files. > > Meanwhile the usage of SVG files doesn't actually exist in GTK code either, > because GTK widget rendering is theme based, and both widget and icon themes > are separate. Even when the widget theme requests an icon, it doesn't specify > a format, because icon themes are pluggable too and it will look for icons > in whatever format happens to exist on disk. > > The icon theme doesn't include a dep on librsvg2 either, because the icons' > package doesn't dictate what is used to load them. > > IOW, it is a tragedy of a highly modular framework that nothing individually > needs/want to have a dep on librsvg2, but the combined work does need such > a dep. > > In a typical Fedora/RHEL install, all the right bits will get installed > either because of deps elsewhere in the default "desktop" install profile > group, or because of comps groups listing librsvg. p2v though is picking > a minimal set of individual packages and so misses the dep.This is horrible. The librsvg2 package provides this file: /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so which, if present, enables the whole stack to work, but if absent, breaks the stack without a peep. 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. Laszlo
On Fri, Sep 30, 2022 at 03:57:15PM +0200, Laszlo Ersek wrote:> 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.I think a lot of it comes from the endless quest to make smaller and smaller container images, which IMHO is little to do with any real technical problem and more to do with a kind of peacock's tail of evolutionary battles. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html
On Fri, Sep 30, 2022 at 03:57:15PM +0200, Laszlo Ersek wrote:> On 09/30/22 15:35, Daniel P. Berrang? wrote: > > On Fri, Sep 30, 2022 at 03:23:31PM +0200, Laszlo Ersek wrote: > >> On 09/30/22 14:11, Richard W.M. Jones wrote: > >>> On Fri, Sep 30, 2022 at 12:56:40PM +0200, Laszlo Ersek wrote: > >> > >>>> (2d) I started icewm with "icewm --replace" (as recommended by the error > >>>> message from (2c)), and lo and behold, two changes had come into effect: > >>>> > >>>> - the spinner started working > >>> > >>> This is strange ..? Did librsvg get installed at some point? > >> > >> So, "ldd `which icewm`" reports that icewm depends on librsvg-2.so.2; > >> therefore it's not surprising that RPM generated the proper Requires: > >> directive for the binary icewm package. I guess with Metacity, this is > >> not the case -- which should be fine, if Metacity itself does not use > >> librsvg2. > >> > >> So it looks like a package dependency bug somewhere in or around gtk3; I > >> guess it has a kind of plugin architecture, and the SPEC file does not > >> properly capture the (dynamic) dependency. > >> > >> Interestingly, in the usptream gtk repository, on the gtk-3-24 branch, > >> the file ".gitlab-ci/fedora-gtk3.Dockerfile" spells out > >> "librsvg2-common" and "librsvg2", from commit 81c4fa5d505ec (which is > >> quite non-descript in this regard). So it is a *known* hidden dependency > >> in a way. Sigh. Packaging bug then? :/ > > > > "its complicated" :-) > > > > GTK doesn't directly know about any image formats. It is built on top > > of GDK-Pixbuf which is a library that provides an API for loading images, > > with plugins for various formats, most outsourced to other packages. > > librsvg2 provides a plugin for GDK-Pixbuf for SVG files. > > > > Meanwhile the usage of SVG files doesn't actually exist in GTK code either, > > because GTK widget rendering is theme based, and both widget and icon themes > > are separate. Even when the widget theme requests an icon, it doesn't specify > > a format, because icon themes are pluggable too and it will look for icons > > in whatever format happens to exist on disk. > > > > The icon theme doesn't include a dep on librsvg2 either, because the icons' > > package doesn't dictate what is used to load them. > > > > IOW, it is a tragedy of a highly modular framework that nothing individually > > needs/want to have a dep on librsvg2, but the combined work does need such > > a dep. > > > > In a typical Fedora/RHEL install, all the right bits will get installed > > either because of deps elsewhere in the default "desktop" install profile > > group, or because of comps groups listing librsvg. p2v though is picking > > a minimal set of individual packages and so misses the dep. > > This is horrible. The librsvg2 package provides this file:snip> All of this registration stuff is for the 5% more comfort of > programmers, at the 90% more discomfort of sysadmins / users.Honestly as a packager you are stuck between a rock and a hard place. There are a bunch of users who want you to fully express all the optional deps, so they're guaranteed everything is installed by default. There are another bunch of users who want everything to be optional so they can make the most minimalist install profile in every conceivable scenario. You can't win, no matter what, a bunch of people end up being unhappy with the choices made. Over time Fedora and RHEL have tended more towards making everything highly modular at the package level, and then left the question of default "bundles of packages" to the high level such as the installer groups. Effectively it has been decided that if you're hand picking packages, you need to accept the complexity and figure out all the optional bits for your scenario. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|