Removing -V would be very wrong. Either leave it as-is or make sure it's kept up to date with the highest version from .symbols.
Cheers, Julien On December 20, 2017 8:35:18 PM GMT+01:00, Jeremy Bicha <[email protected]> wrote: >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 <[email protected]> >Date: Wed, Dec 20, 2017 at 12:55 PM >Subject: Re: next glib upload >To: Jeremy Bicha <[email protected]> > >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 <[email protected]> >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
