negative priorities can't be set from command line

It it an option to use a later version of smart .
Something greater than Smart 0.52
e.g:

# rpm -qa | grep -i smart-
smart-ksmarttray-1.1-2.3
smart-1.1-2.3
smart-gui-1.1-2.3
linux:/ # smart priority --help
/usr/lib64/python2.6/site-packages/smart/const.py:39: DeprecationWarning: object.__new__() takes no parameters
  instance = klass._registry[name] = object.__new__(klass, name)
/usr/lib64/python2.6/site-packages/smart/util/strtools.py:28: DeprecationWarning: the md5 module is deprecated; use hashlib instead
  import md5
Usage: smart priority [options]

This command allows changing the priority of given packages.
Packages with higher priorities are considered a better option
even when package versions state otherwise. Using priorities
one may avoid unwanted upgrades, force downgrades, select
packages in given channels as preferential, and other kinds
of interesting setups. When a package has no explicit priority,
the channel priority is used. The channel priority may be
changed using the 'channel' command, and defaults to 0 when
not set.

Notice that negatives priorities must be preceded by '--' in
the command line, otherwise they'll be interpreted as command
line options.

Options:
  -h, --help Show this help message and exit
  --set Set priority
  --remove Unset priority
  --show Show priorities
  --force Ignore problems

Examples:
  smart priority --set pkgname 100
  smart priority --set pkgname mychannel -- -200
  smart priority --remove pkgname
  smart priority --remove pkgname mychannel
  smart priority --show
  smart priority --show pkgname

On systems that are running 1.1 (ie.. my Fedora 10 box)

#rpm -qa rpm -qa smart\*
smart-gui-1.1-58.0.1.fc10@x86_64
smart-update-1.1-58.0.1.fc10@x86_64
smart-1.1-58.0.1.fc10@x86_64

#smart priority --set test -- -100
error: no such option: -1

Even through the help documents that it is valid syntax (as you showed for 1.1, which 0.52 says the same thing) it does not correctly work. this looks like a bug in the getopt parseing that smart is doing

Smart runs optparse twice over the arguments. Once for "smart" and once for the command.
So if one wants to escape something for the final command, it needs to have -- listed twice...

smart -- priority --set test -- -100

ok.. I have to say it.. "Ewww." I would still consider this a bug then, as that's not the documented expectation, and it is not very intuitive at all..

Is there another way optparse can be run to not require BOTH sets of "--"s?

I believe the fix is to set parser.disable_interspersed_args() on the main parser (in smart.py), so that it doesn't stumble across the options intended for the command but let the second parser handle these.

     | allow_interspersed_args : bool = true
     | if true, positional arguments may be interspersed with options.
     | Assuming -a and -b each take a single argument, the command-line
     | -ablah foo bar -bboo baz
     | will be interpreted the same as
     | -ablah -bboo -- foo bar baz
     | If this flag were false, that command line would be interpreted as
     | -ablah -- foo bar -bboo baz
     | -- ie. we stop processing options as soon as we see the first
     | non-option argument. (This is the tradition followed by
     | Python's getopt module, Perl's Getopt::Std, and other argument-
     | parsing libraries, but it is generally annoying to users.)