update-manager weekly update #0
It has been more than a month since I last wrote about my work on update-manager during this year's Google Summer Of Code and I am somewhat ashamed I wasn't able to provide you with updates more regularly.
So first of all, yes, I did do some work and yes, there has been quite some progress. Basically both private and university stuff have kept me from writing and that's why I'd like to start with this series of weekly updates today.
This series are meant to summarize what has happened during a week of writing code and give you an overview of what's happening. This first issue however will sum up the past month.
So let me begin explaining what has happened since my last post.
update-manager bazaar repository
All code I have written so far is available through a public bazaar branch on launchpad.net. My branch's page can be found here and provides you with its history and of course instructions on how to obtain the code. The location is only temporary though, as I am going to move hosting over to alioth.debian.org. This is on my task list for next week.
modular design
I have ripped apart nearly all of update-manager and put it together in a more modular way, which should implementing new frontends or backends more easy, whilst also simplifying code maintenance.
The new design consists of four major parts:
- The application class is responsible for parsing command line arguments, initializing all other components correctly and coordinate communication between the frontend and the backend.
- The backend itself is defined through the UpdateManager.Backend.BackendBase class and each implementation subclasses BackendBase. It is responsible for interacting with apt.
- The frontend is again defined through a base class, UpdateManager.Frontend.FrontendBase. This part of update-manager provides the userinterface, handles user input and starts operations accordingly.
- Lastly there is the distribution-specific part, which lives inside the UpdateManager.DistSpecific Python module and is defined by its own base class, DistBase.
backend implementation
When I started working on update-manager it heavily relied on synaptic and used it to do the dirty-work. However, together with my mentor, mvo, I decided to drop synaptic support and rather concentrate on using python-apt. This means that the only backend implementation right now is a python-apt backend.
The python-apt backend is currently a work in progress, but already includes some basic functionality. Right now it can (re-)load the package cache and package lists and is able to provide a list of packages which are upgradable to the frontend.
Whilst implementing these functions I noticed some shortcomings of python-apt itself, fixed those and got mvo included in his python-apt branch at launchpad.
frontend implementation
I started re-implementing the Gtk frontend as provided through current update-manager and right now it visualizes the package cache reloading process and provides users with a list of upgradable packages. However, that's pretty much all of the functionality it includes right now, which is why implementing more functions is pretty much on the top of my todo list.
Additionally I have ported the text frontend, as included in Ubuntu, to the new modular system, and this frontend's code really shows how easy adding a frontend with the new modular design is. This frontend contains the same functionality as the Gtk frontend.
distribution specific code
The core described above does not include any distribution specific code anymore, which is the main focus of this project. The implementations of distribution-specific functionality contains classifiers for update categories for both Debian and Ubuntu, whilst I focused on getting things right with the Debian implementation for now. These classifiers allow the frontend to let the user know which kind of update they are about to install, like a security update, a recommended upgrade or a third-party (unofficial) upgrade.
documentation
As update-manager was poorly (read: hardly at all) documented I started documenting the API using sphinx. However, right now the generated documentation cannot be found anywhere yet. This should change as soon as an alioth project for update-manager has been created.
next week's tasks
I would also like to provide you with my task list for the coming week. The list, ordered by priority, is:
- Register an alioth project and move the bazaar branch to bzr.debian.org
- Generate an HTML version of the API documentation and put it on alioth.
- Implement changelog-fetching for the Debian-specific module and make use of that from within the code and the Gtk frontend.
As you can see this list is rather short. This can mainly be attributed to a few university assignments, and instead of providing a long list of tasks which I probably won't be able to finish I rather keep the list short and hopefully get things not on this list done too.