Re: Git Packaging: Native source formats
Simon McVittie writes ("Re: Git Packaging: Native source formats"):
> 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.
Good point. I meant "bit-identical to upstream".
> Does/can git-deborig guarantee that a given git commit will always
> produce the same tarball?
No, it doesn't. But it uses git-archive and in practice that nearly
always gives you the same tarball - even though that's not guaranteed.
I haven't seen any trouble (but I normally use `dgit clone' or `dgit
fetch' and that arranges for any existing origs in the archive to be
in the right place on my laptop, so perhaps that means I avoid trouble
that others see).
> 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.
This is a good point. Of course it's only a warning and warnings are
often ignored when you're in a hurry.
> 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.
Perhaps. I have a vague feeling that there might be (or have once
been?) some reason to prefer 1.0 (native) to 3.0 (native) but I can't
bring it to mind, and now that I try to think about it it's all just
fog. Maybe I am remembering some years-old abundance of caution.
Sean and I faced an aspect of this problem with tag2upload and 1.0
source format. (We didn't want to just say 1.0 wasn't supported.)
The information in git needs to specify whether the output is supposed
to be a native package. Obviously git-debpush shouldn't look for
tarballs in your `..', like dpkg-source does. So we ask the users of
format 1.0 source packages to add an appropriate setting to
debian/source/options.
Anyway, it seems to me that if debian/source/format says `3.0
(native)' then the warning is inappropriate.
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: