2010/10/6 Denis Leroy <[email protected]>: > 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).
