[OpenAFS-devel] Linux Kernel Module build question

[Jeremy Katz]

On Thursday, July 12 2001, Derek Atkins said:
> Sam Hartman <hartmans@mekinok.com> writes:
> > Now that you have been presented a solution within the Redhat model
> > that could support this, I think you should adopt it.
> 
> Unfortunately it is not sufficient.  Unless there is some way to add a
> 'Requires:' that is based on the actual architecture, it still is
> insufficient for my needs.  If I could insert a requires statement
> that says, in essence, "Requires: kernel-2.4.2-3.i586" then yea, that
> would solve part of my problem.

If you build the packages with the architecture set and people ignore
it, they'll figure it out real quick and use the kernel of the proper
architecture.  If you're having the packages installed as part of the OS
installation (for places that customize Red Hat with their own
site-specific packages) or through some sort of package installer such
as autorpm, yup, or a variety of others, you will get the package of the
right architecture.  If not, that is a bug in the program.   Yes, there
are a lot of variables here.  But, making things more complicated is not
the answer.  Keep it simple and within the framework provided for you
and it will be easier for everyone, both users and the people providing
packages.
 
> Even if the 'requires' problem got solved, it still wouldn't help me
> build for multiple kernels at once.  I would have to go out an
> specifically rebuild the package for every kernel, manually.  This
> means instead of a single 'rpm' build command, I would need N*M rpm
> commands, where N is the number of architectures and M is the number
> of kernels.  That can get to a large number relatively quickly (for RH
> 6.2 I built against 6 kernels; RH 7.1 has 5 'architectures' for x86).

And I still maintain that you don't need to build for every kernel ever
released with a release of Red Hat Linux.  Telling people to upgrade
their kernel or rebuild a source package is not too much to ask IMHO.
OpenAFS is not simple... the people just downloading and installing this
had better be able to handle that if they expect to get it working (or,
they'll have a competent system administrator at which point they won't
be the people installing it).

[snip]
> Sam, you have the benefit of actually building something that will be
> 'shipped' with the OS as a whole.  I don't have that benefit.  So,
> just because something is the right way for you, and might be the
> right way if Red Hat did it themselves, does not necessarily mean it
> is the right way for me to do it as a third-party.

It also doesn't mean it's not the right way for you to do it as a
third-party.

Jeremy