On Wed, 2006-08-16 at 23:23 -0500, Jason L Tibbitts III wrote:
>>>>> "RC" == Ralf Corsepius
<rc040203(a)freenet.de> writes:
RC> I disagree on this. It is way too narrowly focused on
RC> implementation details of kmod.
To some degree I agree with this.
RC> What we needed is strict and narrow conventions on kernel-module
RC> NEVRs to assure proper interaction with installers.
Well, it's more than that; we have to ensure proper interaction with
the buildsys and there may be restrictions on file locations and such.
Agreed, like
we agree upon "apps go to %{_bindir}", "libs go to
%{_libdir}", we need a clear and strict convention on where
kernel-modules need to be installed.
How to handle accompanying userspace libs/apps, whether to use split or
unified srpms/specs, how many kernel-modules to build simultaneously
from one spec are implementation details, each with different pros and
cons.
But beyond those things I agree that a bit of leeway is reasonable.
Of course, this stuff is _hard_, and the templates are a great idea
because it allows packagers to just plug the details in. But that's
different from saying that the spec MUST conform to that template.
Exactly.
It's a particular rpm's macroscopic behavior as viewed by the
installers that matters.
So perhaps we could approach this issue from the other direction:
what
NEVR convention(s) and file locations are required so that rpm, yum
and the like will properly handle the modules, including parallel
installs without conflict? What do the spec(s) need to have so that
the buildsys can build them for all supported kernel versions and
variants?
Fully agreed, sounds very reasonable to me.
Ralf