openafs-client does not recognize openafs-modules-dkms as satisfying dependency

[psigen]

Impact:
In Jaunty, the openafs-client (1.4.9.dfsg1-0+ubuntu3) package recommends openafs-modules-source or openafs-modules2, but does not refer to the new openafs-modules-dkms.

This causes apt-get to try to install openafs-modules-source with openafs-client, even if openafs-modules-dkms is already installed. As far as I know, openafs-modules-dkms should satisfy all the same dependencies as openafs-modules-source, so the openafs-client package should probably be updated to reflect this.

Patch:
Patches attached for Jaunty & Karmic.

How it's addressed:
The openafs-modules2 option is removed since that package doesn't exist in any supported Ubuntu or Debian release anymore. The openafs-modules-dkms option is added as an "or" with openafs-modules-source but listed first since it's the easier one for setup and thus preferred. Also, since they're all built from the same source package and the openafs-modules-source version requirement was 6 years old, unsupported upstream, and "well, it might work, but that's a bad idea" according to upstream, the version is set to ${source:Version} since matching versions is the recommended situation.

Instructions to reproduce:
Try to install openafs-client and note that it wants to make you use module-assistant manually when it could set everything up automatically with dkms for you.

Regression possibilities:
None

[Robert Gerlach (khnz)]

And openafs-modules-dkms should depend on dkms.

[Anders Kaseorg (andersk)]

openafs-modules-dkms depending dkms is bug 368471, fixed in karmic.

[Maia Everett (linneris)]

Sponsored for karmic.

I think the jaunty version should be +ubuntu3.1, although it might not matter now.

[Launchpad Janitor (janitor)]

This bug was fixed in the package openafs - 1.4.10+dfsg1-1+ubuntu2

---------------
openafs (1.4.10+dfsg1-1+ubuntu2) karmic; urgency=low

  * Update openafs-client recommends so it can use dkms or module-assistant,
    and fix the versions of those required (LP: #369875)

 -- Mackenzie Morgan <email address hidden> Tue, 19 May 2009 21:45:15 -0400

[Mackenzie Morgan (maco.m)]

Maia:
I asked Rich Johnson, and he said the decimal is only for security updates and regular bugfix updates just use normal versioning.

[Anders Kaseorg (andersk)]

Please don’t fix this in Jaunty without also fixing bug 368471 (for which I already submitted a patch that has a MOTU SRU ack).

[Mackenzie Morgan (maco.m)]

I think Scott Kitterman uploaded that last week (which is why I asked John
Dong to ACK it). Let's see how they want to handle it (one debdiff / two
uploads? what?)

[Anders Kaseorg (andersk)]

Ah, I see, it’s been sitting in the unapproved queue for jaunty-proposed since Friday.
https://launchpad.net/ubuntu/jaunty/+queue?queue_state=1

[Mackenzie Morgan (maco.m)]

Sarah released that other one. She said that 3.2 (since that one was 3.1) or 4 are both OK ubuntu versions since Karmic has 1.4.10 and Jaunty has 1.4.9, but that most people go with Security's way of doing things (so 3.2). Since a context line on that debdiff doesn't match after that upload (oops) and thus won't apply against the now-uploaded one, here's yet-another-correction to the Jaunty debdiff.

[Anders Kaseorg (andersk)]

-Recommends: openafs-modules-source (>= 1.2.9) | openafs-modules2, lsof
+Recommends: openafs-modules-dkms (>= ${source:Version}) | openafs-modules-source (>= ${source:Version}), lsof

Wait, why are you dropping openafs-modules2 as a satisfying dependency? That makes it impossible to get binary OpenAFS modules from a central APT repository (which is what we’re currently doing for Debathena at MIT), and requires that you have a working C compiler in order to use OpenAFS at all.

Please don’t upload this Jaunty patch, as it will break many working systems at MIT.

[Mackenzie Morgan (maco.m)]

openafs-modules2 doesn't exist in any Debian or Ubuntu repositories. How
could it be used to satisfy a dependency?

[Evan Broder (broder)]

Any modules built from openafs-modules-source using the module-assistant provides openafs-modules2.

[Mackenzie Morgan (maco.m)]

Anders:
Are you talking about getting third-party modules from elsewhere and using the
Ubuntu-packaged client with them?

[Matt Zimmerman (mdz)]

openafs-modules2 is the binary package produced by the source bundle in openafs-modules-source, so it should remain an alternative.

mizar:[/tmp] tar xjf /usr/src/openafs.tar.bz2
mizar:[/tmp] egrep 'Package|Provides' modules/openafs/debian/control*
modules/openafs/debian/control.in:Package: openafs-modules-=KVERS
modules/openafs/debian/control.in:Provides: openafs-modules2

[Evan Broder (broder)]

Mackenzie: That's one possibility. Or even if you don't want to use dkms and instead build the modules yourself with module-assistant. Those modules provide openafs-modules2.

The Debathena project at MIT (which Anders and I work on) build AFS modules centrally to save hassle for our users (see http://debathena.mit.edu/apt/pool/openafs/o/openafs/). Those modules are built with module-assistant and provide openafs-modules2, satisfying that dependency.

[Mackenzie Morgan (maco.m)]

OK, edited the Jaunty one to have -dkms | -source | -modules2
That work?

[Mackenzie Morgan (maco.m)]

Corresponding Karmic change

[Anders Kaseorg (andersk)]

Karmic doesn’t need any change; this was already fixed in Karmic by the sync from Debian (bug 382608).

The Jaunty diff looks reasonable.

[Mackenzie Morgan (maco.m)]

Ah, ok then.