On Fri, 2007-03-09 at 18:06 +0530, Debarshi 'Rishi' Ray wrote: > First of all someone who is using the command line interface and not > the GUI, even when the GUI is available, is not a complete newbie. If > he has the acumen to remember the 'cd', 'clear', 'ls', 'sudo yum', > etc. dance then why can not he/she remember the 'apt-get update' and > 'apt-get upgrade' dance? > I suppose this is a fair enough assumption. But, unlike 'cd', 'ls', etc which perform _immediately-required_ actions, 'apt-get update' (from a semi-newbie point of view) does nothing tangible. (Think: "It's updating the repository information? What's that? Why is this needed? Why can't I just install the program?") So unlike the basic commandline commands, the "apt-get update" command gives no immediately obvious results to someone coming from, say, That Other OS. Explaining to them what "apt-get update" does is usually pointless, as they do not always understand and definitely don't care. They _just want it to work_. Oh, and you'd be surprised at how many "newbies" use/want to use the command line (see comments about the yum gui below)... > Even if it is still a problem, then consider that we have yum-updatesd > downloading update information automatically in the background, and > Yum itself engineered in such a way that it will download update > information after 'metadata_expires' is reached. No matter how high > the value of 'metadata_expires' is, this is simply not needed. If I am > a newbie, and can not handle the 'apt-get update' and 'apt-get > upgrade' dance, I will simply ask yum-updatesd to do the job for me. > Provided, ofcourse, I have the bandwidth to do it efficiently. > Otherwise, if I know my way around or have bandwidth issues, then I > shall simply switch of yum-updatesd and resort to the apt-get update' > and 'apt-get upgrade' dance. > Fair enough, but if you know what you're doing, then why not simply use something like "yum -C update"? This does the same as "apt-get upgrade", i.e. it runs from the local metadata cache. > Secondly, since most newbies are prone to use GUI tools, if Pirut has > a nice icon (like Synaptic) that prominently announces: "look for > updates", then I do not think people have to remember any dance > sequence at all. As far as I have seen, Ubuntu users (mostly newbies > not knowing what 'ls' and 'clear' are) are so happy with their > distribution simply because Synaptic precisely does this. I have not > seen a single Pirut user who is even marginally content. If such a > feature was removed to help any newbie, then it has surely failed to > do so. > > Before finishing let me give my own example. The only repositories > that I use are Fedora's Core, Updates and Extras; and ATRPMs. All > these are mirrored locally on my LAN, and I do not use the upstream > repositories ever, except for keeping the local ones updated. I do not > run yum-updatesd too. On such a set-up when I start Pirut, it takes 15 > seconds to show the initial window, which is the 'browse' (leftmost) > tab. Funnily it has no package or category listed. When I click the > 'list' (rightmost) tab it takes a further 60 seconds to show the > package list. Everytime I change tabs and come back to 'list' it takes > the same amount of time as before. Since I do not use a US English > desktop the tabs might not be named exactly 'browse' and 'list', but > that is what they look like from the local language traslation. I agree, Pirut's "lag time" is a pain, and as a whole the GUI isn't as streamlined as Ubuntu's GUI update manager (synaptic with a "friendlier" starting point). It's "list-page slowness" has some more problems than just a "yum update"-induced issue, however; imho this needs _desperately_ needs to be looked at. Some of our newbie users actually prefer the yum-cli because of this. I submitted a "concept" patch a while back that allows "off-line" and "non-root" usage of Pirut (amongst some other things) - this same technique could be used to lessen the metadata-update requirements of the GUI, at least. Interestingly enough, we are running a very similar setup. I, however, use a managed mix of core, updates, extras, livna, rpmforge, kde-redhat, freshrpms and dribble, and all our local machines update from a centralized cache. As you can guess, this cache serves a fairly large amount of machines. Explaining basic repository management (read: apt-get update; apt-get upgrade or apt-get update, apt-get install X) to _all_ of the people becomes a bit of a drag when a single "yum update" or "yum install" command is enough. This is the same with Synaptic; the package metadata gets old eventually (however it does prompt the user when this happens, which is nice). > I am basically an end-use when it comes to Yum and/or Pirut, but I > know Python and do some programming and would like to help out > regarding this if required. > Me too. Is there some (clear) way that the community can get more involved in Pirut/yum's development (outside of only writing yum plugins)? To summarise: I agree with almost everything you are saying (especially the GUI-related stuff), I just feel that yum's _default_ behaviour should not necessarily be similar to apt's. :-) Cheers, -Francois -- This message is subject to the CSIR's copyright, terms and conditions and e-mail legal notice. Views expressed herein do not necessarily represent the views of the CSIR. CSIR E-mail Legal Notice http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html CSIR Copyright, Terms and Conditions http://mail.csir.co.za/CSIR_Copyright.html For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR Legal Notice send a blank message with REQUEST LEGAL in the subject line to CallCentre@xxxxxxxxxxx This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
