On Thu, 29 Aug 2019 at 11:56:55 +0100, Ian Jackson wrote:
> If you already don't care about bit-identical upstream tarballs, then
> dealing with these tarballs is a reasonably well-solved problem.
> git-deborig etc. FTW.
I think it's important to distinguish between the two things that you
might mean by "bit-identical upstream tarballs": you might not care
whether the orig tarball is bit-identical to upstream's official release
artifact (assuming they have one), but you still have to care about
the orig tarball being bit-identical to any orig tarball of the same
name that might previously have been uploaded to the Debian archive,
because otherwise the archive will reject your uploads.
Does/can git-deborig guarantee that a given git commit will always
produce the same tarball?
> One thing I would like to see changed in this area: some of our tools
> issue warnings about packages with a non-native version, but a native
> source format. I think there is nothing wrong with this and it should
> not be discouraged and doesn't merit a warning. (There is an
> awkardness here in that you can sometimes unintentionally generate a
> native format source package if your origs are missing...)
I think that last point is a significant reason to want the nativeness
of the source package to match the nativeness of the version number: for
version 1.0 source packages, detecting a non-native version with a native
source format is the only way to generate any sort of warning about this.
Unlike 1.0 (non-native) vs. 3.0 (quilt), where some people prefer one and
some people prefer the other, I am not aware of any advantages of 1.0
(native) over 3.0 (native). If 3.0 (native) is indeed strictly better
than 1.0 (native), perhaps it would be reasonable to say that packages
that intentionally have a non-native version number but a native
source format should declare this explicitly, by using "3.0 (native)"
in d/source/format? That way, if a version 1.0 source package has a
non-native version number, tools can assume that it was meant to have
a .orig, and issue warnings; conversely, if a source package with a
non-native version number explicitly has "3.0 (native)" format, tools
could assume that the maintainer wants what they asked for.
smcv
