Re: Upstream Tarball Signature Files

Russ,

On Sat, Aug 12, 2017 at 7:59 PM, Russ Allbery <rra@debian.org> wrote:

Paul Hardy <unifoundry@gmail.com> writes:

> Osamu: I did not mean just accept one format--I meant accept both ".asc"
> and ".sig" files for ".changes", ".dsc", and uscan files. I suppose all
> three manuals you mentioned could be modified to document this.

> I had not brought this up until the latest lintian check on a test build
> returned an error, but then Sean noted that the lintian error report is a
> bug.

> If there are no strong objections to this change, I will file a wishlist
> bug as an "issue" for debian-policy about this. I will be away next
> weekend so I will try to put together something before then.

Hi Paul,

This isn't a debian-policy matter. Support for ".sig" files in *.changes
and *.dsc would be a bug against dpkg and possibly also in DAK for the
archive to handle them, and in watch files would be a bug against
devscripts.

However, I don't think it's a good idea to support multiple file names for
the same thing. Instead, package building tools should probably just
rename *.sig files to *.asc if upstream uses *.sig, the same way thhat
they rename upstream source tarballs to follow our naming convention
(which upstream almost never uses). The bug may be best filed against
devscripts for uscan --download to rename the signature on download.

If it is permissible to rename a ".sig" file as ".asc", I think that is the best solution because it copies the original signature file unmodified. I tried it previously and it worked, but it seemed to me like masquerading (because a binary file obviously is not an ASCII-armored file) and not right.

The first part of my request was going to suggest adding ".asc" files in examples. The Policy Manual gives sample lists of files that appear in the Files and Checksums sections (5.6.21 and 5.6.24) of ".dsc" and ".changes" files using "example_1.2.orig.tar.gz" and "example_1.0.orig.tar.gz". Do you think it is appropriate to mention that those sections may contain signature files of the form "example_1.[02].orig.tar.gz.asc", showing that file name with the other files? There seems to be no mention of such a file in the Policy Manual. Sections 5.6.21 and 5.6.24 are where I thought of requesting changes.

It's almost never a good idea to introduce synonyms into any sort of
standard. It adds a lot of complexity that has to be maintained forever,
to very little benefit.

Yes. My thinking was to maintain the integrity of an upstream signature when applicable. Changing the extension of a binary ".sig" file to ".asc" will do that.

Thank you,

Paul Hardy