On Wed, Aug 17, 2011 at 7:22 PM, Allan McRae <[email protected]> wrote: > On 18/08/11 09:34, Dave Reisner wrote: >> >> On Thu, Aug 18, 2011 at 08:57:55AM +1000, Allan McRae wrote: >>> >>> On 18/08/11 08:27, Dan McGee wrote: >>>> >>>> On Thu, Jul 21, 2011 at 3:40 PM, Dave Reisner<[email protected]> wrote: >>>>> >>>>> In addition to being what I feel is a cleaner and faster >>>>> implementation, >>>>> we avoid the use of eval by normalizing option arguments into a global >>>>> array which is then set after a successful call to parse_options. >>>>> >>>>> This trims out the idea of having multiple arguments to a single >>>>> option, >>>>> making our parsing algorithm a little more sane. We never took >>>>> advantage of >>>>> this in makepkg (for the one option that feasibly supports it), and I >>>>> think we've overlooked a much simpler solution in pacman-key. Since >>>>> actions are limited to 1 at a time the leftover positional parameters >>>>> become the keys or keyfiles which are acted upon. >>>>> >>>>> Also added is a new test directory test/scripts with a harness for >>>>> parse_options, run as part of make check. >>>>> >>>>> Signed-off-by: Dave Reisner<[email protected]> >>>>> --- >>>>> Thoughts? I know Allan wasn't quite sold on this, as the downside is >>>>> that we >>>>> sort of pigeonhole ourselves into using the non-optional parameter as >>>>> arguments >>>>> to our action. This has zero effect on makepkg. >>>>> >>>>> I've also thought to add --option=arg syntax parsing, but I'm not sure >>>>> we need >>>>> this. >>>> >>>> Allan, was deferring to you on this. >>> >>> >>> Well, I was deferring to you as Dave is right that I was never sold >>> on this... >>> >>> Unless I am missing something, this does have a minor effect on >>> makepkg. In git "makepkg --pkg foo bar" builds only foo and bar >>> from a split package. >> >> And, imo, this introduces bizzare unexpected behavior. With the >> "standard" getopt{,_long}, passing something such as: >> >> --pkg foo bar >> >> I'd expect bar to be completely unrelated to the flag. Not the case >> here, and this behavior isn't really documented clearly at all. We don't >> even properly handle arguments with whitespace anymore. Not such a big >> deal for makepkg, but I think it's reasonable that pacman-key might some >> day need to import a key from a file with a space in the name. > > I thought the whitespace issue was fixed but testing now I see it is not. > That is definitely something that needs addressed. > >>> I guess with this patch we would have to quote the package names in >>> some way (like is needed on the current maint release). So we would >>> need to revert changes made to the makepkg documentation when the >>> multiple arguments stuff was added. >> >> We can (should?) follow pacman here and separate multiple arguments by >> commas. I'm going to channel Dan and call out "consistency" here. > > You mean like "pacman -S pkg1,pkg2"? Fairly sure we do not do that! So I > call consistency... Where do we use commas in pacman options?
pacman -Syu --ignorepkg foo,bar.baz
