[OpenAFS-devel] openafs spec-file kernel-detection

[Alexander Bergolth]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

On 05/16/2006 03:45 PM, Derek Atkins wrote:
> Alexander Bergolth <leo@strike.wu-wien.ac.at> writes:
>>Thanks.
>>Another issue that I noticed is the way how the kernel-depencency is
>>specified in the spec-file:
>>Requires: kernel = %{kversion}
>>
>>Current kernels provide the kernel capability for both only <version>
>>and <version>-<release>:
> 
> Current kernels, yes, but not older kernels.  For example, on RHEL3:
> 
> [root@vmware-rhel3 root]# rpm -q --provides kernel
> kernel = 2.4.21
> kernel-drm = 4.1.0
> kernel-drm = 4.2.0
> kernel-drm = 4.3.0
> kernel = 2.4.21-4.EL

Hmm - too bad. :(

>>Unfortunately the first capability causes rpm to register a general
>>capability for 2.6.16 regardless of the exact release and renders the
>>last capability (kernel = 2.6.16-1.2111_FC5, including the
>>release-string) effectless. See
>>http://distro.conectiva.com.br/pipermail/apt-rpm/2003-August/001951.html
> 
> Well, I do use kernel{,-smp} = {kvers}-{krel} -- so it does put
> 
>    kernel-smp = 2.4.21-4.EL
> 
> into the RPM for SMP kernels.  So technically I'm not using the first
> capability, I'm using the "last" capability.  Looking at the FC1
> OpenAFS RPMs it looks like the dependency isn't quite right, but it
> seems to work anyways.  The OpenAFS kernel RPM there has:
> 
>   kernel = 2.4.22-1.2155
> 
> Whereas the kernel itself provides:
> 
>   kernel = 2.4.22-1.2155.nptl

The problem is that the kernel provides both "kernel = <version>" and
"kernel = <version>-<release>". On my system this is:
rpm -q --provides kernel-2.4.22-1.2199.nptl_52.rhfc1.at | grep 'kernel '
kernel = 2.4.22
kernel = 2.4.22-1.2199.nptl_52.rhfc1.at

... but the second one is redundant because as soon as it provides
kernel = 2.4.22, this will satisfy _any_ dependency on "kernel =
2.4.22-<something>", so it just doesn't matter which "Requires:
kernel"-tag you are using, any 2.4.22 kernel will fulfill this requirements.

That's why I suggested to use the "kernel-%{_target_cpu}" dependency,
because the (newer) kernel-rpms only provide the exact
<version>-<release> string for this capability.

> I'm fairly sure that this is fixed by your patch to openafs-kvers-is.sh
> so I'm not too worried about it.

As mentioned above, any release string will be valid here.

>>The Fedora Extras kernel module guidelines suggest that kernel modules
>>should require "kernel-%{_target_cpu} = ${verrel}${variant}", like
>>Requires:         kernel-i686 = 2.6.14-1.1776_FC4
>>
>>See http://www.fedoraproject.org/wiki/Packaging/KernelModules for details.
> 
> Oh, I know all about that.  I just can't follow it because it doesn't
> exist on all the platforms I support.
>
>>Since the kernels provide only the exact "<version>-<release>" string
>>for "kernel-%{_target_cpu}" (see above), dependency checks should work
>>using this approach.
> 
> Unfortunately because not all OSes I support use this feature I cannot
> use it.  So until I drop support for RHEL3 (and FC1) then I cannot
> switch over to using the kernel-%{_target_cpu} requirement, because it
> just wont work.

How about a feature-test? (Use "Requires: kernel-%{_target_cpu}" only
when available?)

Something like
- -------------------- snip! --------------------
if [ "$1" = "provideskernelarch" ]; then
  kernelrpm=`rpm -qf "$2"`
  if [ -n "$kernelrpm" ]; then
    if rpm -q --provides "$kernelrpm" |grep -q "^kernel-$3 "; then
      echo "kernel-$3"
    fi
  fi
  exit 0
fi
- -------------------- snip! --------------------
... for openafs-kvers-is.sh, which is feeded with arguments
provideskernelarch, %{ksrcdir} and %{_target_cpu}?

Cheers,
- --leo
- --
- -----------------------------------------------------------------------
Alexander.Bergolth@wu-wien.ac.at                Fax: +43-1-31336-906050
Zentrum fuer Informatikdienste - Wirtschaftsuniversitaet Wien - Austria

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFEaepbsYaksEkoAQMRAvE2AKCNebA7qunzkSGeDhSNiFd6cduR0ACeKBcQ
VBQEAFvmVOaJ3ylcugDpdXY=
=MlBU
-----END PGP SIGNATURE-----