Seth, On Wed, 28 Aug 2002, seth vidal wrote: > On Tue, 2002-08-27 at 15:40, Connie Sieh wrote: > > One reason why I selected yum was because it was small and easy and did > > not have lots of options which only confuse the users. > > > > I need a way to update out of date rpms automatically. > > > > I need a easier way(than downloading via ftp after figuring out > > lots of dependencies) for end users to install new rpms. > > > > I need a way for end users to update out of date rpms. > > > > Sure there are other things that would be nice. One of those was the > > mirroring. So yum did not do it so Troy wrote scripts to do it for us. > > > > so I'm going to respond to rob's comments and your's here: > > I agree about a simple interface for a user. I don't want to add > complexity if it doesn't help me out. I liked yup, from a while back, > and I thought the interface was REALLY easy - I just told it what I > wanted and it got it - but it wasn't fast and it broke a lot, so yum is > fairly fast in comparison and it is less prone to breaking, I think. > > but its got to continue doing what I want - which is update a bunch of > systems easily and allow me to install stuff whenever I want it w/o > having to hunt for things. > > However, I think we can add options w/o adding more work - ie - make the > advanced features be just that -advanced - but not required. > > so I'd like to think someone could continue telling users: > > yum update > yum install [blah blah blah] > yum remove [blah blah blah] > > that I'm cool with and I think that should probably be the default set > of arguments > I agree. I really do not want to have to tell users to use the -this and -that option all the time. The default should be what users need and expect most. > but I think rob might have a point - some of those features could be > useful - but I think they should be renamed/organized. If they were renamed then that might not be so bad. > > most of that will involve trying things and seeing what sucks and what > doesn't suck and how to keep from breaking people's scripts too badly. > Thats why I wanted to have this discussion to see what things should be > included so I know what to be worried about. > > > > The question if install should update is a good one. I cannot think of a > > reason to not update as the default way of doing it but there may be a > > case. One could always install then do a update but then we would have to > > train the users again. So maybe a switch that only installs but have the > > default install option to update if necessary. > > I think as troy put it was good. > > yum update - update only - if its not update-able then error out. > yum install - update if its installed already, otherwise just install - > however, if its installed and current then bail with a "this is > installed, you dolt." error. > > no retraining necessary. > Yeah. > > To rob's requests: > yum ain't going to parse kickstarts.cfg anytime soon, quit dreaming.:) > > however, I like the idea of a url-retrievable command file. > > ideally so one could have a "script" of commands that a single yum > session would run through. It could speed up multiple-operations > tremendously, but there is thinking to be done here, before thats > implemented. > > Regarding dist-version upgrades - I think that can happen - but there > might be a couple hangups to making it happen smoothly - right now yum > scratches an itch - if its going to have more infrastructure to include > things like dist-commands i'd like to sit down and plan out those steps. > > > Connie/Troy: > regarding mirroring - tell me again the situation you're in and how you > want to deal with it, then I can see if I can actually implement > mirroring in yum where it will be helpful to you/others. Do not need it now as Troy's script should work for us. We need mirroring to handle the cases of a server being down and to help with future scalability. We currently have about 1300 autorpm users and with autorpm downloading every rpm every time it connects the load can get high. We stagger the starts when possible. I really expect yum to scale well but want to have the ability to have multiple servers. My point with the mirroring issue is that yum does not really have to do everything including the kitchen sink as some of these features can be implemented via other means. Sometimes it is best to put the feature in "the product" vs using some outside method and sometimes it is not. We needed to pick a product other than autorpm. We looked at the trade offs of all the products and yum had everything we needed except for mirroring, so we just added it externally. There are few possible holes(the script can check that the server is ok but some other client can have connected in the meantime and there is a possibility that we could not get in) in this method but I think we can live with them until yum can do mirroring itself. > > > > Just in general, right now, yum, excluding package groups, does what I > wanted it to do - I'm fairly pleased with how some of it has turned out > and I'd like to thank all of y'all on this list for your > help/suggestions/patches/code etc > I would like groups too, I understand the issues you face with putting it in. > > -sv > > > -connie
