Bug#914271: lintian: Rationale behind hyphen-in-upstream-part-of-debian-changelog-version

[Guillem Jover <guillem@debian.org>]

On Thu, 2018-11-22 at 13:24:04 +0100, Johannes Schauer wrote:
> Quoting Guillem Jover (2018-11-22 13:12:05)
> > > in your original commit you were talking about "some tools".
> > > 
> > > This suggests that you know tools that behave wrongly.
> > > 
> > > If you share the tools you know of, then we could file bugs.
> > 
> > I think that would be difficult, I'm afraid the bulk of these
> > tools are human brains! :D
> > 
> > See for example #911341 which is something I recently stumbled upon.
> > The tools here work as intended, but the human made a very
> > comprehensible mistake.
> > 
> > I mean, yes, we could improve lintian, perhaps even some of
> > dpkg-gensymbols, and similar to warn or maybe not propose this kind
> > of situation, but in the end, any time you strip the revision in any
> > dependency field or similar, you can end up with broken comparisons
> > given the current algorithm.
> 
> I then suggest two things:
> 
> Instead of checking whether the upstream version contains dashes, check whether
> the .symbols file contains a version format that avoids bugs like #911341.
>
> Improve the tag description to be more explicit about which problem is being
> solved, for example by making the tag specific for the symbols file error.

The problem is that we have recommendations around to remove the
revision in some cases, for example from build-dependencies (I think
there's even a tag for that). And people do that also when declaring
dependencies when the relevant relationship is against the upstream
part and not the packaging part.

Having an explicit check for the symbols stuff would be nice, but I
think it's besides the point. In the same way epochs in upstream
version are problematic, dashes in upstream versions are too IMO.

> Additionally: I don't know how the machinery works that compares versions in
> symbols files, but maybe it could be improved to make sure that this kind of
> problem doesn't happen anymore?

Actually the dpkg-gensymols file does not strip the revision, so
that's human made. To try to cope with these cases the code in
dpkg-shlibdeps would need to traverse all debian/changelog entries
and try to _infer_ from the versions seen there which ones have had
their revisions stripped. This might not always work, I'm afraid,
f.ex. say we have this:

 1.0-1
 1.0-1-1

:) This is all very fuzzy.

Thanks,
Guillem