2010/10/6 Denis Leroy <denis(a)poolshark.org>:
I've been asked (#1429) to upgrade open-vm-tools in F-13. Now,
this is
causing me some headaches because the latest versions of open-vm-tools need
the 2.6.34 kernels (because some of the modules provided by
open-vm-tools-kmod were upstreamed in 2.6.34, so the open-vm-tools package
no longer ships them, even though they're still needed for 2.6.33).
The problem with F-13 is that is spans both the 2.6.33 and 2.6.34
kernels.
In other words, if I push a more recent update of open-vm-tools, it will
have to include something like
Require: kernel >= 2.6.34
This will probably not match (because PAE varriant
mostly), or you
might try with Requires: kernel-uname-r >= 2.6.34
forcing the user to upgrade the kernel in order to install
open-vm-tools. So
the questions:
Users aren't expected to stay on older kernels. But when a
userland
tool need to exactly match the kernel side component, we usually (done
for nvidia/fglrx) push the new update along with the kernel update.
Anyway, if one want to stay with an older kernel, he can also stay
with an older userland (yum-plugin-versionlock is made for that).
- can kmods handle a dependency like this, so that 'yum install
open-vm-tools' will correctly bring in the kernel updates ?
Conflicts:
kernel-uname-r < 2.6.34 would have made the job in a
userland situation. In this one this will not work as one can have two
kernel installed together (one 2.6.33 while running 2.6.34).
I think the open-vm-tools update is for the Greater Good (tm), but
I'm not a
huge fan of forcing kernel upgrades on people...
So you currently force user to
stay on older and possibily unaccurate
open-vm-tools for current fedora kernel instead, which isn't
necessarily a good either.
Nicolas (kwizart).