Bug#552729: lintian: weak-library-dev-dependency shouldn't trigger for some (most?) cases that are not "= ${binary:Version}"
Mike Hommey <mh+reportbug@glandium.org> writes:
> There are various cases where you don't need to have -dev packages
> strictly depend on the binary version, or even sometimes, need it *not
> to* be a strict dependency on the binary version.
> One of these cases is when the -dev package is arch: all, where using
> ${binary:Version} will fail after a binNMU. (This also makes the arch:
> all package uninstallable on architectures other than the one a DD
> uploaded a build for, until the buildds keep up, which can take a while
> ; this has been a long-standing bug of the debian archive)
> For instance, I use (>= ${source:Upstream-Version}),(<= ${source:Version}.1~)
> in such cases.
This makes sense.
> Another of these cases is when both API and ABI are stable: you can
> surely link against a newer version with the old API headers. Even when
> ABI is unstable, the package that is depended upon is supposed to change
> its name related to the SONAME.
> There are probably actually a very few cases where such a tight
> dependency is strictly needed.
Well, a fairly tight dependency is almost always needed because of the
*.so symlink. The value of that symlink changes, provided upstream is
using normal shared library versioning such as done by libtool or the
like, with every change of any kind to the source of the library, since
they change the third number of the shared library name even though they
don't change the SONAME.
However, the *.so symlink is unlikely to need to change if the upstream
version hasn't changed.
The tricky part is to try to represent this in Lintian, since parsing the
Depends header to figure out whether the maintainer is sufficiently
cautious is tricky.
I think my first pass solution here will be to require that arch: all -dev
packages instead depend on (>= ${source:Version}) or (>=
${source:Upstream-Version) and ask people to use an override if that still
doesn't cut it.
At first glance, I don't see a reason for arch: any -dev packages not to
use the strict dependency even if it isn't entirely necessary, since it's
maximally safe and doesn't risk having some oddity create an unusable -dev
package (particularly since nothing will catch that the package is
unusable). I'm not really seeing a drawback to using the tight dependency
in that case, although one clearly cannot do so with arch: all -dev
packages.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: