Well, it *can* be built without kernel headers, so if the kernel module were ever to be packaged as a binary or included in the kernel it might make sense to still have kernapps around. Otherwise I agree about kernapps, although it may be worth keeping around for development purposes. Is there some issue with debian packaging that makes that target a problem?
Well kinda with debian unstable they use an app called module-assistant to build external module packages for various external kernel module packages (redhats gfs, ipw3945, fuse) and putting the build for both the kernapps and the module into that package (because theoretically you should be able to just point module-assistant at any kernel even one you build) is not quite the way debian works, ideally the packages would be split. However, since both the client and the kernel module kinda need to both change depending on the kernel version used. It presents a problem for fitting pvfs2 into debian. For something like fuse they guarantee backwards compatibility between their kernel module and userspace libraries, so you can update the userspace libraries without rebooting or rmmoding to change out fuse module. However, if pvfs actually changes the size of particular structures across the device depending on what the configure checks result in then putting both the kernapps and the module into one package is going to have to be the way it works. Thanks, - David Brown _______________________________________________ Pvfs2-developers mailing list [email protected] http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
