On Mon, 2003-03-17 at 09:53, Vox wrote: > This time Fran�ois Pons <[EMAIL PROTECTED]> > becomes daring and writes: > > > Possible features of urpmi for next release : > > > > * virtual medium (no need to update explicitely, only with synthesis ?). > > * delay before accepting using a package from a medium (cooker) > > * always ask confirmation if fuzzy search is used (even for 1 package) > > * on the fly sorting of media (according to regex like > > file,rsync,ftp,http) > > * urpm centralized tools, as well as perl-URPM managing media. > > * p2p urpmi database (export database as magic synthesis) > > * -h by default for urpmi.addmedia > > * do install of package by groups which are shorter as possible (apt-get > > like) > > * allow file conflicts error to be handled by recovering errors and try > > again. > > * conflicts, provides and requires tag added for global rpm behaviour in > > order to allow broken dependencies to be not resolved or to avoid > > removing important package (generalize basesystem) > > > > Any other idea are wellcome. > > An --info or whatever switch to get the description of an > uninstalled package, just as you get it with rpm --info packagename > when it's already installed.
Vox, Do you mean like # rpm -qip http://redhat.secsup.org/redhat/linux/7.3/en/os/i386/RedHat/RPMS/4Suite-0.11.1-8.i386.rpm (try it it works) I chose this rh rpm because I knew it wouldn't be installed on your MDK box. *grin* (btw the switch is q as in query ip just in case of font problem) James > > And the build-from-source thing that Levi mentioned...specially > useful if urpmi "remembers" what has been built from source and what > has been installed from binaries, and updates accordingly...that > would absolutely rule :) > > Vox
