[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Google Summer of Code 2010



As you may or may not be aware, Emdebian put forward a project for the
Google Summer of Code 2010:
http://wiki.debian.org/SummerOfCode2010

Our accepted proposal:
http://wiki.debian.org/SummerOfCode2010/Package_Repository_Analysis_and_Migration_Automation

The GSoC page for our proposal:
http://socghop.appspot.com/gsoc/student_proposal/comment/google/gsoc2010/rodonell/t127070533000

I'm mentor for the project and my student is Ricardo O'Donell.

Most discussion of the project will happen by direct email but there
will be occasional mention of it here for the duration of the summer
and Ricardo may well pop up on #emdebian and on this list with
questions and ideas.

This is a very important part of future Emdebian work because it
involves key stages of managing the Emdebian distributions:

1. Removing packages from Emdebian when removed from the same suite in
Debian. This reduces the number of broken packages and missing
dependencies.

2. Adding packages that are new in Debian and which are dependencies of
packages already in Emdebian. This is the flip side of 1: because old
packages usually need removal because the package has gone through a
SONAME transition - removing libfoo0 without adding libfoo1 isn't
helpful.

3. Speeding up the transition calculations on the server - this will
improve all parts of Emdebian, providing a more responsive server,
complete transitions and a more stable "testing" distribution for all
flavours of Emdebian. That is the ultimate goal of the new code.

The issues and problems within this project are not particularly
"embedded" in nature, it's much more a Debian thing and a mathematical
problem of designing a new, faster, algorithm based almost exclusively
on the data in the relevant Packages files. However, it is also a
uniquely Emdebian problem because it focuses on our need to "filter"
Debian and then manage the resulting dependency problems
*automatically*. We all acknowledge that Emdebian doesn't want to have
to package the entirety of Debian just to create Emdebian Grip, Crush
or Baked, therefore some form of filter management is essential, just
to cope with all the SONAME transitions in Debian if nothing else.

The potential benefits to Emdebian are immense and this sort of
dependency-resolution/migration automation is going to be essential if
Emdebian is ever to properly cope with a distribution based on uClibc
packages.

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/

Attachment: pgp2heJoLlKCL.pgp
Description: PGP signature


Reply to: