On Sat, 17 Sep 2016 at 16:03:19 +0200, Andreas Beckmann wrote: > This was observed during a test on i386 with --install-recommends enabled. > I cannot reproduce it on amd64. ... > Package: libgpod-common ... > Depends: ..., libgpod4 (>= 0.7.90), ...
Compare with, on amd64: > Package: libgpod-common ... > Depends: ..., libgpod4-nogtk (>= 0.7.90) | libgpod4 (>= 0.7.90), ... I think what's going on here is that dpkg-shlibdeps chooses one of the two implementations of libgpod.so.4 from the built tree, essentially at random. If it chooses the "not GTK" version, we get the amd64-style dependency and everything is fine. If it chooses the "GTK" version, we get the i386-style dependency and the -nogtk version is uninstallable. On the reproducible builds infrastructure, we can see the dependency randomly changing. The obvious answer to this would be to stop building a special "non-GTK" version of libgpod, and turn those binary packages into transitional packages that depend on their "full" counterparts. The name "-nogtk" is misleading: what it actually means is "no GdkPixbuf", where GdkPixbuf is considerably smaller than Gtk. Of the reverse-dependencies of libgpod, the only ones that are not already dependent on Gtk (amarok and clementine) depend on GdkPixbuf themselves anyway! So this is extra complexity for literally no space-saving, which should be avoided. I am probably not going to NMU this, because I can't test this package (I don't have an iPod); but I'm build-testing a patch. S "at" the Cambridge BSP