Bug#858319: uscan: Handling of non-trivial repacking

[Osamu Aoki]

Hi,

On Tue, Mar 21, 2017 at 07:28:22AM +0000, Christopher Hoskin wrote:
> Package: devscripts
> Version: 2.17.2
> Severity: normal
> 
> Dear Maintainer,
> 
> Sometimes it is necessary to repack an upstream tarball when it contains
> material which violates the DFSG. In the case that whole files need to be
> removed, this is adequately handled by mk-origtargz. However, there are
> other situations which cannot be handled simply by excluding files, for
> example, removing non-DFSG ICC profiles from images [0].
> 
> The watch file can specify a script to be called by uscan instead of
> uupdate. Current practice seems to be to use this script to call a repack
> script to perform custom repacking. For example, the Perl Team use [1].
> 
> There are a couple of problems with this approach however:
> 
> * the repacksuffix in the watch file is not passed to the repack script
> * the <target> tag isn't set to the name of the repacked tarball
> 
> Thus there is no agreement between uscan/watch and the repack script about
> what the repacked tarball should be called.
> 
> The impact of this is that when a command  such as
> 
> gbp import-orig --uscan --pristine-tar 
> 
> is called, the original tarball is commited to the pristine branch rather
> than the repacked tarball.

repacking is done by uupdate.  So whoever decide to implement its
substitute, its needs to do the same as uupdate does well so gbp can
work well.  I don't think making uscan more complicated than it is now
is bad idea.

What is needed is to add a feature to support like ICC repacking to
uupdate in a generic way.  So it will be flexible enough to address
other script running.

Anyway, pointer to perl is useful so now I know what kind of script is
needed. ... repack.stub

Thanks

Osamu