> I'm just throwing out ideas and "community input" to help resolve Seth's > perceived problem with these options. > > Playing devil's advocate for mandatory options... it would *force* people to > RTFM. The natural inclination of most users is to just try the most obvious > solution before RTFMing. If you, one of the developers, understands that the > user is going to miss vital information and that RTFMing will avoid landing > the bullet in his/her foot, then forcing the user here is a good thing. > > Wider commentary... I think this point's to one of yum's wider problems: lack > of focus. I asked once before (a long time ago), if yum was a convienence tool > to help out new users or if it was a power tool for advanced admins; the > question was never answered. I know what *I* use it for, I know what some > other people use it for, and I also know how else I'd *like* to use it. So I ask > again, what is yum's intended audience? If you've been following cvs-HEAD devel you may have noticed a direction I've been taking in the code. I've been de-coupling as much of yum from the backend code as possible. I've been doing this so that more user-oriented tools can be written using the same backend yum normally uses. Right now setting up a yum backend entails: - creating a yum base object - setting up the config file - populating repositories - at this point you can setup your rpmdb, repositories/packageSacks and depsolve. yumobj.doRpmDBSetup() yumobj.doSackSetup() [stuff happens here to populate the tsInfo with whatever you want to do] yumobj.resolveDeps() but most of the user stuff will stop after the SackSetup. once you know what you have installed and what packages are available in the repositories all the interesting user querying can happen. I've done this so yum can be a system updating and admin mgmt tool, but other interested parties can use the libs to do whatever they might want for the users. So does that help with your focus question? -sv
