Re: moving a to a: in getopt (was Re: apt-listchanges: changelogs for tglase-nb.lan.tarent.de)

[Guillem Jover <guillem@debian.org>]

Hi!

On Sat, 2020-06-27 at 19:11:38 +0200, Thorsten Glaser wrote:
> On Sat, 27 Jun 2020, root wrote:
> > dpkg (1.20.0) experimental; urgency=medium
> > 
> >   [ Guillem Jover ]
> >   * perl: Switch Getopt::Long from bundling to bundling_values. This means
> >     the few scripts using Getopt::Long will stop accepting options in the
> >     form «-ab» for «-a -b», which is not future-proof, as it does not allow
> >     these options to get new arguments without making them ambiguous.
> 
> You shouldn’t do that for two reasons:
> 
> 1. It breaks existing users that use the short form.

That use the bundled short form, true.

> 2. For your example, if -a were to ever gain an argument, the existing
>    -b is silently used as the argument and not parsed as option any
>    more breaking everything horribly.

This should not be a problem, as long as at least a whole release has
passed before considering adding any such arguments to these options,
which TBH I don't see happening in the near future anyway.

> For this reason any existing option MUST NOT get an argument later.

This is currently restricted to only 4 perl scripts that use
Getopt::Long (that is dpkg-checkbuilddeps, dpkg-mergechangelogs,
dpkg-scanpackages and dpkg-scansources). The rest have an open coded
argument parsing implementations, which do not accept option bundling
(but do accept argument bundling).

The plan is to switch every perl script to use Getopt::Long, using the
same format for consistency, and I'd rather not make the bulk of the
scripts more loose in that sense.

There are also a few options that take no arguments, where other
options are accepted:

  dpkg-checkbuilddeps (-A -B -I)
  dpkg-scansources (-n)
  dpkg-scanpackages (-m)

So it does not look that bad to me TBH.

Thanks,
Guillem