On Mon, Dec 05, 2011 at 09:11:28AM -0600, Dan McGee wrote: > On Sun, Dec 4, 2011 at 10:21 AM, Lukas Fleischer > <[email protected]> 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 > >> <[email protected]> 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 > >> >> <[email protected]> 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.
