A few ideas.

[Debarshi 'Rishi' Ray]

I have been using YUM (and Pirut) on various versions of Fedora Core
for the past two or three years, and have some ideas to improve
certain aspects of it. I apologise for the cross-posting, but I figure
that this might be relevant to both the lists.

1. Enabling users to make 'yumpacks': This is inspired by
https://wiki.ubuntu.com/OfflineUpdateSpec to enable users of YUM (and
Pirut) to be able to install/update from packages downloaded on a
different machine on a standalone offline machine or one with very
harsh bandwidth constraints. Users having more than one machine, which
are not on a LAN, can also be benefitted since they need not download
the same things everywhere.

It is true that the samething can be done using:
a. yum deplist
b. wget
c. createrepo
d. yum localinstall
e. yum localupdate
However for those who are not conversant with the working of YUM,
Pirut, RPMs, dependencies, repositories, etc. will find it quite
difficult to do it. With the growing popularity of GNU/Linux on the
dektop, this is no longer a trivial issue.

Some use cases can be:
a. Manu has two machines-- one at work and one at home. The former is
blessed with a nice Internet connection, while the other one is a
standalone machine. Manu has just installed Fedora Core 6 on both his
machines but does not really know much beyond 'yum install' and 'yum
update', and his heavily dependant on the GUI since he is not a geek.
He loves the system, and wants to install his favourite media player
on his home machine. He has it on his office box, but the lack of
Internet connectivity at home is a problem. He has read some material
about making YUM repositories, but what he would love is a simple
interface to do the whole thing. eg., "yum makepack <mediaplayer>" or
a click and go feature in Pirut. Once the pack is made and saved in
the desired location he can care it home on his pen-drive and enjoy
the latest movie with his wife and kids.
b. Rakesh has five different machines and they are not on the same
LAN. Although both are connected to the Internet, the bandwidth is not
of the best quality. Downloading the same updates and packages on both
machines is quite a pain. He wants a simple facility by which he can
create a 'yumpack' everytime he installs or updates something on one
machine, so that he can use the same 'yumpack' to repeat the
installation or update on his other boxes.
c. My grandmother is fascinated by the talk of Free Software. She
wants to try out Fedora. She does not know much about computers, and
it is not possible to teach her about YUM caches, repositories,
dependencies, etc.. She also finds it difficult to figure out what
package to install using YUM and Pirut. I want to give her a 'yumpack'
on a CD containing the packages she wants to have on her desktop, so
that all she has to do is ask YUM or Pirut to install whatever is
there in the pack. She just has to remember one command-- something
like: "yum usepack <pathtopack>", and not "yum install <package1>",
"yum checkupdate", "yum -y update", etc..

2. I recently learned that it is possible to download deltas of RPMs
instead of the whole package. Exploiting this feature in YUM (and
Pirut) can be extremely beneficial in conserving bandwidth and cache
size. Making 'yumpacks' (see point 1) can will also become quicker and
result in smaller packs being made, since one would not need to
download and put the entire RPM in the pack if the currently installed
version of the package is known.

I have heard deltarpm does something like this, but have not come
across something in YUM or Pirut which makes use of this.

Some use cases:
a. Arjun has a very slow connection to the Internet which is not
available 24x7. Everytime he does "yum -y update", the slow network
ensures that he has to keep his machine on for hours. Even then he
experiences time-outs while downloading large packages (say >2M) and
because the Internet is not available 24x7 this makes things more
difficult for him. Arjun badly wants to circrumvent this problem. He
wants to upgrade package 'foobar' and the RPM is 20M. However the only
change as compared to the one he already has is a small, but critical
segmentation fault problem. So it would be really good if he can
somehow download a small diff and patch his installation using YUM
(and Pirut).
b. Ranjeet wants to give his brother all the latest RPMs in the
updates repository. However they take up too much space to fit on a
CD. Ranjeet does not have a DVD-RW drive so he has to use multiple
CDs. Since his brother regularly updates his box, all that is needed
are the diffs and not the entire packages. Ranjeet can make smaller
repositories (or 'yumpacks') for his brother if he and his brother can
use the diffs in YUM (and Pirut).

3. A "apt-get update" and "apt-get upgrade" combination for YUM and a
'refresh package information' for Pirut, so that the package
information is updated only when explicitly stated by the user.
However I do not know whether this is already available in YUM (and
Pirut) or not.

What I have learned is that the 'metadata_expire" value in yum.conf is
used to decide when the meta-data is marked stale. The usual default
setting of 1800s is too low and effectively every time someone starts
YUM (or Pirut) it starts downloading the full package information from
the remote servers. With the exception of extremely quick networks,
this causes YUM to take a long time to actually start doing something.
Pirut gives the impression of having hung or crashed. The more
repositories you have enabled, the more enhanced is the problem,
making these aplications (especially Pirut) almost unusable.
Increasing the 'metadata_expire' value to something like 24*10*3600
can work, but for novices this is difficult to figure out and in my
opinion is not an elegant solution.

A use case:
a. Vivek has just shifted to Fedora from Ubuntu/Debian. He tries out
Pirut and is apalled by the amount of time it took to display the
packages list. He badly misses the feature in Synaptic which enabled
him to update his package information only when he desired to. Same
applies for YUM too.

Phew! That was long, but did I make any sense? Comments?

I know Python and would love to help out in developing any of these
features if you find them useful.

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