On Wed, 2003-10-08 at 21:09, Jim Wildman wrote: > On Wed, 8 Oct 2003, Garrick Staples wrote: > > > The reason why yum should do it because yum can pick the correct file, > > and knows exactly where it is located. ftp/web clients don't know this. So the crux of the problem is over-cluttering the cli with lots and lots of more options. how do we get away from that? to get around that. commands of yum: install update upgrade [deprecated - most likely) remove list search provides clean groupinstall grouplist groupupdate info check-update then an array of options: -y, -c, -e, -d, -t, -R, -C, --installroot, --version, -o (soon) -h let's think of all the possible other commands we could dream up: clone (download all the rpms for the current system) get/retrieve (just download the requested rpms) transaction (run the transactions requested in a file) noop (just to update all the headers or what not) mirror (make a dupe of the repos provided) (boy this sounds like rsync) fixdb (check and correct the errors in my rpmdb) installfile updatefile importkey source rebuild fixmycar promoteworldpeace cureflu you get the idea (other than the last 3) so how do we put all these in cli w/o driving people insane looking for their command? if y'all ever seen the cvs manpage, then you know what I'm talking about. I'm not sure - maybe all the rpmdb modifying commands run from one script (yum) and all searches/indexes/queries go in another(yum query), and all the 'meta' stuff (importkey, clean, fixdb, mirror, get, clone, etc) go in another (yum-meta). And maybe all the source rpm work goes into another on (yum-source). Who likes this idea? It doesn't mean all the crack idea get in but it makes me cringe less when I look at the command line parsing routine. -sv
