Re: Keeping upstream commits separate from Debian packaging commits
On 10/17/2014 01:01 AM, Tristan Seligmann wrote:
> If such a tarball exists, and is suitable
> for use in Debian, then having the upstream source in Debian match the
> tarball distributed by upstream byte-for-byte makes it much easier to
> verify that the source in Debian is unmodified from the upstream
> source.
I never understood why this is important, even though so many people
told me they want to check for that. If the point is security, then I
don't think we achieve anything by doing so.
> This is harder when the tarball is generated from a git tag:
> the source package does not include the information necessary to match
> it against the git tag, comparing the individual files is necessary
> instead of comparing the archive, and producing the upstream source
> (.orig.tar.gz) will produce a tarball with different bytes every time
> (even if the file contents will not change).
This is anyway completely broken (see why Joey Hess decided to stop
maintaining pristine-tar ...).
> Alternatively, if you will never generate the upstream source from the
> git repository, then you avoid this problem, but then building a
> particular package version may require manually fetching the correct
> tarball from the archive / snapshot.debian.org if they are no longer
> available from the original source.
When using xz compression, then anyway, the resulting orig.tar.xz will
often not be the same when doing the same operation twice. So it's a
broken concept. And I really hope you're not arguing that because of
this, we should continue to use a 2 decade old compression thing...
On 10/17/2014 02:12 AM, Hans-Christoph Steiner wrote:
> I think there is a lot of value to always including the Debian
> upstream/v1.0 tag. It provides a standard way to access the upstream
> version across all repos. There is no such standard out there "in the
> wild". There are tags like v1.0, 1.0, release-1.0, the-real-1.0,
> etc. etc.
The most common standard I've seen almost everywhere, is to use, for a
version number, well ... just a version number. Eg, release version 1.0,
then just tag 1.0. That's what you'll see almost everywhere. Yes,
there's silly upstream who loves to prefix these with a single character
(and surprisingly, they've decided it would be a "v"). But that's fine,
just re-tag on top with: "git tag 1.0 v1.0" and then everything is fine.
There's absolutely no need to re-tag "upstream/v1.0", that's a
pristine-tar convention only, IMO.
On 10/17/2014 11:19 PM, Dimitri John Ledkov wrote:
> There are different tag types in git. "Soft" are just named commit
> references and indeed can be renamed at will / point to new commits,
> however signed tags encode:
> object SHA1id
> type type-of-above
> tag tag-name
> tagger normal user name, email, timestamp
>
> tag-message
>
> All signed with gpg. Thus any change to that metadata of a signed tag
> will invalidate signature, or be treated as conflicting tag and thus
> require --force push.
>
> Unsigned tags should not be publically used for e.g. release
> identification.
Though, if upstream publishes a gpg signed tag "v1.0", and then you
don't like it and retag "1.0" on top, then it just points to the same
pgp signature object, and you can still validate the signature. That's a
very nice feature which I use often! :)
On 10/17/2014 11:57 PM, Tristan Seligmann wrote:
> The value of this is questionable if the upstream tags are unsigned,
> especially if the released source tarballs *are* signed
I haven't yet found any instance of the above. Most of the time, I see
signed git tags, but no signed tarballs.
On 10/17/2014 11:57 PM, Tristan Seligmann wrote:
> I felt it
> was worth the extra contortions to handle the upstream tags /
> orig.tar.gz this way (the upstream tag in the packaging repository can
> still be verified, as shown above). I did end up writing a 36 line
> README.source discussing this process however... so I'm not sure how
> suitable it is for the average DPMT/PAPT-maintained package.
>
> [1] The git repository is at
> https://anonscm.debian.org/git/pkg-bitcoin/armory.git -- browse link
> is https://anonscm.debian.org/cgit/pkg-bitcoin/armory.git
My feeling is that it's not necessary. Just use upstream tags as-is, and
do not attempt to prefix them with "upstream/", which adds very little
to no benefits.
Cheers,
Thomas Goirand (zigo)
Reply to: