Russ,

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

> Paul Hardy <unifoun...@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

Reply via email to