Blog de Cristian Porras

In these two weeks, I focus on two points in the timeline:

a) Write code to add the history to a sqlite database, and code to retrieve the history from the database.
b) Show the history of a particular package in the GUI and terminal.

I had thought about doing this after the Mid-term evaluation, but Daniel suggested me to first work on this before implement the new undo and the redo.

For a) I redefined the database draft that had been around for some time to have a database schema like this:

History Entries
/                      \
Dpkg Changes         Aptitude State

In which History Entries is used to store basic information about a change (package name, date, type of change, etc.) and the rest of the details can be subdivided into tables, and depending on the type of change, use some or other tables. Similarly, the retrieve of the history from the database depends on the type of change.

In b) I added command line support, thus having the ability to view history of a package as $ aptitude history [PACKAGE ...].

For the GUI, I have based on the code made to view the files and folders (filesview), and added a subtab in the packet tab.
Following the Filesview scheme, I created the HistoryColumns class to manage columns containing historical information, the HistoryTreeView and HistoryView classes with which were implement to handle the ListStore to view the data.
For now the details shown are few, but I hope to get the proper view of the related changes (deps, suggested, etc). Besides working with the cwidget/ncurses interface in future.

Gtk Viewer

Apart from that, I was in Bogotá a few days doing the paperwork for the visa, I get the answer the next Tuesday .

The outline for the DebConf could be something like this:

Introduction
Deliverable 1: History Explorer/Viewer (What has been done so far and what is missing)
Deliverable 2: Undo – Redo (What has been done so far and what is missing)

I hope we meet in Caceres.

Given this, the students have expressed in various ways against his re-election. Protests which the only way out that saw the direction of the university was the cancellation of the semester, extent to which students lost all the money and time invested. With the cancellation of the semester, 19 students took the main cathedral of the city and began a hunger strike and a large part establishes safeguards against the university for denying the right to education.

Yesterday the Board of Governors of the university decided to reverse the agreement that canceled the semester, but still maintains the Principal in his post, which is no solution to the crisis at the university.

I think I deviate slightly from the topic, I just wanted you to know a little the problems of the university, which is a reflection in small scale of the country, where the dictator of the moment simply to disqualify the opposition branded they as terrorist and sent to silence by force and not arguing as should be.

Since the previous report I had a more fluid communication with Daniel, in large part by the access to the repository. Most of these two weeks I have spent the time polishing the code that I made the first two weeks. Now I get the most information from the changes in dpkg and aptitude states, but recently I have been a problem presented in the order in which these data should be collected when I remove a global variable that was clearly a sign of bad programming, I am focused on circumventing this problem before proceeding. Another important change was the creation of a class to manage the database and the text logs.

For the next weeks I hope to start working on the undo and redo systems.

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