Durk Strooisma <[EMAIL PROTECTED]> writes: > Package: openafs-client > Version: 1.4.7.dfsg1-2 > Severity: normal > > The OpenAFS Client is only started if the Linux openafs module exists. > This check is not strong enough (see below). Besides checking for > existence of the kernel module on file system level, the init.d script > should check whether the module is registered. > > What happens if someone has built the openafs-modules-source, has put > the resulting binary package in a local repository and tries to install > the package together with openafs-client, is that the installation will > fail (apt fails actually). The trouble is that registration of the > openafs module happens after starting the OpenAFS Client.
I agree that this is a problem, but unfortunately there's no good way to fix it without creating other, more serious problems. dpkg and apt don't enforce installation order without Depends, but having openafs-client Depend on the module breaks anyone who builds the module themselves rather than as a package and also makes openafs-client uninstallable until one has built the module (even to look at the documentation which points one at the right package to build the module). Also, at a Policy level, openafs-client can't Depend on the module package since it's not in Debian proper because it's not built automatically. However, one thing that we can do is have the init script exit with a 0 status if run when there's no module available. It still doesn't get OpenAFS started properly in this particular case if the kernel module is installed after openafs-client, but it at least prevents dpkg from failing and makes the end state less confusing. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
