On Tue, 2005-06-28 at 21:24 -0400, Matthew Miller wrote:
On Tue, Jun 28, 2005 at 07:40:52PM -0500, Tom 'spot' Callaway
wrote:
> - 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.
Leaving everything else aside for a sec, this doesn't screw up bugzilla if
you do it as a subpackage -- same way kernel and kernel-smp don't.
I think we have to assume that there will be some kernel-module packages
that just consist of drivers, with no extra user space addons.
I think it's better to have this in the release:
> Release: %{kver}
> (Where %{kver} is the kernel we're building against)
> Requires: kernel-%{_target_cpu} = %{kver}
> BuildRequires: kernel-devel-%{_target_cpu} = %{kver}
Release: %{realpackagerelease}.%{kver}
OK, so lets say we do this.
In this case, we have %{kver} in %{release} to keep %{release} unique
(and thus, have unique NVR). However, we can no longer just use
%{release} as our check variable in yum. In this scenario, we need to
instead make yum check some sort of "magic" provides that only
kernel-module packages will have (not as much of a hack as might be
thought).
In the spec, we put:
Provides: kernel-module-openafs-kver = %{kver}
Basically, to modify my original yum logic path:
- Does any kernel-module-openafs package exist on the system with the
same kernel-module-openafs-kver?
- If yes, remove it (rpm -e). If no, continue.
- Install new package (rpm -i).
Oh, there's another problem -- can't have a "-" in
the release #.
%define cleankver %(echo %{kver} | sed s,-,_,g)
My only concern here is maybe particular to openafs -- the kernel
module
source isn't distributed separately from the other library/userspace/gunk. I
guess I *could* make an openafs.src.rpm and a separate
openafs-kernel.src.rpm both containing the same source tarball, but that
seems kinda wrong. On the other hand, hey, maybe it isn't.
Or you could make the userspace gunk in a subpackage. No reason that
kernel-module-openafs can't generate both kernel-module-openafs and
openafs packages.
You can override the version and release for the openafs package.
Haven't thought this through completely, but there's one more
factor too:
kernel-module-openafs-1.3.84 will be required by the openafs-client package.
Shouldn't be a problem. We'll just pretend we're anaconda and --nodeps
the remove, knowing that the install is coming right afterward.
~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!