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
