[pacman-dev] [PATCH] contrib/paclist: Add "--help" command line parameter

[Dave Reisner]

On Mon, Dec 05, 2011 at 09:11:28AM -0600, Dan McGee wrote:
> On Sun, Dec 4, 2011 at 10:21 AM, Lukas Fleischer
> <archlinux at cryptocrack.de> wrote:
> > On Sat, Dec 03, 2011 at 11:56:09AM -0600, Dan McGee wrote:
> >> On Fri, Dec 2, 2011 at 6:44 PM, Lukas Fleischer
> >> <archlinux at cryptocrack.de> wrote:
> >> > On Fri, Dec 02, 2011 at 10:10:14AM -0600, Dan McGee wrote:
> >> >> On Fri, Dec 2, 2011 at 2:49 AM, Lukas Fleischer
> >> >> <archlinux at cryptocrack.de> wrote:
> >> >> > Be consistent with all other contrib scripts and support the "--help"
> >> >> > command line switch. Fixes FS#27258.
> >> >> Where are we on consistency here with what we expect out of scripts in
> >> >> scripts/? All of these support -h/--help/-V/--version; is it logical
> >> >> to require the same for scripts in contrib?
> >> >
> >> > You surely know... :) I only saw that bug report and found it weird that
> >> > paclist displays a usage message if we pass no parameters but does
> >> > nothing when it is invoked with "-h" (as opposed to all other contrib
> >> > scripts).
> >>
> >> Well my gut tells me "yes, we should do this". Take a look at
> >> scripts/Makefile.am, namely the first two lines- it would be nice if
> >> we could do this in contrib/ as well.
> >>
> >> I'll apply this; awaiting further patches for fixing the rest of the
> >> scripts and adding the above automake option. :)
> >
> > Alright! What to do with contrib scripts that currently do not have a
> > version defined? I noticed that we're pretty inconsistent here:
> >
> > * All "official" scripts use the same version number as pacman(8). Also,
> >  we include "(pacman)" in the version output, here.
> >
> > * Some contrib scripts use their own versioning scheme (e.g. there's
> >  bacman 0.2.1 in master).
> >
> > * Some contrib scripts don't support "--version" and hence don't have a
> >  version number at all.
> >
> > What we can do now is either tag scripts, that don't have a version
> > number yet, with an initial value (such as 1.0.0) or always use the
> > pacman version number. I'd prefer the latter. Opinions?
> 
> Given that they live in the pacman codebase now, I'd also prefer the
> latter. This will also simplify bug reports and the like. I'd also
> bump ones like bacman that have a version number to just using the
> pacman one.
> 
> -Dan
> 

+1 to using pacman's version number globally.