[OpenAFS] In the RPM spec file, what is the goal of the special fedora option?

Paul Johnson pauljohn32@gmail.com
Tue, 12 Feb 2008 20:01:56 -0600


On Feb 12, 2008 4:03 PM, Derrick Brashear <shadow@gmail.com> wrote:
> On Feb 12, 2008 4:58 PM, Paul Johnson <pauljohn32@gmail.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.

pj


> Derrick
> * 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
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>



-- 
Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas