pup: boon or curse? quicker updates or slower updates?

Fri Mar 9 13:42:37 UTC 2007

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 at csir.co.za.

This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.