[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Thread Hijack - Our package management GUI tools need improvement

Mike Kearey wrote:
In general our single, most commonly criticized feature is package

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

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]