#973759 lintian: False positive: debian-changelog-file-is-a-symlink matches on upstream changelog

Package:
lintian
Source:
lintian
Submitter:
Andreas Metzler
Date:
2021-09-19 21:18:03 UTC
Severity:
normal
#973759#5
Date:
2020-11-04 17:13:40 UTC
From:
To:
For exim4 lintian now warns:
W: exim4-daemon-heavy: debian-changelog-file-is-a-symlink changelog.gz
N:
W: debian-changelog-file-is-a-symlink
N:
N:   The Debian changelog file is a symlink to a file in a different
N:   directory or not found in this package.
[...]

However the Debian changelog file is not a symlink, only the upstream
one.

cu Andreas
#973759#10
Date:
2020-11-04 21:19:22 UTC
From:
To:
Hi Andreas,

Unfortunately, Lintian cannot tell from an installation package
(*.deb) whether it was built from a native source package. Possible
solutions are:

1. Via policy, prescribe a constant basename for Debian changelogs,
regardless of "nativeness".
2. In installation packages, add information about nativeness to the
control files in DEBIAN/.

Kind regards
Felix Lechner
#973759#15
Date:
2020-11-05 06:23:21 UTC
From:
To:
Hello,

It does not need to imho. It should simply consider
/usr/share/doc/package/changelog.Debian.gz as Debian changelog if it
exists and only fall back to /usr/share/doc/package/changelog.gz
otherwise.

cu Andreas
#973759#24
Date:
2021-09-19 14:09:55 UTC
From:
To:
Hi,

Andreas Metzler wrote:

Same with aptitude-robot:

  W: aptitude-robot: debian-changelog-file-is-a-symlink usr/share/doc/aptitude-robot/changelog.gz

But:

  → debc | fgrep changelog
  -rw-r--r-- root/root      5390 2021-09-19 15:17 ./usr/share/doc/aptitude-robot/changelog.Debian.gz
  lrwxrwxrwx root/root         0 2021-09-19 15:17 ./usr/share/doc/aptitude-robot/changelog.gz -> changelog.Debian.gz

Huh? This should be obvious from the binary package version number.

Ack, that should work as well. Although I still don't see how lintian
isn't able to determine from a binary package's version number if it's
a native or a normal package. (And aptitude-robot is a bit of both
respectively inbetween, hence that symlink.)

		Regards, Axel
#973759#29
Date:
2021-09-19 14:58:42 UTC
From:
To:
Hi,

It isn't. A well-known example is python-defaults [1], which is native
even though the version number suggests otherwise. The corresponding
heuristics were dropped from Lintian two years ago. [2]

In addition, it is not well-publicized that version numbers for
installation (aka "binary") packages are not necessarily tied to the
version strings for their sources, but I do not remember an example
right now.

Kind regards
Felix Lechner

[1] https://tracker.debian.org/pkg/python-defaults
[2] https://salsa.debian.org/lintian/lintian/-/commit/8e8341470ba2a5e1d8d58776b5d32c0e4a70b4c8
#973759#34
Date:
2021-09-19 15:58:17 UTC
From:
To:
On 2021-09-19 Felix Lechner <felix.lechner@lease-up.com> wrote:
[...]

Hello,

gcc-defaults is one of the most prominent examples.

cu Andreas
#973759#39
Date:
2021-09-19 21:16:14 UTC
From:
To:
Hi Felix,

Felix Lechner wrote:

I see. While I was aware that binary and source package numbers can
easily differ, I wasn't aware that the binary versions package can be
arbitrary even in their type.

Oh, wasn't aware of that either.

I was aware of that. I just never thought of the fact that this also
means that it is possible that native source packages build non-native
looking binary packages and hence version numbers are error-prone when
trying to distinguish between native and non-native packages.

The common case I remember and also already used, is to generate
transitional packages formerly built by other source packages which
used to have a higher version. So the trick is to prepend an epoch to
the actual version for just that binary package..

Thanks for the insight and details!

		Regards, Axel