On 6/5/06, Tom 'spot' Callaway <tcallawa@xxxxxxxxxx> wrote:
> In fact, I'm not really calling for major packaging changes - by > making a few changes to kmodtool behind the scenes, all of this is > abstracted from the packager, who is free to demand a specific kernel > or just let the dependency resolution figure out if the kernel and > module will be compatible at RPM install time. The only issue really > is how this would affect official "policy" with regards to kernel > dependencies as you hinted at above. If kmodtool starts providing this by default, then there would be no need for the Requires: v-r in the policy. I suspect you'd need to convince the kmodtool author(s), not me. :)
That's what I'm trying to do at the moment :-) With that done, there's no need to make user-visible changes to the packaging process at this stage, except that we can introduce a >= type dependency on the base kernel release if it's felt that a kernel version should be included in addition to the binary dependency information. To check out what I mean, take a rawhide kernel and do: rpm -q --provides kernel on it. You'll see a set of dependencies, one per directory of the kernel source used to build that kernel. For example kernel(kernel) = blah means that the checksum for built-ins in the /kernel subdirectory is blah. This is then matched against in the dependencies of the module. Part 2. I've also spoken to the SuSE folks about agreeing on a joint packaging standard for driver updates that could be used in Fedora, OpenSUSE and potentially in commercial products at a later stage. There's a channel for communication there so I want to explore that in the longer term - having a common set of RPM macros that encapsulate our differences and present a single spec file format. I don't know if you folks will love or hate that idea :-) Jon. -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
