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@xxxxxxxxxx <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Current office temperature: 78 degrees Fahrenheit.
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
