Bug#792415: python-debian: Remove support for broken timezone names

[Guillem Jover]

Hi!

On Mon, 2016-06-13 at 16:44:03 -0700, Stuart Prescott wrote:
> > As pointed out in
> > <https://lists.debian.org/debian-policy/2015/06/msg00034.html>, the
> > changelog trailer part of the regex to support timezone names is bogus.
> > And it seems the best thing to do is to remove it instead of fixing it.
> > For more details either see tha above mail or the commit message on the
> > attached patch. Beware, that the patch has not been tested!
> 
> Thanks for the patch!

You're welcome!

> My understanding from the relevant thread is that this TZ name feature didn't 
> work properly in the past and that it now cannot be used because dpkg will 
> reject the changelog entry as being invalid. That should mean that we won't 
> see new changelog entries with the TZ name in them, but are there historical 
> changelog entries that include it? Do we know how many that might be?

As the commit log and the mail on that thread say, this has never worked,
so I'd be extremely surprised to see any such bogus timezones in the wild.

> python-debian's changelog support is used to iterate through the entire 
> changelog not just the last changelog entry so removing the ability to parse 
> these entries would either generate warnings or raise exceptions depending on 
> the strictness specified by the caller. 

The same applies to the code in libdpkg-perl, for which I removed the
broken regex part already. :)

> A question for you (and my co-maintainers), does it make sense to become more 
> strict in what is accepted?

That depends on what is being more strict. For dpkg (the run and build
time commands/code), which is kind of a sieve where almost any packaging
related thing has to go through, my intention is to incrementally make
it more strict, to reject bogus input. If necessary via long-winded
transitions, where for extraction and fetching it should almost always
be possible to turn any errors into warnings via user-selectable options,
but for building I might just make it fail hard and expect brokeness
to be fixed because old things might not be expected to build with a
modern environment anyway due to countless other changes.

Making "3rd-party" parsers more strict might be more tricky as they
do not have the luck of being the single canonical implementation,
so they might need to coordinate that strictness with other
implementations (dpkg, etc), or policy, to avoid the wrath of
infuriated users. :)

But as you see, yes I think in general we should try to be more
strict, this is something we have the luxury of doing in a tighly
controlled environment with a predominant reference implementation,
which would not be possible in a more decentralized one.

Thanks,
Guillem