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

And openafs-modules-dkms should depend on dkms.

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

Sponsored for karmic.

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

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

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

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

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

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

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.

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

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

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

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

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

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.

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

Corresponding Karmic change

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

The Jaunty diff looks reasonable.

Ah, ok then.