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

Debarshi 'Rishi' Ray debarshi.ray at gmail.com
Fri Mar 9 12:36:55 UTC 2007


I would not quote anyone since the same point is being discussed
simultaneously on three different threads.

One argument that I constantly hear is that the packages in the Fedora
repositories are so frequently updated that it is not advisable to
keep a high value for 'metadata_expire' to ensure that Yum does not
miss out on any recently available packages/updates.

Although this sounds nice, but there is an inherent flaw in this
argument, which becomes underlined when one uses it on slow networks.
In places like India, Bangladesh, and maybe Africa too, not too many
people are blessed with an Internet connection that can allow them to
download the whole package list everytimebefore doing anything
worthwhile with Yum (and Pirut). The fact is that _just_ installing a
package is much more important than installing the _latest_ version of
it. eg., my father does not really care if he uses version 2.2.3 of
package Foo or version 2.2.5 of Foo. If he needs Bar, and can not do
'yum install bar' quickly enough simply because Yum needs to download
the whole list of available updates, and find out whether Foo 2.2.5 is
available or not, before starting to actually download and install
Bar, then I am sure he would not like it.

One more thing I heard is that people do not understand the 'apt-get
update' and 'apt-get upgrade' dance.

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?

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.

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 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.

Regards,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu




More information about the fedora-devel-list mailing list