On 23 May 2003, seth vidal wrote: > > > > Although it's an extreme example, I refer to the man pages for Perl. > > > Would anyone really want to make that One Big Man Page? > > > > > > > No. But seperete yum-tool-command programs is opposite of yum's current > > mode f operation. It's contrary to the way things work currently. > > > > I don't understand why we can't have a yum-tool that understands verbs but > > also is able to implement verb based the name of the called program (much > > liek the way the startup scrtipts are handled, then everybody can have it > > their way: There's a yum-tool command, but there can be symlinks back to > > yum-tool for each verb it understands and presenst it's self like a > > command. > > > > This goes farther than I'm comfortable with for fairly specific reasons: > 1. it's cluttery > 2. it eats inodes (all those symlinks) > 3. it makes tab completion hard > 4. it means the rpm has to keep up with additions to functionality in > the code It is also interesting to note at this point (as I screw around with rebuilding xmms on my laptop under RH 9 so I can play all my various legacy mp3s, grrr) that rpm appears to have "just" split into rpm and rpmbuild, presumably for all the reasons being discussed here with regard to the (far simpler) yum. popt is used to alias them back into a single "command" by diehards who prefer to just use rpm and sort-of-the-old commands form. Discovering this I got to experience firsthand all the joys of split up commands. First one tries rpm --rebuild as usual, it barfs, you RTFM and learn that they split off the build commands (while, amazingly, still leaving them just as broken and nonintuitive as they ever were:-). Even though my fingers still want to type rpm -ba and so forth, RH did use a logical breakpoint, at least, to split the command, and I imagine that I will relearn and might one day even find it simpler this way. However, because they split out and renamed one of the MOST often scripted variants of rpm, I can now look forward to the true joy of fixing rpm build targets in a staggering list of my personal makefiles. Still, that's why god made sed, find, and scripting languages -- to test our faith and patience fixing fallout from other folks' "good ideas". It will be especially fun fixing the Makefiles to automagically work on both new e.g. RH 9 systems and old e.g. RH 7 systems -- a simple "sed -e "s/rpm -ba/rpmbuild -ba/g" will not work unless I want to break the makefiles for everybody using older versions of rpm, so I'll have to figure out a script fragment that determines whether rpmbuild exists and uses it or falls back to rpm. Torture. This kind of worrisome pointless drift that at first glance SOUNDS like a good idea, but that in actual fact ends up punishing the hell out of everybody in the known universe that builds rpms with scripts or make targets is what concerns me. I think you have to be very careful to have a very clear rationale and to think about side effects before splitting something up. Sure, rpm was overly complex (like tar, perl etc) with arguably "too much" wrapped into a single command (although of course ALL the scripting languages are invoked by a single command, not "perl" for one language command and "perlfun" for another), but rpm has FOUR distinct operational modes and they only split off ONE, and the one they split off is the one that will absolutely certainly break every makefile in existence that has an rpm-building target. What, are they going to wait to split off the informational, the installation, and the "miscellaneous" (db) commands? Are they going to really spread the torture out, so those of us who learned long ago how to invoke the commands in these modes have to RElearn where they are? Sigh. Lessons to be learned here, as well. Now consider yum's single, simple, intuitive interface: yum [verb] [modifier] [objectlist] This is information-theoretically compact and makes sense linguistically -- there are only a handful of unixoid -letter flags, the verbs are totally intuitive whole words with synonyms like erase and remove painlessly recognized. yum specifies taskset and language you gonna do something with. verb is what you gonna do. modifier tells you how you gonna do it, with a few, rarely needed "flags" (almost NEVER needed interactively). objectlist tells you what you gonna do it to. It doesn't get any simpler, really. The same syntax is in common use in shells and scripting languages and in many unixoid commands for that very reason. Altering this, you aren't going to make it less complex -- at best you're turning it into yum-verb1 [modifier] [objectlist] yum-verb2 [modifier] [objectlist] or worse, yum-tool1 [verb1 or verb3 or verb4] [m/o] yum-tool2 [verb5 verb2 verb6] [m/o] ... (order deliberately scrambled) where you have to BOTH remember the list of verbs (which is the irreducible and REAL source of both power and complexity and which define everything that yum can, literally, "do" as an action) AND where they reside. C'mon, without looking now, was verb4 in yum-tool1 or yum-tool2? Is the verb "info" (info me baby:-) in yum, or would that be in yum-tools, or yum-misc...? How many scripts already wrap up yum commands that would have to be rewritten if the verb they implement happens to move to yum-tools? I reiterate -- the yum interface is actually amazingly SIMPLE at this point, and is likely to remain so even if every command thus far suggested is added. yum [v/m/o], piece of cake. Learn the (short!) list of verbs and you're DONE, for the most part, as the objects are generally pretty obvious -- a few, rarely needed command flags for the various verbs, a few fullword modifiers. If yum >>must<< be split, for God's sake split it in a very deliberate, functionally grouped way, that won't break many scripts now or later (the info-user/functional-root split is ideal in this regard as long as functional-root remains just plain yum, since that is what is likely cron'd in scripts). Finally, just split it ONCE, now, and then try to never have to split it or to have to arbitrarily "decide" where to put new features ever again. With a good functional split it should be obvious which subspace a new command belongs to, and the new name should be a perfect mnemonic of the split and not "yum-tools". The whole command space is a set of "tools", for Pete's sake. How am I to guess which particular verb is a "yum tool" vs just a tool in just plain yum? Still, at least one good thing about a root/user split is that LOTS of yum users would only have to learn the informational unprivileged verb (command) set; splitting it would actually make their task easier. This could, maybe, balance the otherwise mostly negative aspects of a split. rgb -- Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@xxxxxxxxxxxx
