Yum Applet
Since Fedora Core 4, when the old RHN applet stopped to function, Fedora has needed a new mechanism for telling the user that updates are available. For convenience, we are calling this the Yum Applet.
| Latest news: Coding work has begun on this project. To participate, join the yum development mailing list and take a look at the code in the yum CVS repository . |
Functional discussion
There are two possible ways for the applet to act visually:
- One is similar to the previous RHN applet, showing a blue circle check sign when it's sure there are no new updates, a red circle with an exclamation mark when there are new updates (and possibly also when the system in not configured yet), a green circle with double harpoons when the update server is being queried, and a gray circle with a question mark when the status can't be known (like when the network is disconnected, or possibly also when the system is not configured yet). A distinction between security and bugfix/improvement updates may also be useful, using the red sign only for alerts about the availablity of security updates, and a new sign for bugfix/improvement updates. (This distinction is currently not technically possible, because yum does not support it.)
- The other mechanism is using a Notification Area icon, which only appears when updates are available. New icons would be needed for this, somehow hinting toward the availablity of new updates (or that the system needs security updates). New icons are necessary because while a red exclamation mark where there used to be a blue check mark makes sense, but it won't necessarily make sense as an stand-alone notification that only appears sometimes.
A way for choosing which, may be referring to the guidelines in GNOME HIG , Section 2.4 .
Because of security considerations, the system must be on and properly configured by default, functioning out of the box.
A mechanism to disable the system (remove the applet or silence the notification) by the user may be desirable. Technical consideration: if the system is implemented using a cron job (see below), users without root access may not be able to turn off the cron job. I don't know if they should be prompted for the root password, or what.
Note from skvidal: We should be able to make the applet simply stop responding to the dbus events, too, right? Then they won't need root access and the cron job is just harmlessly getting updated metadata and emitting a dbus event that no one is listening to.
Icon Development
Icon development has started: NewIconDevelopment - Icon development fedora-art-list discussion
Technical discussion
The following architecture is suggested for the system:
There are two subsystems. A cron job (or alternatively a daemon), which updates the metadata at regular intervals using the yum python module (see below for discussion about the default interval) and emits a dbus event (or one event for each update?). And an applet (or daemon again), that catches the dbus event(s) and acts on that, starting pup in case of a user click or something. The applet should be as simple as possible ("less things to break and less things to eat memory"), and the complicated stuff should be preferably done by the subsystem.
The subsystem should be written in Python, but the applet should be in C. ("The python abstractions for the applet aren't really light - ISTR that a good 20MB of the applet's memory use was just in the core applet code pygtk, outside of any RPM information." [1 )
The cron job/daemon thing may also be able to support more fancy things over the dbus interface. For some ideas, See this post by Bill Nottingham.
A proof of concept code by SethVidal and PaulNasrat is available here . Paul may even have a newer version.
Default update interval
In choosing the default regular interval for checking for updates, a consideration of the load on the yum repository mirrors may be necessary, as presently not every Fedora installation uses updates, and with enabling this applet, updates (or at least fetching the metadata) will become much more frequent.
In order to save server bandwidth, the system may choose to not check for new updates for a longer while if already knows that not-yet-installed updates are available. This usually means that the user does not really care about the updates, or can't update the machine anyway (she may not have root access, for example). If a distinction is made between security updates and others, the system should still check regularly for updates, if the not-yet-installed updates were non-security ones.
If this is implemented using a cron job, cron's limitations should also be considered, for example, things will be much easier if the cron job could use already existing infrastructure of
A consideration for the default hour of updates may also be good. If there are many installations in, say, Eastern United States (using EST), and all of them check for updates at a certain time of the day, the server load on that time would be very much like a distributed denial of service attack. So, the cron job may want to wait for a random amount of time before checking for the updates. But only if it's run through cron proper, not anacron. If the anacron job is delayed, the update may actually never happen. (I really don't know how complicated is this to implement.)
Note from skvidal: This isn't too hard to do - yum has a -R option that waits a random amount of time before performing the rest of the action.
This document was originally drafted by RoozbehPournader, based on IRC discussions with SethVidal, inspired by a blog posting of Seth's, and a thread on fedora-config-list titled crazy ideas for yum/pup/that_damned_applet .