Package: debian-installer Severity: normal The libgdk-pixbuf2.0-0 package and its corresponding udeb have traditionally included two shared libraries, libgdk_pixbuf-2.0.so.0 and libgdk_pixbuf_xlib-2.0.so.0.
Gdk-Pixbuf upstream recently split the source package, moving the Xlib parts into their own deprecated repository. In preparation for this we're splitting up the binary packages, similar to what happened to Pango in the past: - libgdk_pixbuf-2.0.so.0 -> libgdk-pixbuf-2.0-0 - libgdk_pixbuf_xlib-2.0.so.0 -> libgdk-pixbuf-xlib-2.0-0 - transitional package libgdk-pixbuf2.0-0 that pulls in both (See #974870, and note the subtle distinction between *pixbuf2.0* and *pixbuf-2.0*.) We *could* split the udeb in the same way, but I'd prefer not to, because I suspect the installer doesn't actually use the Xlib part - so I'd prefer to only have libgdk-pixbuf-2.0-0-udeb, and in the short term a transitional libgdk-pixbuf2.0-0-udeb that Depends on it. Does that seem OK from d-i's side? That would mean that when we split the *source* package, only src:gdk-pixbuf will need udeb machinery, and the new src:gdk-pixbuf-xlib will no longer need to produce one. Please check my reasoning? The packages that need the gdk-pixbuf udeb seem to be src:cdebconf, src:gtk2-engines, src:gtk+2.0, src:gtk+3.0 and src:vte (according to https://deb.debian.org/debian/dists/unstable/main/debian-installer/binary-amd64/Packages.gz), and none of them contain a regex match for gdk.pixbuf.xlib, except in old changelogs. So I think losing libgdk_pixbuf_xlib-2.0.so.0 from the udeb would be OK. I'll follow up to this bug when I have a gdk-pixbuf version with the proposed split ready for testing. It would be great if someone who knows d-i could try a build of the graphical installer with those packages. Also, does d-i respect versioned Provides? If it does, we could remove libgdk-pixbuf2.0-0-udeb completely, and give libgdk-pixbuf-2.0-0-udeb a Provides: libgdk-pixbuf2.0-0-udeb (= ${binary:Version}). Thanks, smcv
