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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
