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