Bug#953554: Please permit Debian revisions with 1.0 native packages [and 1 more messages]
Felix Lechner writes ("Re: Bug#953554: Please permit Debian revisions with 1.0 native packages"):
> On Tue, Mar 10, 2020 at 7:51 AM Ian Jackson
> <ijackson@chiark.greenend.org.uk> wrote:
> > 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.
>
> I too would like to see versions decoupled from the native/non-native
> question, but I think there are big technical hurdles.
There are no technical hurdles with using native formats with
non-native versions. Everything works completely correctly.
The problems are entirely ideological/philosophical. They result in
the following practical problems:
* lintian complains (at one point it didn't care, then for
a long time it was a warning, now it is an error)
* dpkg-source refuses entirely to make a `3.0 (native)' package
so you have to use `1.0'
* Using a `1.0' source format causes further warnings from
various tools telling you that 1.0 is deprecated. IMO there
is no good reason for this either.
The *only* effect of all of the above is having to suppress or ignore
warnings. Then there is one other infelicity:
* Using a 1.0 source format prevents you using better compression
than gzip. This is not an inherent technical limitation of
the 1.0 format; it's just that support for better compression is
not implemented. My understanding is that patches to implement
better compression for 1.0 would be rejected.
This infelicity results solely from the refusal of successive
dpkg-source maintainers to fix it. But it is not typically of any
significance for the kinds of packages where (i) there is an upstream
but (ii) using a plain tarball is appropriate, since such packages are
typically small.
> Maybe one day all version strings will be legal, even when a native
> format was declared. It would not work with format 1.0, which contains
> no such declaration.
It works today. The only problem is the lintian warning.
Mattia Rizzolo wrote:
> In my opinion your statements here doesn't make any sense: using a
> Debian revision when you are not relying on a single upstream tarball
> (i.e., non-native) really is going against the implied meaning of a
> Debian revision: something that is not supposed to change the upstream
> part.
Most packages are maintained in git nowadays. It is usual to have a
separate git branch for Debian and upstream work. In such a situation
it makes perfect sense to have an upstream version number which
corresponds to an upstream tag. For packages with a very small (or
zero) Debian delta to the upstream files, it makes sense to maintain
these git branches using `git merge' rather than as a stack of
patches.
However, there are serious inherent problems with all of the
non-native source formats. There are many that can occur in git
repositories which are not representable in non-native packages. For
example, changes to symlinks. Worse, one must either choose
`3.0 (quilt)' which involves patch files within the git tree
and a great deal of complexity to manage those; or 1.0-with-diff which
has an even more restricted set of things it can represent.
Using a single-tarball source package makes all of these problems go
away. The only downsides are: (i) Debian-only changes involve
re-shipping all the upstream code via the archive - but for a small
package this is not a concern; (ii) it does not ship a pristine
upstream tarball - but upstreams often don't provide tarballs, and
even when they do reusing pristine upstream tarballs is not mandatory
in Debian, and can be bad idea depending what they contain compared to
upstream git.
So there are no real downsides. Other than having to constantly whack
warnings.
Chris Lamb writes ("Re: Bug#953554: Please permit Debian revisions with 1.0 native packages"):
> However, I would be minded to not adjust Lintian in this particular
> case regardless of the above: I suspect in the overwhelming majority
> of cases where this tag is emitted it is due to a temporary mistake
> such as a typo on behalf of the maintainer which is then immediately
> corrected locally. Indeed, I am often guilty of "dch -v 1.0-1" for
> packages where I definitely do not intend this suffix and I would very
> much like to see that prior to an upload.
I have no problem with this being a lintian warning. In this bug I am
requesting this "error" to be returned to its previous status as a
warning.
Right now, I have a package where I have to suppress this:
O: [package] source: malformed-debian-changelog-version 1.0-1 (for native)
(package name elided)
This corresponds to this:
https://lintian.debian.org/tags/malformed-debian-changelog-version.html
What this says is that lintian is certain it has detected a
release-critical bug in my package. That is clearly not true.
> Have you considered adding a (commented!) override for this particular
> package? I suspect your response may be to suggest we allow this for
> 1.0 version source packages, but I must confess it would need
> explaining to me that the version (eg. "native (1.0)" vs "native
> (3.0)") is a distinction to be made here at all.
I have indeed used an override. But I am worried. I perceive this as
part of a campaign to abolish one of my workflows. I am scared that
in the future an attempt may be made to actually forbid this practice.
Having to override a "certainty: certain, severity: serious" warning
for this is very worrying to me. Having to suppress this also means
that lintian wouldn't warn me if my version number was actually
seriously mangled.
I think that Previously lintian reported this situation as
"hyphen-in-native-debian-changelog-version"
which was a warning.
My personal view is that there is *absolutely nothing wrong* with this
workflow and this packaging approach. It is worth a warning from
lintian precisely for the reasons you (Chris) state: this situation
can be a mistake. I would be happy to suppress a warning.
I am not happy to have to suppress a warning. I am also not happy
that there are clearly people who regard what I am doing as
ideologically/philosophically wrong and seem to be trying very hard to
discourage me. I am not happy that it seems likely that I will at
some point be actually *prevented* from doing this.
(Ideally I would like dpkg-source to permit source format
`3.0 (native)' packages to have a non-native version number.)
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Reply to: