On Sun, 2005-07-03 at 16:11 +0200, Thorsten Leemhuis wrote: > - These macro definitions are now found in the top of the spec file: > %{!?kver: %define kver %(uname -r)} > %define ksrc %{_usrsrc}/kernels/%{kver}-%{_target_cpu} > %define moddir /lib/modules/%{kver}/kernel/misc > %define mainpkgname ndiswrapper > %define mainpkgversion 1.2 > %define mainpgkrelease 1 > Yes, in other packages I would not like these "mainpkg*" definitions on > the top, but in this type of package I think they are helpful. I think you're mostly right. mainpkgversion and mainpkgrelease are redundant, however. Just use Version and Release for that. > - The main kernel-module package is now named > "kernel-module-%{mainpkgname}-base" (if someones knows something better > then "base" tell me). Perhaps instead of -base, it could be -source. I'm ambivalent on that, really. > The kernel-module itself is now placed in > %package -n kernel-module-%{mainpkgname} > So only one SRPM is created no matter how much different kernel-modules > are build. This makes sense, good thinking. > - Avoid some problems when kernel-module and kernel are deleted in one > rpm transaction (anyone knows a better way to fix? "Requires(postun): > kernel-%{_target_cpu} = %{kver}" does not work): > -- Only depmod when System.map is still there > %postun -n kernel-module-%{mainpkgname} > [ -e "/boot/System.map-%{kver}" ] && \ > /sbin/depmod -e -F /boot/System.map-%{kver} %{kver}> /dev/null || : > -- In %files: > %dir /lib/modules/%{kver}/ > so that dir is removed during remove. The kernel package already owns that dir, I don't see why this is here. rpm removal ordering should take the module out first, then the kernel. Is that not the case? All in all, very good work. I think your proposal is shaping up to work well. Thanks for the time. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 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