Our repository, and the progress of a sarge-based debian-edu
I guess we all agree that we need some new ways of managing our
repository. There are different reasons that we might want a new method
of handling our repository:
- To clean the repository up
- To enable autobuilding
- (There was more, but I've forgot them)
There are several ways to manage our repository
- using our manual methods (but we want a better way ...)
- dak "Debian's archive maintenance scripts"
- reprepro "debian package repository producer"
- maybe others ?
There has been a few volunteers to set up dak on developer, and I've
started to use reprepro on my own repository, and have kind of
volunteered to set up reprepro on developer.
Why do I use reprepro, and not dak ?
Well, pere mentioned dak at some point, and I tried to find out what he
was talking about. I found that it was a debian-package, and I found the
description of the package, but that was it.
For Reprepro, I found a small how-to on the home-page[1], and there is
also a tutorial on debian-administration[2].
And there is the package descriptions:
DAK - Debian's archive maintenance scripts
This is a collection of archive maintenance scripts used by the Debian
project.
You don't want to use this if you only have a few hundred packages to
maintain. Look at mini-dinstall or debarchiver or maybe even
apt-ftparchive for this.
reprepro - debian package repository producer
reprepro is a tool to manage a repository of Debian packages (.deb,
.udeb, .dsc, ...). It stores files either beeing injected manually or
downloaded from some other repository (partically) mirrored into a
pool/ hierarchy. Managed packages and files are stored in a libdb3
database, so no database server is needed. Checking signatures of
mirrored repositories and creating signatures of the generated Package
indices is supported.
Well, we have just a few packages that we (re)package. And from the
package description I would choose reprepro. Even if there are people
whoare willing to set up dak, I think the missing documentation is a
blocker. We have experienced that even if we get help to set something
up, people tend to drift away after they've set things up. Having good
documentation is nice.
But first, maybe we should decide what we want from a new archive
handling system.
My wishes, prioritized:
- Tool to help keep a repository clean.
We now have a bunch of unused packages in our repository that are
outdated and replaced
- Tool to mirror upstream debian
We do a full mirror of i386 from ftp.debian.org (I think) There is no
need to mirror anything else than sarge and maybe woody, the
increasing load of the etch packages causes our builds to be unstable.
- To me autobuilding is of lesser priority, but yes, maybe in the
future.
Trouble with the solutions:
dak - I dont really know. I hav enot tested it, caus I failed to find
any easy to read doc.
reprepro
- it basically just a tool to build the repository, not a tool do the
autobuilding and stuff.
- Doesn't handle .orig.tar.gz, we have to create a script to handle
that ourself
Both dak and reprepro is availibe in sarge, we have woody on developer.
I've previously made backport of reprepro, I have not tested with DAK.
So should we use reprepro or dak, or something else.
Should we use maintainer.s.n, or should we use backports on developer
I'll vote for reprepro, and maybe use maintainer to do the job (I'm
using a celeron466MHz, with 368MB memory).
links:
[1] http://mirrorer.alioth.debian.org/
[2] http://www.debian-administration.org/articles/286
--
Finn-Arne Johansen
faj@bzz.no http://bzz.no/
Leverandør av support på, drift og videreutvikling av Skolelinux-løsninger
Reply to: