[Soc-coordination] Britney improvements: report for July 22, 2006

Fabio Tranchitella kobold at debian.org
Sat Jul 22 19:40:32 UTC 2006


This is the second report for the "Britney improvements" project, which
is part of Google Summer of Code.

= Current Status =

Britney code-base has been rewritten in python, and the output of the
old and new version are quite identical. The code is hosted within the
subversion repository of the soc-coordination alioth project [1]. There
are small portions of the code which haven't been yet completed, but the
task is quite easy and I think it is better to focus on important
improvements now and leave them for later.

The excuses generated are exactly the same, while the update.OUTPUT_py
file has some differences. I'm not sure if these small issues are real
bugs of the new code or the old one, but the final result is the same so
I'll check them later.

The main problem of the current code is that it is slower than the old
one: without considering the data load (which now is handled by python
and not by a C module, so it is **really** slower), the time needed to
complete the first loop is about 2 minutes and 30 seconds. Britney
required a bit less then 2 minutes for the same task. One of the biggest
bottlenecks is the conflicts handling, which is really computing
expensive, so a better agorithm for it could speed up the new code.

= Next task =

The next days will be used to run the new and the old britney togheter
on a variety of inputs, to check if there is any regression or
not-handled case. After I'll be confident with the code, I'll start
implementing new features (eg. udeb support and new dependency
algorithms) as well as improving the performance for the critical parts
of the code.

= Request for feedback =

While working on britney, I have been busy reimplementing dpkg behaviour
in python (since apt_pkg doesn't seem to provide such an interface
without using the apt cache of the system, for example using normal
lists and dictionaries). 

One of the ideas I had was to resolve the testing update using apt_pkg
to "simulate" a dist-upgrade from testing to the valid candidates of
unstable (as resulting from the update excuses), then checking how dpkg
resolves the problem. I don't know if this is possible at all, but this
would really simplify the code leaving apt and pkg do the task.

I've done some tests with apt_pkg using a crafted apt.ini pointing to
ad-hoc sources.list and Packages.gz files. I haven't found how to run
the upgrade and how to track the changes, but I think that this could be
an interesting way to solve the problem.

I'm really interested in receiving feedback about this idea.

= References =

[1] svn://svn.debian.org/soc/britney/trunk

-- 
Fabio Tranchitella <kobold at debian.org>                        .''`.
Proud Debian GNU/Linux developer, admin and user.            : :'  :
                                                             `. `'`
   http://people.debian.org/~kobold/                           `-
_____________________________________________________________________
1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Questa =?ISO-8859-1?Q?=E8?= una parte del messaggio
	firmata digitalmente
Url : http://lists.alioth.debian.org/pipermail/soc-coordination/attachments/20060722/af6b39b7/attachment.pgp


More information about the Soc-coordination mailing list