> Actually, no. I'm not going to standardize kernel module packaging > _UNTIL_ at least yum is fixed. > > Let me reiterate some points that I have made in the past: Good, gets us all back on track. :-) > > - I do not plan to overload the %{name} value for kernel module > packages. This means that we will NOT be shoving the kernel version in > %{name}. Its ugly, it screws up bugzilla, breaks existing packaging > guidelines, and is altogether wrong. > > - Given that, we WILL need to put the kernel version (in some part) in > either %{version} or %{release}. Let me explain why: > I can tolerate %{release} > On SMP systems, at a bare minimum, there will be two kernels installed: > > kernel-smp-2.6.12-1.1400_FC5 > kernel-2.6.12-1.1400_FC5 > > If we do not use kernel version in either %{version} or %{release}, > we'll have no way to generate two packages with unique > %{name}-%{version}-%{release} values. > > We have to assume that each installed kernel will want to have a > matching module addon installed for it. > > I originally proposed (back in March) that we put the kernel version in > Release. This is a slightly revised proposal. > > Name: kernel-module-openafs > (where the value in the Name field is the name of the module, prepended > with "kernel-module-") > Version: 1.1 > (where the value in the Version field is equivalent to the kernel module > version, NOT the kernel version we're building against (in this example, > "1", followed by the build revision, in this example ".1") So %{version} ends up having the upstream version number and the release number combined. I think this is the worst part as its confusing to the packager. Why I advocate requiring %{kver}. However, I did not propose a solution for a unique NVR for eatch kernel type (smp, xen, etc). > Release: %{kver} > (Where %{kver} is the kernel we're building against) > Requires: kernel-%{_target_cpu} = %{kver} > BuildRequires: kernel-devel-%{_target_cpu} = %{kver} > > %{kver} gets passed by the buildsystem, for each kernel found in the > branch for which that package is being built. So, for our example > kernels, %{kver} would be 2.6.12-1.1400_FC5 and 2.6.12-1.1400_FC5smp, > respectively. FC4 and newer kernels have this value in the provides for > "kernel-%{arch}", so it should not be too difficult for the build system > to figure out the correct value for %{kver} from the target kernel > package. > > There is no need to use dist tags here, since %{kver} includes the dist > name. > > If a bugfix needs to be made to the package, then the .1 (build > revision) is incremented. If a new version of the kernel driver is > released, then the first part of the Version is incremented, and the > build revision is reset to .1 (if it is not .1). > > So, after the buildsystem does its thing, we've generated two new binary > rpms: > > kernel-module-openafs-1.1-2.6.12-1.1400_FC5.i686.rpm > kernel-module-openafs-1.1-2.6.12-1.1400_FC5smp.i686.rpm > > Since no previous packages with those n-v-r's exist, yum installs them, > just as it would kernels, doing the equivalent of an rpm -i action. > > Now, on the system we have all four packages installed: > > kernel-2.6.12-1.1400_FC5 > kernel-module-openafs-1.1-2.6.12-1.1400_FC5 > kernel-smp-2.6.12-1.1400_FC5 > kernel-module-openafs-1.1-2.6.12-1.1400_FC5smp > > But wait, I've found a bug in kernel-module-openafs. Easy enough to fix, > I patch it away, increment my build revision to .2, and we now have > these new packages available: > > kernel-module-openafs-1.2-2.6.12-1.1400_FC5.i686.rpm > kernel-module-openafs-1.2-2.6.12-1.1400_FC5smp.i686.rpm > > But, here yum doesn't know what to do. We can't do a -i, those packages > would conflict with the existing kernel-module-openafs packages. We > can't do a -U, because then we'd only end up with one > kernel-module-openafs package on the system. What we need yum to do is a > special operation that does the following (only for kernel-module > packages): > > - Does any kernel-module-openafs package exist on the system with the > same %{release}? > - If yes, remove it (rpm -e). If no, continue. > - Install new package (rpm -i). > I have a patch for yum that does exactly this except it keys off of the kernel requires. (Does kernel-module-openafs-1.1-2.6.12-1.1400_FC5 require the same kernel as kernel-module-openafs-1.2-2.6.12-1.1400_FC5?) So in a day or two I could probably have it edited to do the above. > After this process, the system has: > > kernel-2.6.12-1.1400_FC5 > kernel-module-openafs-1.2-2.6.12-1.1400_FC5 > kernel-smp-2.6.12-1.1400_FC5 > kernel-module-openafs-1.2-2.6.12-1.1400_FC5smp > > Now, if someone is willing and able to write the exception case needed > for yum in kernel-module-* packages, then I think we can document the > remaining standard bits, duct tape the necessary logic into the > buildsystem, and start doing kernel-module-* packages for FC4 and devel. > Since I already have a good bit of the code done... Spot, the only change I would like in this is to have the build number not in %{version} but as part of %{release}. So using your example, kernel-module-openafs-1-2.2.6.12-1.1400_FC5 Where the %{release} == build#.%{kver} This doesn't add or subtract any complexity from the code in Yum. It does make the versioning a little easier to grok. Reading the new mail I got as I wrote this it looks like Matthew and I agree. Cool. Jack > ~spot > -- > Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 > Fedora Extras Steering Committee Member (RPM Standards and Practices) > Aurora Linux Project Leader: http://auroralinux.org > Lemurs, llamas, and sparcs, oh my! > > -- > Fedora-packaging mailing list > Fedora-packaging@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/fedora-packaging -- Jack Neely <slack@xxxxxxxxxxxxxxx> Realm Linux Administration and Development PAMS Computer Operations at NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging