[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
 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

Trouble with the solutions:
dak - I dont really know. I hav enot tested it, caus I failed to find
       any easy to read doc.
  - 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).

[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: