[Soc-coordination] Google Summer of Code 2009: Debian's Shortlist

[Colin Watson]

On Sun, Apr 12, 2009 at 07:28:14PM +0200, Guillem Jover wrote:
> On Fri, 2009-04-10 at 09:18:32 +0200, Obey Arthur Liu wrote:
> > === And the details: ===
> > ========================
> > 
> > * Control Files Parsing/Editing Library/Qt4-Debconf Qt4-Perl bindings *
> > -----------------------------------------------------------------------
> > Student: Jonathan Yu, Mentor: (probably) Dominique Dumont *see below*
> > 
> > This project proposes a common library for parsing and manipulating
> > Debian Control files, including control, copyright and changelog. Main
> > ideas include validating and parsing of these files, with both Strict
> > and Quirks modes for the parser. The second idea is a new frontend for
> > Debconf using Qt4 (for which Perl bindings will be written).
> 
> I've some comments after checking the more detailed project proposal at:
> <http://wiki.debian.org/jawnsy/Debian_Control_Files_Parsing_and_Editing_Library>
> 
> There's already several libraries to parse debian control and
> changelog files, but I don't think there's anything for copyright as the
> format is not yet standardized.
> 
> dpkg has a C library (albeit not yet public) for parsing and dumping
> control-style files, and dpkg-dev has also perl modules supporting
> control and changelog files.

As a general system-design style point, dpkg is the logical place for
this and there are a number of reasons not to create yet another library
elsewhere, particularly if it's going to be done in C. Getting dpkg's
library for control parsing up to the point where it has a stable,
advertised API would be very good for Debian, IMO.

> There's also mention of rewritting debconf in C/C++, but that has also
> already been done in the form of cdebconf.

We will probably be moving to cdebconf eventually, but not within the
lifetime of this GSoC project as there are still a number of things left
to be added before it can be a full replacement. A second C rewrite
would very likely do more harm than good (due to fracturing development
effort). It wouldn't hurt to add a Qt4 frontend to cdebconf, and there
would be some future value in that; but the only immediate use for that
would be to produce a Qt-based graphical installer, which I doubt the
installer team has time to maintain as we already have enough to do with
one graphical frontend.

Right now, fixing the Perl Qt4 bindings and updating the existing
debconf "KDE" frontend (it really just uses Qt, but such is its
historical name) seems to be the preferable approach by a long way.

-- 
Colin Watson                                       [cjwatson at debian.org]