[242] in athena10
OpenAFS modules metapackages
daemon@ATHENA.MIT.EDU (ghudson@MIT.EDU)
Fri Jun 13 15:30:55 2008
Date: Fri, 13 Jun 2008 15:30:09 -0400 (EDT)
From: ghudson@MIT.EDU
Message-Id: <200806131930.m5DJU9CX019348@outgoing.mit.edu>
To: athena10@mit.edu
Background: Debathena has a well-known problem where people update
their kernels and have no AFS until (1) we build new OpenAFS modules,
and (2) they manually "aptitude install openafs-modules-`uname -r`".
Anders had an idea for improving this situation by creating a
metapackage named openafs-modules-generic which depends on
openafs-modules-<version>-generic and linux-image-generic (=
<version>). With this metapackage installed, kernel upgrades would be
blocked until our metapackage is updated.
I've begun implementing this proposal by creating a script
debathena/third/openafs/meta/update-metapackage. It looks up the
current most recent kernel version, makes sure there is a matching
openafs module, generates an equivs file, builds it, and uploads it.
Here is an example of the equivs file it generates for Hardy:
-----
Section: openafs
Priority: extra
Standards-Version: 3.6.2
Package: openafs-modules-generic
Version: 2.6.24.18.20
Maintainer: Debian-Athena Project <debathena@mit.edu>
Depends: openafs-modules-2.6.24-18-generic, linux-image-generic (= 2.6.24.18.20)
Copyright: ../common/copyright
Readme: ../common/README.in
Description: Metapackage to enforce OpenAFS modules for kernel
This package prevents automatic upgrades of the generic generic until
there is a corresponding openafs-modules Debathena package available.
-----
The script is wrapped in a for loop and could be trivially changed to
generate modules for server and xen as well as generic, but I wasn't
sure if that was a good idea.
I don't think we can depend on this in debathena-clients since that
would be forcing all debathena-clients machines to use the -generic
kernel. The best integration point is perhaps the installer, although
that doesn't help existing machines. Anyway, I'm going to give people
a chance to review this before making further steps.
(Also, I just realized I can simplify the first part of the script's
logic; instead of getting a list of all linux-image-<version>-generic
packages and finding the maximum version, I can look at the
dependencies of the current version of linux-image-generic.)
