Bug#976836: libgnutls30: 3.7.0-3 fails to connect on debian.ethz.ch

[Adrian Bunk]

On Sun, Dec 27, 2020 at 12:38:21PM +0100, Julian Andres Klode wrote:
> On Sun, Dec 27, 2020 at 12:25:37PM +0200, Adrian Bunk wrote:
> > On Sun, Dec 27, 2020 at 09:58:06AM +0100, Julian Andres Klode wrote:
> > >...
> > > or revert that madness
> > > of forcing all your reverse depends to depend on gnutls28 just because
> > > there are a few new enum members they _might_ have used - it's doing
> > > more harm then good, and it's not standard practice.
> > 
> > This is actually good practice, if in doubt our dependencies should 
> > always err on the safe side.
> > 
> > Imagine software like apt would have gotten a too low dependency and 
> > then migrated before gnutls to testing.
> > 
> > Or even worse, due to a too low dependency apt would have been upgraded
> > during the first step of an oldstable->stable upgrade, but not gnutls.
> > 
> > In this specific case the higher dependency might not be required for
> > apt specifically, but really bad practice would be risking breakage
> > for our users by not setting the dependency strict enough.
> 
> The tooling is just suboptimal for these cases. I think essentially
> in most cases raising the depends is wrong - if something used newer
> features it would build-depend on newer versions, and run-time depends
> should be max version of (build-depends on dev package, symbols of
> runtime package) or something like it to make this easier to manage,
>...

This cannot work.

It is common for software to autodetect the version or features of a 
library, and use everything that is available at build time.

You cannot build-depend on a not yet available next upstream version of 
a library if your package uses new features from that when it is the
version available at build time.

If in doubt dependencies should be too strict rather than too loose,
what gnutls does here is exactly correct for ensuring that any setup
that fulfills the dependencies is also working.

cu
Adrian