Move existing project definitions from projects/gsoc_2011/ to
projects/project/ .
The goal for this reorganization is to remove any knowledge of the projects
classification from the file hierarchy: the classification goes into tags,
and projects indexes automatically list projects based on such tags.
Also, the current gsoc_2011 name was wrong anyway, because GSoC 2011 has
already concluded and projects would have had to move to a gsoc_2012 directory
anyway.
Lastly, yes, "projects/project/*" is slightly redundant. But I want to keep
the project lists from the projects "database" clearly separated.
This is as proposed in www@.

[[!template id=project
title="Rewrite pkg_comp with portability as a major goal"
contact="""
[tech-pkg](mailto:tech-pkg@NetBSD.org)
"""
mentors="""
[Julio Merino](mailto:jmmv@NetBSD.org), [Aleksej Saushev](mailto:asau@NetBSD.org)
"""
duration="3 months"
description="""
pkg_comp is a shell script that allows building packages inside a sandbox in an automated manner. The goal is to allow the user to build packages in a controller manner and to provide a simple mechanism to build packages for a host running a specific NetBSD release (e.g building packages for NetBSD 5.x while running NetBSD-current).
The [current version](http://www.netbsd.org/contrib/soc-projects.html) of pkg_comp is written as a pretty big shell script that has grown out of control. It is hard to maintain and hard to extend. And, more importantly, it is not portable at all.
The goal of this project is to rewrite pkg_comp from scratch with portability being the main goal: it has to be possible to use the script in different Unix variants (including Mac OS X).
The language of choice for the reimplementation will be Python. The code will be hosted outside of pkgsrc to be able to distribute it as a standalone tool.
The following items should be accomplished:
* Implement a "sandbox" library with an interface to programmatically create and manage a sandboxed file system. The structure of the sandbox has to be configurable through a template, and templates have to be provided for a few systems. The sandbox itself will be constructed either by unpacking tarballs with the system contents (such as the NetBSD distfiles), by null-mounting directories of the host file system, or both.
* Implement a command-line frontend utility for the "sandbox" library. This tool is completely unaware of pkgsrc but will be really nice to have (and trivial to write, as all the juicy bits are in the library). Will be useful as part of server administration, as it will allow isolating services in a fairly easy manner.
* Implement the "pkg_comp" application, building it on top of the "sandbox" module. It has to provide most of the current functionality, if not all. More specifically, these are a must: unattended builds of a predefined set of packages and use of libkver to override the system version.
* Implement detailed unit tests for the modules and integration tests for the front-end tools. At this point, the former will most likely be implemented using JUnit and the latter will be implemented using ATF.
As part of this project, the student will get familiar with pkgsrc, construction of sandboxes for different operating systems, unit testing, ATF and Python.
"""
]]
[[!tag gsoc]]
[[!tag medium]]
[[!tag pkgsrc]]