dh_makeshlibs -V and udebs

[Jeremy Bicha <jbicha@debian.org>]

We have several packages that pass the dh_makeshlibs -V flag. Simon
says he thinks it's not harmful since the symbols file takes
precedence. I think we should go ahead and remove it then unless it's
targeting a specific version (like our C++ packages do).

There is one exception: udeb packages. See the below forwarded email.

Thanks,
Jeremy Bicha

---------- Forwarded message ----------
From: Simon McVittie <smcv@debian.org>
Date: Wed, Dec 20, 2017 at 12:55 PM
Subject: Re: next glib upload
To: Jeremy Bicha <jbicha@debian.org>

On Wed, 20 Dec 2017 at 17:33:36 +0000, Simon McVittie wrote:
> On Wed, 20 Dec 2017 at 12:07:07 -0500, Jeremy Bicha wrote:
> > On Wed, Dec 20, 2017 at 11:12 AM, Simon McVittie <smcv@debian.org> wrote:
> > > On Wed, 20 Dec 2017 at 08:40:01 -0500, Jeremy Bicha wrote:
> > > Can you show me some examples of packages waiting for GLib?
> >
> > It was a bit easier to show examples before someone thought it was
> > good idea to upload all of pkg-gnome! ;)
> >
> > How about atk1.0 or gtk2-engines or gtk+3.0 or harfbuzz?
>
> According to queries like ?source-package(^gtk.3.0$) in aptitude:
>
> libatk1.0-0 Depends: libglib2.0-0 (>= 2.49.3) which is older than stable.
...
> I think this is looking like a bug in the testing migration
> infrastructure?

Oh... I understand this now, and it isn't a bug in the
infrastructure. What links atk1.0, gtk2-engines, gtk+3.0 and harfbuzz,
other than using GLib? Answer: they produce udebs.  Sure enough:

  https://packages.debian.org/unstable/libgtk-3-0-udeb
  dep: libglib2.0-udeb (>= 2.54.2) [not alpha, arm64, hurd-i386, sparc64]

That looks like the result of -V all right.

The symbols file generates nice loose dependencies for ordinary debs,
but the shlibs file is used to generate dependencies for udebs.

-V is too strict, but too strict is always safe, just annoying (it
delays migrations). However, the absence of -V is too loose: that tells
dependent udebs that *literally any version* of GLib is acceptable,
which is not correct in general. If a new version of GTK uses a symbol
from a new version of GLib, then GTK must not migrate before GLib: that
would result in non-functional udebs and a broken debian-installer,
which I think is built from testing?

I think we should be using -V${version} where ${version} is the newest
version mentioned in the symbols file (that could probably be automated
reasonably easily, and arguably dh_shlibdeps should do this itself).

    smcv