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

[Ville Skyttä]

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
  k-m-foo-1.0-1.%{kver1}

  kernel-%{kver2} # eg. kver2 = 2.6.12-1.1387_FC4
  k-m-foo-1.0-1.%{kver2}

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
  Release: 1.2.6.12_1.1234

  Version: 1.0
  Release: 1.2.6.12.1_1.2345

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.