Differences between revisions 3 and 4
Revision 3 as of 2006-02-06 22:01:02
Size: 3610
Editor: ?DanielRuoso
Revision 4 as of 2008-04-06 14:06:37
Size: 3618
Editor: FranklinPiat
Comment: linda is gone.
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
#language en
Line 33: Line 34:
   * followed by lintian/linda    * followed by lintian

We're trying to design something for CollaborativeMaintenance. Check the actual source code in the repository :

Additional requirements

  • While the original proposal speaks only of subversion, we want to be able to support various VCS since people tend to have very strong opinion about the best VCS.
  • The infrastructure can be imagined as a natural extension of "dak" (the tools used by ftpmasters), so we may well inspire our work from dak itself.
    • Thus the suggestion is to write everything in Python.


The infrastructure obviously needs a configuration file in which you give :

  • which respositories (svn/bzr/cvs/...) needs to be considered
  • which APT sources will be used as reference for comparison of the packages
    • need to support several distributions (Ubuntu/Debian/whatever)
    • need to support several sources per distro

Given the amount of data involved, we need a (little) database to keep a cache of the most important information. And the database will probably also store some meta-information about the status of each package (see the kind of meta-information needed on CollaborativeMaintenance).

Many scripts are needed. Server side scripts:

  • update the database with new infos from read-only "PkgRepository" (in particular APT deb-src repositories)

  • incremental update script: update database with new infos from a specific package (useful to launch by trigger on SVN commit for example)
  • a script maintaining an aptable repository with all the latest version of the source packages maintained in the infrastrucure
  • various CGI
  • intelligent hook scripts to send "diff" to the PTS

Client side:

  • Download last source from VCS or APT repositories.
  • Run a complete "test suite":
    • build in pbuiler
    • followed by lintian
    • debdiff against last package in unstable/experimental



PkgRepository is an interface (or an abstract object or whatever) that will be implemented by all modules providing support for a specific kind of "package repository" :

  • subversion repository created by svn-buildpackage
  • bzr/cvs/whatever repository
  • normal APT deb-src repository

It should provide following services :

  • lists the packages available in the repository
    • We suppose/require that each package is available only once in a repository.
  • give properties about each package (wouldn't a Sources file provide that?)

    • current version
    • target distribution (extracted from changelog)
    • URL of original/upstream source tarball
    • some other meta-information (see examples on CollaborativeMaintenance)

  • possibility to generate a "source package" from current version (.dsc, orig.tar.gz, .diff.gz)

If the repository is "writable", it should also provide the following service :

  • possibility to replace the current version of the package with a source package retrieved somewhere else (=> possibility to reinject an external upload)

Each instance of such a module is given a directory that it can use for its purpose.


We obviously will have to download lots of files from Debian/Ubuntu mirrors (Sources packages mainly) and we need a smart cache if we don't want a full mirror copy sitting on the server and if we don't want to download the same files again and again.