Bug#748465: Renaming repacked tarball (was Re: Excluded-Files feature reimplemented)

[James McCoy]

Adding #748465 since it also raised the issue of the renaming.

On Tue, May 20, 2014 at 11:56:09PM +0200, Joachim Breitner wrote:
> Am Dienstag, den 20.05.2014, 19:10 +0200 schrieb Andreas Tille:
> > So what would be your suggestion to solve this issue to get some
> > appendix to the version number.  I think editing each debian/watch
> > file an mangling names is a bit clumsy.
> 
> I don’t think its too bad, and at least its explicit, but I don’t use
> that feature myself (yet).
> 
> Would it be less clumsy if you did not have to specify some specific sed
> expression, but could rather had a simple way to flag uscan to „do the
> usual and commonly accepted version mangling“? That would be more
> declarative, less line-noisy and less for you to type.

The type of suffix varies depending on the reason the tarball is being
repacked.  The two common ones are [+.]dsN and [+.]dfsgN where the
former indicates the tarball has been repacked and the latter indicates
that the repack was due to DFSG violations.  Not everyone includes the N
(+dfsg1 vs. +dfsg) but I think it's a good idea in case the same
upstream version needs to be repacked differently for some reason.

Given the above, how about a “--repack-suffix …” that gets passed
through to mk-origtargz?  So “uscan … --repack-suffix +dfsg1” or a
similar mk-origtargz invocation repacks and adds +dfsg1 to the upstream
version.

This could possibly be exposed by a new opts value in the watch file
itself -- opts=repacksuffix=+dfsg1

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jamessan at debian.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/devscripts-devel/attachments/20140520/77d4157f/attachment-0001.sig>