Hi!

[ I was pointed out to this bug, so chiming in. :) ]

On Tue, 2020-03-10 at 14:47:12 +0000, Ian Jackson wrote:
> Package: lintian
> Version: 2.55.0

> I am packaging a small program for which I am the upstream.  It does
> not make sense to use a complicated source format; 1.0 native is
> perfect.
> 
> Even though I am both upstream and Debian maintainer, this is not a
> Debian-specific package and it might have both (i) changes in Debian
> that have no upstream implications and (ii) changes upstream that
> affect more than Debian.

I see why using a native source package in such case can be more
convenient. And I also think it is reasonable and something that a
maintainer should be able to decide whenever and whether the
trade-offs are worth it.

Personally, this is something that I'd never do, because I find it
alters the nature of native source packages, and makes it more confusing
for others to understand and handle within Debian and relative to
upstream, but I also obviously consider it acceptable for others to
disagree with this view!

> A non-native version is the best way to reflect that.

But, I don't find this to be very reasonable, because while the previous
is a conceptual mismatch (what we consider upstream and packaging,
etc), this one is a technical or interface mismatch, that makes dealing
with these packages more complex and in need of special casing, etc.

So…

> However,
> 
> E: chiark-tcl-applet source: malformed-debian-changelog-version 1.0-1~
> (for native)
> 
> For the reasons above I disagree with calling this an error.
> Previously it was a warning.  (Full disclosure: I know the dpkg
> maintainer disagrees with my position here.)

…would you be amenable to instead change the way you version these
kind of packages, and use some other marker instead of «-»? Say «+» or
a word like «rev» like in «1.0rev1» or similar construct?

Which would give you the properties you look for, while not messing
with the semantics of the source and version formats, so that we can
keep them consistent?


I am also, as mentioned on d-d, already in the process to start
obsoleting this in dpkg-dev, and already prepared an initial patch for
dpkg yesterday [O], because we currently only have 33 such packages in
the archive, where I have the impression most if not all (except at least
for the one you maintain and the python default packages) seem due to
packaging error.

[O] 
<https://www.hadrons.org/~guillem/tmp/0001-Dpkg-Source-Package-V1-Check-version-format-matching.patch>

Thanks,
Guillem

Reply via email to