[OpenAFS] Trouble compiling 1.4rc4 SRPM

[Derek Atkins]

Quoting Christopher Allen Wing <wingc@engin.umich.edu>:

> I see you are also supporting Linux 2.4. I didn't bother to put in 
> the work since I only cared about deploying RHEL 4.

Yea, I'm trying to support fedora-1,3,4 and RHEL-3,4.

> 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.

> 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.

> Because I'm lazy, I've kind of gotten used to keeping the kernel 
> modules in a separate place and not having to upgrade the openafs 
> stuff every time a new kernel update comes out.
>
> 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.

> I took a quick look at your spec file and it looks like you are 
> packaging the 'aklog' from the afs-krb5 kit instead of the one from 
> OpenAFS. I packaged the one from the OpenAFS source since it supports 
> rxkad2b, and was getting active development.
>
> I would suggest you do the same thing. The only annoying thing about 
> the OpenAFS aklog is that it seems to use 2b always; so if you are 
> running servers that don't support it then it gives you bad tokens 
> unless you explicitly specify -524.

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.

> 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).

> 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'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!

Thanks,

-derek

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.

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available