Bug#737843: manipulate unzip behavior

Osamu Aoki osamu at debian.org
Sun Nov 15 09:12:54 UTC 2015


Hi,

On Sun, Nov 15, 2015 at 09:12:25AM +0100, Emmanuel Bourg wrote:
> Hi Osamu,
> 
> Thank you for the feedback. Adding optional unzip options to uscan isn't
> uninteresting but that's a much larger goal than the issue I raised.

I re-read the bug reports in question:
 https://bugs.debian.org/737843 Reported in Feb 2014
 https://bugs.debian.org/618513 Fixed in Apr 2011 (2.10.72)
 Initial unzip support in Feb 2008 (2.10.17)

Hmmm... so it was changed to add "-a" option in 2011. Daniel said "I
felt a little unsure..." when changing this.

> I'm just requesting that uscan doesn't change the content of the
> upstream files, that's a reasonable expectation I think. This should
> be the default behavior and packagers shouldn't have to set extra
> parameters to achieve this.

You are the first one to come up with a real case which caused the
regression.

I think expectation are different depending who we talk to.  Generally,
if the differences are marginal, I leave such decisions to the upstream
of the each basic tool writer and offer ways to customize convenience
tool. Also, I am very conservative on changing default behavior of any
command.

Also we are not living in ASCII/Latin-1 era.

This is tough call which default we should deploy.  But I vote for not
using -a for default while making alternative behavior accessible for
people who need them.

James and Daniel, is this plan OK?

Osamu



More information about the devscripts-devel mailing list