> 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.
I fully agree, the problem shouldn't be fixed with a Depends-construction. > 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. Exactly, just like the current check on file system level. It does an "exit 0" just like you said. There only needs to be an extra check on registration of the openafs module (I guess this info is in modules.dep). If that check fails, the OpenAFS Client shouldn't be started, but the script should exit with 0 as well. > 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. Yep, I agree, openafs-client can't help the module is installed later. Durk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
