[OpenAFS] Trouble compiling 1.4rc4 SRPM

[Christopher Allen Wing]

Derek:

>> Hmm. I ended up rebuilding all the RPMs from the openafs site in the past 
>> year because there were no x86_64 packages.
>
> That's because I have no x86_64 hardware, and vmware doesn't emulate x86_64.

We need to start a collection and get you some money and/or x86_64 
hardware. Seriously, you are suffering :)

>> If people already are running kaserver and are going to convert to krb5, 
>> they will probably need the whole kit. I figured I might as well provide 
>> it, but in a separate package. Otherwise people will just have to build it 
>> anyway, and they won't have the openafs source tree available like we do 
>> when the RPM is being built.
>
> True..  I just didn't want to go through the hastle of getting afs2k5db to
> build.  i don't recall why I didn't build/ship fakeka.

I think it's worthwhile to provide it, although if we actually wanted to 
make like easier for people converting from kaserver to krb5, we should 
also write some new documentation.

When I packaged it, I used the same kerberos stuff that comes with RHEL 4 
so that everything matched up.

>> But since you make the kernel packages their own RPMs it looks fairly easy 
>> to handle.
>
> Yep.  That was a design goal of the 1.4 RPM.  This way you can actually 
> *JUST*
> build a kernel module via rpmbuild.  Just supply a target and it'll build a
> kernel module for the running kernel (at least on x86).  It makes it VERY 
> easy
> to build a new kernel module without having to rebuild all of AFS.

Yes.

The main reason why I didn't like this in the past, was that Red Hat used 
to ship multiple kernel packages that had conflicting files:

 	kernel-.i386 kernel-.i586 kernel-.i686

all installed into the same /lib/modules/version directory.

I like to keep the package load on all machines the same where possible. 
The old scheme was a pain in the ass, because you couldn't install all 
possible AFS modules on a single machine in the actual kernel paths, etc.

Now that Red Hat has wisely decided to simplify and only support one 
'arch' for its kernel RPMs, this isn't an issue.


> I've pondered which to do..  The "2b always" can potentially be an issue.  I
> figure that this is something I can change for, say, 1.4.1.

Hmm. I guess I'd suggest packaging the OpenAFS aklog since it's more up to 
date.

It would be nice if aklog could figure out whether or not a server 
supports 2b somehow...


>> I'm also guessing that the -authlibs package in your RPMs will not install 
>> properly, due to the ABI naming problem with the shared libraries on Linux. 
>> I included Russ's patch to fix this:
>>
>> 	http://rt.central.org/rt/Ticket/Display.html?id=18767
>
> Yes, I know about this bug..  And it's been mentioned on the list..  I 
> actually
> only include these packages because you did.  I could just remove them
> totally...  My preference is that this patch get included in the main distro. 
> If the gatekeepers are not willing to apply this patch then they must have
> their reasons.  (Or they're being lazy, but I'd prefer to believe they have
> reasons).

I guess they are afraid of the people who have already built software 
linked against the libraries with inconsistent SONAME?

>> In my opinion I think this patch either has to be applied, or the shared 
>> libraries should not be packaged in the RPM. Otherwise they get built with 
>> inconsistent naming compared to all the other libraries on a redhat system.
>
> Fair enough.  I'm willing to remove the authlibs packages from the RPMs.

I'd go ahead and do that (remove the shlibs entirely) if you're 
uncomfortable with adding the patch. Since you will be effectively 
defining OpenAFS on redhat, though, you could probably defend throwing the 
patch in since anyone who builds against OpenAFS on redhat would use your 
stuff.

The shared library interface for OpenAFS doesn't seem to be too well 
specified anyway, and as I noted in my spec file comments, it isn't used 
by anything inside OpenAFS.

I think the preferred way to do most things you'd need those libraries for 
is GSSAPI and PAM. (granted, the necessary pieces for _that_ to work have 
only come together very recently, but it does work)

(non-multiprocess server access to AFS is the only thing I can think of 
that would need to set tokens in a hurry)


>> I'll try to take a look at your packages when I have time this weekend or 
>> next week. Unfortunately we just deployed 700 machines with 1.4.0-rc1 and 
>> my RPMs, so I won't get an opportunity to upgrade them for a while.
>
> Thanks.  Any patches would be appreciated.  The one outstanding issue I have
> right now is that even though the module is named openafs.ko, lsmod reports 
> it
> as libafs.   So even tho "modprobe openafs" works, "modprobe -r openafs" does
> not.  This means the openafs-client initscript doesn't completely stop the
> client -- or at least it doesn't properly remove the module.
>
> If anyone has any hints about why this occurs, or how to rename the module, 
> I'd
> appreciate the hints!

I think it's getting set by the kbuild makefile magic in linux-2.6.

e.g., when the module gets built in:

 	src/libafs/MODLOAD-x.y.z

the script 'make_kbuild_makefile.pl' generates a kbuild makefile:

 	src/libafs/MODLOAD-x.y.z/Makefile

which contains the line:

 	obj-m := libafs.o


and then the kbuild stuff magically parses this and knows that the module 
is called 'libafs'.

I think the script in question that handles this is:

 	/path/to/kernel/source/scripts/Makefile.modpost

I'm guessing that if you change the AFS scripts and makefiles to generate 
openafs.o instead of libafs.o, it will do what you want. Otherwise, maybe 
find a way to specify KBUILD_MODNAME to the kernel makefiles/scripts?

> PS: Thanks for your original work!  It was very useful.  Between you and 
> David
> Howells I used a lot of ideas for the updated packaging system.

no problem. We needed to deploy RHEL4 by the fall, so we needed to build 
openafs 1.3.x.

I'm looking forward to bumming off your work again in the future... :)


-Chris
wingc@engin.umich.edu