[OpenAFS] In the RPM spec file, what is the goal of the special fedora option?
Tue, 12 Feb 2008 20:01:56 -0600
On Feb 12, 2008 4:03 PM, Derrick Brashear <firstname.lastname@example.org> wrote:
> On Feb 12, 2008 4:58 PM, Paul Johnson <email@example.com> wrote:
> > I've been building RPMS for openafs versions for years and have always
> > just used the default approach that creates openafs-kernel rpm.
> > Now I notice in the 1.4.6 spec file an option for fedora, but I can't
> > quite understand what benefit there is in this approach. The only
> > thing I can tell for sure is it builds the kernel module into a
> > package called kmod-openafs. I don't understand what the benefit of
> > that change is.
> > Can you fill me in?
> Other packages for fedora which provide kernel modules do the same
> with same-style dependencies; we provide something analogous to what
> everyone else(*) does.
It is a funny coincidence that, in the rpm-list, I've started an
argument against ATrpms and the requirement of installing customized
macro packages. So I agree with you there.
But I'm still not quite getting the point. Aside from renaming the
kernel module as kmod-openafs, thus allowing yum or some other
dependency resolver to do its business, I can't see what this does.
Can I be more specific?
Is the actual kernel file openafs.ko the same thing in either version?
Is everything else just signals to the rpm database and yum or apt?
I note that kmodtool distributed with openafs-1.4.6 says it is
customized by Simon Wilkinson.
That means I erased the pre-existing version of kmodtool that I had in
my SOURCE tree and I'm a little disappointed there. When I build some
other rpm, it is likely that kmodtool willl get erased again. If
Simon has something vital in there, it might be better to re-name that
file kmodtool-afs so that it is not obliterating the standard one.
> * except people who believe, perhaps rightly, that kmod is flawed and
> kmdl is the answer; they aren't necessarily wrong but "hey install
> this other package of macros everywhere" wasn't really my cup of tea
> either. i can't say i love any of the answers. 1.4.7 will also include
> dkms support.
> OpenAFS-info mailing list
Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas