On Wed, Dec 20, 2017 at 2:50 PM, Julien Cristau <[email protected]> wrote:

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.

-V shouldn't be needed (and should have no effect) for packages that
have .symbols files and don't have udebs. I know very little about
udebs but I don't think they use .symbols files.

Thanks,
Jeremy Bicha

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

<html><head></head><body>Removing -V would be very wrong. Either leave it as-is or make sure it&#39;s kept up to date with the highest version from .symbols. <br>

Cheers, <br>
Julien <br><br><div class="gmail_quote">On December 20, 2017 8:35:18 PM GMT+01:00, Jeremy Bicha &lt;[email protected]&gt; wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;

<pre class="k9mail">We have several packages that pass the dh_makeshlibs -V flag. Simon<br />says he thinks it's not harmful since the symbols file takes<br />precedence. I think we should go ahead and remove it then unless it's<br />targeting a specific
version (like our C++ packages do).<br /><br />There is one exception: udeb packages. See the below forwarded email.<br /><br />Thanks,<br />Jeremy Bicha<br /><br />---------- Forwarded message ----------<br />From: Simon McVittie &lt;[email protected]&gt;<
br />Date: Wed, Dec 20, 2017 at 12:55 PM<br />Subject: Re: next glib upload<br />To: Jeremy Bicha &lt;[email protected]&gt;<br /><br />On Wed, 20 Dec 2017 at 17:33:36 +0000, Simon McVittie wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt
0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> On Wed, 20 Dec 2017 at 12:07:07 -0500, Jeremy Bicha wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> On
Wed, Dec 20, 2017 at 11:12 AM, Simon McVittie &lt;[email protected]&gt; wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"> On Wed, 20 Dec 2017 at 08:40:01 -0500, Jeremy Bicha
wrote:<br /> Can you show me some examples of packages waiting for GLib?<br /></blockquote><br /> It was a bit easier to show examples before someone thought it was<br /> good idea to upload all of pkg-gnome! ;)<br /><br /> How about atk1.0 or gtk2-
engines or gtk+3.0 or harfbuzz?<br /></blockquote><br /> According to queries like ?source-package(^gtk.3.0$) in aptitude:<br /><br /> libatk1.0-0 Depends: libglib2.0-0 (&gt;= 2.49.3) which is older than stable.<br /></blockquote>...<br /><blockquote
class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> I think this is looking like a bug in the testing migration<br /> infrastructure?<br /></blockquote><br />Oh... I understand this now, and it isn't
a bug in the<br />infrastructure. What links atk1.0, gtk2-engines, gtk+3.0 and harfbuzz,<br />other than using GLib? Answer: they produce udebs. Sure enough:<br /><br /> <a href="https://packages.debian.org/unstable/libgtk-3-0-udeb">https://packages.
debian.org/unstable/libgtk-3-0-udeb</a><br /> dep: libglib2.0-udeb (&gt;= 2.54.2) [not alpha, arm64, hurd-i386, sparc64]<br /><br />That looks like the result of -V all right.<br /><br />The symbols file generates nice loose dependencies for ordinary
debs,<br />but the shlibs file is used to generate dependencies for udebs.<br /><br />-V is too strict, but too strict is always safe, just annoying (it<br />delays migrations). However, the absence of -V is too loose: that tells<br />dependent udebs
that *literally any version* of GLib is acceptable,<br />which is not correct in general. If a new version of GTK uses a symbol<br />from a new version of GLib, then GTK must not migrate before GLib: that<br />would result in non-functional udebs and a
broken debian-installer,<br />which I think is built from testing?<br /><br />I think we should be using -V${version} where ${version} is the newest<br />version mentioned in the symbols file (that could probably be automated<br />reasonably easily, and
arguably dh_shlibdeps should do this itself).<br /><br /> smcv<br /><br /></pre></blockquote></div></body></html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 20 Dec 2017 at 20:50:27 +0100, Julien Cristau wrote:

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.

Right, that's what I thought. The worst that can happen from using bare
-V (with no argument) is a slightly over-strict versioned dependency,
which is a lot better than a too-weak dependency; and .symbols files
mean library users usually don't pick up the over-strict dependency anyway,
so no harm is done.

Am I right in thinking that plain dh_shlibdeps (without -V) is only
acceptable for libraries that literally never add new ABI, which are vanishingly rare?

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

That doesn't follow: -V not being harmful is a reason why we should *not* remove it.

For packages with no .symbols (C++ and udebs), -V generates strict dependencies, which sometimes stall migrations but never lead to broken systems. If a particular package's use of -V is sufficiently annoying,
then we can decide to invest the effort in using -V${abi_version} for
that package.

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)