Tue, 15 Aug 2006
Thanks to the previously mentioned core update metadata enhancements that I've been working on lately, we are now able to do some pretty neat stuff with our package updating tools. So last week I cranked out a bunch of code for Fedora's package updater (pup) and it's notification applet (puplet) to utilize this new enhanced metadata and actually provide the user with some useful information.
In order to be able to attach the notification to a status icon, I had to patch libnotify's python bindings to utilize libnotify's notify_notification_attach_to_status_icon function (notify-python-0.1.0-attach_to_status_icon.patch). While poking around with the notify-python code, I tripped over a bug in libnotify that needed to be patched as well (libnotify-0.4.2-status-icon.patch). I hope to kick off patched versions of libnotify and notify-python for rawhide at some point in the near future, and apply my puplet patch as well (puplet-bubbly.patch).
For pup, I whipped up a hacked out GtkTextView to display the new update metadata, when it's available (pup-enhanced-metadata.patch) (the look and feel will most likely change). Due to the current core/extras dichomoty, this update metadata is only generated for core updates until we get a common core/extras update system in place (I've been working on porting the current update system for core over to TurboGears, and make it encompass core/extras/legacy updates). Hopefully by FC7 we will have bridged the core/extras gap completely (optimism++).
Mon, 14 Aug 2006
Fedora update metadata
I just committed my createrepo update metadata acquisition patch to HEAD which adds support for the -U (--update-info-location) flag. This feature is going to give mirrors the ability to pull in update metadata [example: httpd-2.0.54-10.3.xml] for each corresponding package in the repo. This will allow tools such as pup to know exactly why an update was released, and present the user with all of the details. The next step is to setup the infrastructure for the metadata server. More details to come later.
I gave fastestmirror some love recently and added support for a 'maxhostfileage' option, which lets you specify how many days before it should update the cached mirror speeds file again.
As the GeoIP package was working it's way through the Fedora Extras review process, Warren noticed that this package could be used to do aid in smarter mirror selection. So once the python bindings hit extras, I'm going to start to play around with fastestmirror + GeoIP integration. Once I get some free time I will probably also look into adding multiple mirror-selection algorithms into fastestmirror: GeoIP, bestmirror (repomd.xml validation), and the original socket-fu technique.
I finally found a home for fastestmirror, in the yum-utils cvs repo. So if you are interested in playing around with the latest version, look no further:http://devel.linux.duke.edu/cgi-bin/viewcvs.cgi/*checkout*/yum-utils/plugins/fastestmirror/fastestmirror.py?content-type=text%2Fplain