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.
[...]
Oh wait, something else I want to comment on --
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")
Ouch -- this won't work. The .1 here will be very very confusing. For
openafs 1.3.84, the _package_ release shouldn't be 1.3.84.1 or whatever --
it'll make it hard to match up to the actual source. I think this is *worse*
than putting the version in the name.
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}
'cause hey, that's what the Release tag is supposed to be fore*.
%{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,
Oh, there's another problem -- can't have a "-" in the release #.
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.
Passed in in a loop from the buildsystem? That seems decent.
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.
[...]
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).
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.
--
Matthew Miller mattdm(a)mattdm.org <
http://www.mattdm.org/>
Boston University Linux ------> <
http://linux.bu.edu/>
Current office temperature: 78 degrees Fahrenheit.