linda is gone.
converted to 1.6 markup
|Deletions are marked like this.||Additions are marked like this.|
|Line 3:||Line 3:|
|* [http://svn.debian.org/wsvn/collab-maint/lib/trunk/ web interface]||* [[http://svn.debian.org/wsvn/collab-maint/lib/trunk/|web interface]]|
We're trying to design something for CollaborativeMaintenance. Check the actual source code in the repository :
- Anonymous checkout: svn co svn://svn.debian.org/collab-maint/lib/trunk collab-maint
svn co svn+ssh://svn.debian.org/svn/collab-maint/lib/trunk collab-maint
- 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
- 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.