negative priorities can't be set from command line

Bug #244603 reported by Edward Rudd
2
Affects Status Importance Assigned to Milestone
Smart Package Manager
New
Undecided
Unassigned

Bug Description

Exported from http://tracker.labix.org/issue348/

This issue still affects Smart 0.52 (Fedora 8 w/ pythin 2.5.1)

-- from 2007-10-02 @ 08:42 by thm
A workaround is to use the config subcommand like this:

smart config --set package-priorities.pkgname.channel=-10

-- from 2006-07-20 @ 17:35 by urkle
according to "smart priority --help" I can do this

smart priority --set pkgname channel -- -10

However I receive an error of "error: no such option: -1"

This occurs with both 0.41 (CentOS 4 w/ pytyhon 2.3.4) and 0.42 (FC5 with python
2.4.3)

Revision history for this message
Glenn D. (doiggl-hotmail) wrote :

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

Revision history for this message
Edward Rudd (urkle-outoforder) wrote :

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

Revision history for this message
Anders F Björklund (afb) wrote :

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

Revision history for this message
Edward Rudd (urkle-outoforder) wrote :

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?

Revision history for this message
Anders F Björklund (afb) wrote :

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.)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.