[Soc-coordination] update-manager progress report - week 11 (was: Re: Progress reports for week 12 is today)

[Stephan Peijnik]

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?