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