Thread Hijack - Our package management GUI tools need improvement

[Tim Lauridsen]

Mike Kearey wrote:
> In general our single, most commonly criticized feature is package
> management.
>
> I do think we need bigger efforts in this area:
>
> - Make the GUI tools _just work_
> 	For example, have one graphical tool. It should manage both on and
> offline package management. Make it such that it can manage package
> installs from CD as well as from mirrors. In the situation where the
> system has been updated, and the user is attempting to install a package
> from CD - If the package has deps that have been updated Tell the User.
> Explain that the specific package has been obsoleted. Offer the user the
> choice to go to updates mirrors on Internet to get the package or to cancel.
>   
The been changes in yum lately, there removes the need for downloading 
header, this is necessary to have media support
in yum and the tools using the yum API (pup, pirut, yumex etc.).
So media support is work in progress.

> - Integrate the GUI tools with the yum-updatesd - If there is a conflict
> when yum-updatesd is running, Tell The User. Explain why this is
> happening. Perhaps integrate the GUI tool in such a way that it starts,
> informs the user that yum-updatesd is running, and shows the status of
> yum-updatesd - plus the opportunity to control it.
>
>   
It's imported to know how the different tools works before taking this 
discussion.
yum-api : The yum backed python classes there does all the real action.
yum-cli: The yum command line tool.
yum-updatesd: The system  deamon there checks for updates, controlled by 
DBus commands.
puplet:  The update applet, there shows notification when updates are 
availible, it controls the yum-updatesd by DBus commands.
pup: A Gui for installing yum updates.
pirut: A Gui for installing and removing packages.
system-config-packages: A gui for installing af single local package.
yumex: Another gui for updating,installing and removing packages.
yum-utils: A collection of command line tools to do  different actions 
using the yum-api.

The yum-cli, yum-updatesd, pup, pirut, yumex, 
system-config-packages,yum-util is using the yum-api to do the real 
action and only one tool can
work at the time, so they use a locking system build into yum, all the 
tools will bail out if the yum-api is locked, the don't know what 
application
is locking the yum-api.

Only the the 'puplet' is aware of 'yum-updates', so if it runs in the 
background, you will get an error if you run one of the other tools.
Maybe if the applet was showing some kind of animated icon when it was 
working, the user would know why they cant run one of the other tools.
> - Make yum at least equal in speed to the alternative tools like apt-get
>
>   
The problem with comparing yum and apt-get, is that people forget that 
it is not fair to compare
the speed of 'apt-get update' and 'yum update', because the are not 
doing the same job.
apt-get update only work on a local cache, while yum checks if the local 
cache is warm, and reload it, if it has not been updates
recently.
some you have to compare a 'apt-get dist-upgrade; apt-get update' with 
'yum update'

> I constantly see people criticizing yum for it's apparent slowness. This
> has been going on for years now. We need to do real side by side
> comparisons to identify where the problems are. I am guilty of ignoring
> the slowness as it 'just works' for me and I am a happy sys admin for
> it. For many newer users, speed is essential. For many new users,
> installing packages, and exploring the system is the central activity.
>   
Then talking about speed you have to look at the step in a 'yum update' 
transaction.

1. initialization (reading config files, repo files etc.)
2. for each repo do:
    get a list of urls (load mirrorlist or use baseurls in repofile).
    get the the repomd.xml from the remote site.
    get the basic metadata primary.xml.gz (or primary.sqlite.bz)
    parse the metadata and insert it into the local sqlite db.
3. load the data in the local rpm db.
4. Match the local rpm db with the remote packages available in the 
repos to detected if something needs to be updated.
5. Depsolve the updates found in 4, to see if all dependencies is 
solved. (Extra metadata and rpm headers are downloaded (yum < 3.1.x))
6. Download needed packages.
7. Update/Install the packages in the transaction.

Looking at the speed of different steps.
1. fast.
2. The time depends of the number of repos and the size of the metadata 
and network bandwidth  and speed of the mirror used.
    The speeds is fast if the metadata has been loaded recently, because 
then yum will use the cached files.
3. fast.
4. The  time depends on the number of installed & availible packages.
5. The  time depends on the number of installed and the number of 
packages in the transaction, big transaction can take long time.
    The current yum 3.1.x release is slower than yum 3.0.x, because it 
has been totally redesigned, and it most importent that it is working
    right, before starting to optimize the speed.
6. Depends on the size of the packages to be downloaded, network 
bandwidth and the how fast the mirrors are.
7. Depends on the number of packages, the size and scripts include in 
the rpms. (RPM)

The only step 2 (the metadata parse) ,4 ,5  can be optimized in yum all 
the others are controlled by outside parameters.
In the daily use of yum on a stable version of Fedora, I don't think 
there are any speed issues.
Off cause if you are running a 500 Mhz, PII, with a 56 Kbits modem 
connecting, a OpenOffice  update > 100Mb sucks big time,
But that is not something you can bame on yum.

> So package management GUIs should not be under-estimated in their
> importance.
>
>   

package management GUIs are importent, this is why i have created yumex  :-) .

Tim