On Wed, 2006-08-16 at 23:23 -0500, Jason L Tibbitts III wrote:
> >>>>> "RC" == Ralf Corsepius <rc040203@xxxxxxxxxx> 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
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
