Hi!
[ But, this one again… ]
On Thu, 2022-03-10 at 18:17:15 +0000, Steve McIntyre wrote:
> Why on earth *would* you mess around using Debian revisions on a
> native-format package, though? IMHO it's pointless and is just going
> to confuse people. Unless you can explain a good reason to need this,
> I'd argue strongly that the 3.0 native support is DTRT for the
> principle of least surprise if nothing else!
Yes. People complain about the Debian packaging toolchain being too
complex or too confusing. This is one of such cases. As has been stated
countless times, this subverts the semantics of both the source and
version formats. At least we only have one case remaining, the even
more senseless 1.0 non-native source with native version was turned
into an error with dpkg 1.20.1. Recall that dpkg-source currently needs
to use heuristics to decide whether to use an orig tarball + diff or not
for format 1.0. :(
We currently have 21 source packages in the archive with format 1.0
native source and non-native version:
$ grep-deb-sources -sPackage -FFormat '1.0' -a \
-FVersion '-' -a --not -FFiles '.diff.'
My impression is that _most_ of those are packaging mistakes. I just
filed two new bugs on packages that have recently been (apparently)
accidentally uploaded with such broken source tarballs (vde2: #1007087;
etbemon: #1007088).
<https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=dpkg-mismatch-source-vs-version-format;users=debian-d...@lists.debian.org>
<https://lintian.debian.org/tags/malformed-debian-changelog-version>
Then we are left with at most a literal (vocal) handful of maintainers
potentially doing this on purpose. And the main reason we cannot have
coherent, and understandable semantics here.
I've also asked before why this attachment to subvert the source
format, when the version could be modified to use some other character
instead for the “revision”, such as ‘+’, but I don't recall ever
getting any answer (not even a satisfactory one) to that.
Thanks,
Guillem
