[Fedora-packaging] Updated kernel-module-packaging example with ndiswrapper (Was: example kernel-module package)

Ville Skyttä ville.skytta at iki.fi
Wed Jul 6 18:48:01 UTC 2005

On Wed, 2005-07-06 at 10:28 -0500, Tom 'spot' Callaway wrote:
> On Wed, 2005-07-06 at 18:16 +0300, Ville Skyttä wrote:
> > Or do we solve this with a policy (assuming the process you described
> > above would be implemented): "always bump the release of the "main"
> > package of a module package before building it for a new kernel"?
> > That'd result in only one srpm per module package per released kernel
> > "family".
> It would also result in unnecessary package upgrades. 

How so?  We wouldn't be building the module package again for older
kernels unless there are some real changes in it.  To illustrate
(leaving "tr - _" needed for the release tag aside for a moment):

  kernel-%{kver1} # eg. kver1 = 2.6.11-1.1369_FC4

  kernel-%{kver2} # eg. kver2 = 2.6.12-1.1387_FC4

In the above, k-m-foo-1.0-1.%{kver2} must not upgrade
k-m-foo-1.0-1.%{kver1} in the usual sense anyway, instead they both need
to be installed.  So this needs to be special cased in depsolvers, and
bumping the first digit of the release tag of k-m-foo when built for
kernel %{kver2} should not have any effect on the special case.

Also note that a side effect of stuffing %{kver} into the release (or
version) tag means that we might be in for surprises if we trust rpm's
version comparison algorithm to sort the "same" module packages for
different kernels consistently with the corresponding kernel versions.
For example:

  Version: 1.0

  Version: 1.0

The former is newer as far as rpm is concerned, it compares "1234" in
the former against "1" in the latter.

If the kernel packages' version number always has the same number of
"segments" (currently 3), and its Epoch is never bumped, the
inconsistency would never occur though.

More information about the Fedora-packaging mailing list