Hi, I'd like to start off with the list of deliverables and elaborate on the status of each task then.
* Forking of upstream code, analyzing package to determine core functionality * Identify distribution-specific code and decouple it from update-manager's core * Replace synaptics backend with a python-apt based backend. * Special notification for certain updates * Automatic downloading of updates * Automatic installation of packages * UI redesign ---- Ad points 1 & 2 (Forking, analyzing, decoupling): The first two points formed the base for most of my work. In short I did a major rewrite of update-manager, not only decoupling distribution-functionality from the core, but rather also decoupling the three major parts that make up update-manager: The frontend, the backend and distribution specific functions. Right now these three parts are independent from each other, meaning that for example a single backend can be used by multiple frontends, without the need to adapt anything. This is achieved by inter process communication via handler classes and their methods. In short: backend A and B have the same method "reload_cache"[0][1], that will reload the cache in the backend-specific method and report back to the frontend by calling the methods of an implementation of the CacheProgressHelper[2] class. This type of IPC can be found when any part of update-manager is communicating with another part. Additionally to these three major parts there is an Application[3] class, which glues everything together and is responsible for initialization of the distinct parts and handling communication between those. ---- Point 3 (python-apt backend): As the synaptics backend depended on a Gtk UI I dropped it completely and wrote a python-apt based backend [4]. This is the sole backend implementation right now, and supports checking for updates, downloading and installing them. However, there is one thing that remained on my TODO list: doing distribution updates. In short this means that update-manager will only install updates which do not require installation of new packages or the removal of packages right now. This is a work in progress though. ---- Point 4 (special notifications for security updates): As for the Gtk UI security updates are displayed in a separate category, on top of the list of updates. The functionality that provides a tray icon plus a notification is present in update-notifier. However, I have began re-implementing update-notifier as an update-manager frontend [5]. ---- Points 5 & 6 (Automatic downloading & installing of updates): This functionality is covered by the unattended-upgrades package that is already present in Debian and was not added to update-manager. ---- Point 7 (UI redesign): I did not carry out an UI redesign for update-manager. However, I tried to make some more information available to users (ie. update X depends on Y, or update Y is a dependency of update X) and overhaul some strings. For example, update-manager now displays a summary saying "N updates were installed" after installing, and tells the user if more updates are available, with a note telling them that the user should consider installing those. ---- Things I did, which are not covered by the original task list: update-manager now has a clear coding style and no more mixedCase function names combined with name_with_underscore names. I have created an API documentation for update-manager, documenting every (I hope I didn't miss anything) class, method, function and constant that can be found in the code [6]. Whilst working on the python-apt backend I noticed a few problems. The most notable are passing of more information during fetch operations (current item size, current item uri, etc.) and thread-awareness fixes. The latter were really important, as python would lock up on some operations (fetching, installing) and the UI would not be updated. My python-apt branch can be found at [7]. As mentioned before, I did not only decouple the distribution specific functionality from core functionality, but rather the distinct parts of update-manager from each other. This allows easier adding of for example a QT frontend, should the need arise. ---- Finally I would like to point out that update-manager is now becoming ready for inclusion in Debian sid, and an upload should happen in the near future. I think this email covers pretty much everything I have done in the past few months, but if anything remains unclear, please let me know. Regards, Stephan [0] http://update-manager.alioth.debian.org/doc/current/api/UpdateManager/Backend/index.html#UpdateManager.Backend.BackendBase.reload_cache [1] http://update-manager.alioth.debian.org/doc/current/api/UpdateManager/Backend/PythonApt.html#UpdateManager.Backend.PythonApt.PythonAptBackend.reload_cache [2] http://update-manager.alioth.debian.org/doc/current/api/UpdateManager/Backend/index.html#UpdateManager.Backend.CacheProgressHandler [3] http://update-manager.alioth.debian.org/doc/current/api/UpdateManager/Application.html#UpdateManager.Application.Application [4] http://update-manager.alioth.debian.org/doc/current/api/UpdateManager/Backend/PythonApt.html [5] http://bzr.debian.org/loggerhead/update-manager/devel/update-notifier-frontend/changes [6] http://update-manager.alioth.debian.org/doc/current/ [7] http://bzr.debian.org/loggerhead/users/speijnik-guest/python-apt/gsoc09/changes? _______________________________________________ Soc-coordination mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/soc-coordination
