Blog de Cristian Porras

This year I will be participating in Google Summer of Code! My work proposal “Aptitude Package Management History Tracking” has been selected. So I will be working for Debian and my mentor will be Daniel Burrows. To give you an idea of what I will doing this summer I leave you with my proposal (without some details that are beside the point ).

Project title: Aptitude Package Management History Tracking

Synopsis: Aptitude currently does not track actions that the user has performed beyond a single session of the program. One of the most frequent requests from users is to find out when they made a change to a package, or why a package was changed; we want to store this information and expose it in the UI in convenient locations. As a side effect, this might also provide some ability to revert past changes.

Benefits to Debian: The change history of the packages on a system has become a recurrent need for many systems administrators, who see an opportunity in this possibility to manage more efficiently the resources on their machines. The impact would be positive in many users who use Aptitude interface for APT, not only on the command line application, but also on Aptitude-GTK.

Deliverables: The module which is intended to be designed for Summer of Code 2009, will be composed of two major parts: Add the functionality for Undo – Redo changes in Aptitude (undo really exists, but is replaced with a version that uses the history) and explore the history of a particular package, in each case made the appropriate changes to the UI, to give greater facilities to users.

Project details: The main idea is to make Aptitude store and record the history of actions that an user has done on each package. By having this information and can access it in an orderly manner can be completed easily reach other goals, such as:

* Provide an easy way to find out how and why a package was installed or uninstalled on the system, changes can be made by hand, by dependency, suggested packages, conflicts between packages, etc.

* Give the possibility to undo a lot of changes in a single action, taking into account the limits of the APT system.

* Provide a mechanism for system administrators to audit the history of a package and add notes to it.

* This history should also preserve the information generated in su-to-root operations

* Also thanks to this should be easy to implement ‘redo’, something aptitude has always lacked.

The difficulty in conducting this project is not the collection of data, but it’s to define the proper way in which to store the information in the way that it can be efficient and not to overload Aptitude. It seems the best approach that can be given to this problem is that proposed by Daniel Burrows (See his ideas in [1]), in which it would have a set of text logs and a database binary simultaneously, that for readability by the user in text files and increase the efficiency of Aptitude reaching the database directly. If the database were to fail, Aptitude could scan the log to recreate the database, which also makes it necessary to write code to do the text log – database processing

Since the project can range from different points of view is necessary to discuss and define several issues with the Aptitude developers and some experienced users of Debian, for example:

* What to do with past actions of an “Undo”, delete them or preserve them.

* Whether to include also details on the history of resolver interactions.

* Define whether the record should be updated immediately changes are made or be expected to finish the session to record the actions taken.

* Establishing rules and / or tools to remove old entries in the log. For example, with the rules I am talking about erasing the old posts in the database beyond a certain age. The tools can be commands whose purpose is to delete manually the history, aptitude “remove history” to say something.

I hope this items can be defined on the first month of the GSoC to work on a fixed path to follow and not suffer setbacks, yet it would be open space for made minor changes on the fly.

As already mentioned  above, the first priority is to define the structure of the database, this with the help of the SQLite library, at the end of this (the more creative phase) I begin to define a series of classes and routines necessary in principle to update the records of this database, this section should define a common set of calls that would serve both for the command line application and the cwidget-ncurses and GTK interfaces, since these classes would be accessed by aptitude when it receives the outputs the processes of APT (Maybe based on pkgstates).

As second and third period, classes should be created for the operations “undo/redo”, and for the queries for the database which will be used to display information in an orderly manner in the UI. As the ncurses and GTK interfaces are very similar in concepts (signals and slot object-oriented C++), which happens once we have the code for ncurses is that is relatively easy and quick also have support for GTK (or vice versa). The code for the command line application would be a little different but easy to implement once we have defined the needed queries. Here we must bear in mind that would work with separate packages, Aptitude and Aptitude-gtk, which required a good time for the test period.

The final set of code. Will be for fix fails in the database, generating the transformation between the text log and the binary data base. In addition to providing tools for maintenance work, which would be the least complicated part of the project, things made by the style of  “delete from history where date < $somedate”.

Project schedule:

The preliminary timeline for the project, according to the schedule of GSoC:

April 20, Accepted student proposals announced

Week 1, 2 and 3:

Project initialization

Analysis of existing data model for the history entries, getting to know the coding style and documentation writing concepts. Improving communication skills and understanding the Community, discuss any outstanding issues that are mentioned in the Project details.
Install and configure the necessary software to implement the project on my computer.

Week 4: Improving the sketch of the data model, considering the corrections arising in the analysis of the past three weeks.

May 23, Students begin coding for their GSoC projects

Week 5: Implement the data model.

Week 6: Write code to convert the history entries to and from text and write unit tests for this code.

Week 7: Write code to compute the history list for the current session and store it in a member of aptitude’s cache wrapper.

Week 8~9: Write code to implement undo/redo on top of the history list and replace the current undo code for packages with the new undo/redo code.

Week ~9-10: Testing and correction of bugs discovered so far.

July 13, Mid-term evaluations deadline

Week 11: Write code to add the live history list to a sqlite cache database, and code to retrieve history from the database.

Week 12-13: Write a GUI viewer for the history list, and code to show the history of a particular package.

Week 14: Write code to generate log files in /var/log with history information.

Week 15: Write code that, if the cache database is missing, reads those log files to rebuild it.

August 10, ‘Pencils down’ date

Week 16: Extensive test case analysis whit Bug Fix.

Week 17: Final documentation improvements and some improvements in the code.

August 24: Final evaluation deadline

Project completed.

Note: The documentation is generated simultaneously with the code throughout the summer, making the necessary improvements to the final dates.

[1] http://lists.alioth.debian.org/pipermail/aptitude-devel/2008-December/001071.html