Re: blends and Google Summer of Code?
Hi
On Tue, Mar 12, 2013 at 08:39:56AM -0400, Yaroslav Halchenko wrote:
>
> On Tue, 12 Mar 2013, Andreas Tille wrote:
> > > +10 on this one
>
> > I'd be happy mentoring such a project and I have soeveral other Blends
> > related things on my todo list (including changing the way the web
> > sentinel is created to serve projects like NeuroDebian well). I somehow
> > need to think about a proper wording for a GSoC project - in recent
> > years my wordings failed to attract any student (which seems to be
> > related to the problem that the Blends concept did not yet penetrated
> > the user / developer base of Debian well enough).
>
> Just throw your perspective text against the mailing list, we will
> be here to help refine it (after this Fri ;) )
... so it is "after this Fri" (== last Fri ;-))
Note: I would like to offer two different project descriptions. This
one is about metapackages creation stuff. I will prepare another text
about the web sentinel. Feel free to comment / change / whatever any
part of this proposal. If you think it is more simple to edit in the
Wiki I could move it there as well. Or you can simply throw it into
the Wiki together with your changes.
-------------------------------------------------------------------------
In Debian Blends a basic way to install packages belonging to a certain
user task is a set of so called metapackages. These metapackages are
created by using so called tasks files as data input specifying
dependencies from binary packages. The package blends-dev contains
tools to create a Debian source package which has set all dependencies
according to the specification inside the tasks file which are validated
against the packages inside the package pool. This ensures that the
resulting metapackages will install nicely into a system that is up to
date at the time of creation of this source package.
Currently blends-dev is verifying the package pool of the architecture
on that the source package is created (when blends-dev is called). In
practice this has the effect that the most popular architectures (i386,
amd64) are used as reference for metapackages which are intended to work
on all available Debian architectures. Strictly speaking this is wrong
even if there is no known case were this has leaded to practical
problem.
An additional source of information to create metapackages could be to
use the information of DebTags (which are also available in UDD).
Currently the maintenance of DebTags and tasks files is independent from
each other but this does not necessarily need be the case. There could
be ways to either synchronise the information or at least regard both
sources of information into account when creating metapackages.
The task of the GSoC project is to rewrite the blends-dev code to enable
architecture dependent metapackages.
Hints for solving this task: It seems to be the best way to use the
Ultimate Debian Database (UDD) to obtain the relevant information. The
UDD is a commonly used resource in Blends (see other GSoC project) and
provides a very handy access to the necessary information about binary
packages. Because the implementation is very different than the current
code the task is basically programming from scratch and thus the
prefered programming language for this task would be Python (the current
code is in Perl).
Required knowledge:
- SQL
- Python
Chance to enhance skills:
- learn structure of UDD
- learn structure of debian/control files
- become comfortable with the idea of Debian Blends
----------------------------------------------------------------------
Any hint is welcome, the other project suggestion will be posted soon.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: