Matthew Miller wrote:
I had a look at the rpm available from openafs website. However it seems to be uncompatible with kernel 2.6, so I'd have to package devel version instead, and it would be a lot of work anyway to adapt it to official mdk packaging policy.


Look at my package at <http://www.mattdm.org/misc/openafs/>. I'll be
updating this to work with 2.6.10 later today. You still may have to adapt
it to work with Mandrake, but it should be easier than with the official
one.
Thanks, it was lot easier.

However, my biggest concern is the kernel module. I don't want to build as part of the openafs package, because it is not scalable. Mandrake policy for any kernel module is either to include it in the kernel package, or to make it a dkms package. Basically, a dkms package is just a module source ready to build, that is build at installation time, thus fitting the running kernel on the installation target, and everytime it the target kernel is rebuild also. So I'm actually tring to do it, but I have troubles with openafs build system.

Basically, the 'libafs' target create two target directories (MODLOAD-2.6.10-1mdkcustom-MP and MODLOAD-2.6.10-1mdkcustom-SMP), then chdir there and do the following tasks:
1) link every needed source
2) create dedicated Makefile
3) run it
What I want to do is just tasks 1 and 2, without 3. This way, I could just ship the target directory, with any convenient includes files). But I get lost in multiple inclusions and implicit targets.


Alternatively, I could manually install every file needed in the spec file, but I highly doubt it would be maintaainable in the future.

I also tried the libafs_tree, and found a minor bug: the configure_libafs must be renamed to configure, otherwise the first configure test (ls -t) will fail. Anyway, it doesn't solve my problem, as the configure doesn't generate the final Makefile for creating the module, only a primary Makefile in src/libafs that will create AND execute in the same run final makefile for two hardcoded target modules.

Any help welcome there. BTW, dkms is absolutly not mdk specific, and helps a lot to distribute kernel packages, so I really think this deserve upstream support in build process.
--
All components become obsolete.
-- Murphy's Computer Laws n°8
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Reply via email to