Maintaing an aptable archive with a potato - woody mixture
Hi,
the company I work for relies heavily on Debian for our own servers
and the systems we sell. We run potato with assorted woody packages
compiled under potato in cases we _need_ later software than the
potato-packaged versions. We also want to use apt-get for software
installations on all our machines. We have a local Debian mirror for
the i386 architecture.
Our setup is not yet in place, so we are still in the design process.
I am currently testing a setup like this:
With our own mirror being at $MIRROR, having of course
$MIRROR/dists/potato and $MIRROR/dists/woody, I have added
$MIRROR/dists/$COMPANY which is mainly a symlink farm to potato. When
we exchange packages for packages made by ourselves, we replace the
symlink to potato with an identically named file containing our
version of the package. With a cron-job, we build our own Packages
files to make the $COMPANY archive aptable. This setup clearly has the
advantage that we have full control about the archive, and the clients
only need a single apt line for our $COMPANY "distribution". But we
need to be concerned about the symlink farm's consistency with the
potato archive which doesn't seem to be a big problem because potato
is fairly static these days. I suspect that we'd need to (manually?
yuck!) work on our symlink farm once 2.2r1 is being released.
Recently, I have been thinking about ditching the symlink farm and
going for a setup that resembles the security.debian.org setup:
Clients have apt-lines for a normal potato mirror (that doesn't even
need to be ours), and an additional apt line for an $COMPANY archive
that only contains packages made by us. Packages from the $COMPANY
archive would override packages from the potato archive because the
$COMPANY apt line is below the potato apt line and apt-get seems to do
a "last match" algorithm with package selections.
On a second and third thought, the second (linkless) approach seems
more
and more appealing to me: There is no need of having a local mirror,
backup is much easier (since a complete mirror won't be backed up
because you can use another mirror as backup and you only need to
locally
back up the $COMPANY directory which only contains $COMPANY-build
packages), and the dpkg-scanpackages process will be a lot faster.
What do you think about the advantages and disadvantages of either
setup? Which way should I go? I must admit to currently being stronly
biased towards the second approach.
Additionally, I am concerned about version numbering, and what to do
when
a new version of the Debian package appears. Currently, we do the
following:
If we didn't change much (for example, only a modified config file
that is only relevant for new installs), our package has the same
version
number like the current Debian package, causing a new Debian release
to
override our package automatically.
If we changed more (for example, fixing bugs that are present in the
Debian package), our package has its debian-revision incremented. This
way, a new debian revision shouldn't override our package, but a new
upstream version will. I am not sure if this is desireable.
We will definetely need an automatic process that will inform us if a
new Debian revision or version of a package that we have our own
version of
is released for manual review and possible rebuild of our version. Is
Package file parsing enough to do this job, or could we possibly use
apt (like debian-cd does) to do that job? We would also have to
monitor debian-security and/or proposed-updates.
Is there any way to keep a new debian/$PACKAGE_foo++.deb from
overriding
$COMPANY/$PACKAGE_foo.deb?
I'd appreciate your comments.
Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Reply to: