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. -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging