UsrMove and installing kernels on older releases
kay at redhat.com
Tue Feb 7 01:22:22 UTC 2012
On Mon, 2012-02-06 at 20:13 -0500, Josh Boyer wrote:
> With UsrMove now landed in rawhide, I'm assuming that you'll be wanting
> to commit the patch that makes kernel.spec install modules into
> /usr/lib instead of /lib. According to my understanding, this is mostly
> a "put things in the new proper location" more than it is a requirement,
> because the symlinks should still allow a fully functioning kernel to
> work (and they do in my local testing).
Yes, that's true.
It's a little bit more than correctness, it's the RPM db, which does not
reflect reality, and explicit:
in/from other packages can not be fulfilled by RPM/Yum when the package
is not already installed on the system. But none of that should really
> One of the things we do quite often during debug is ask users to install
> newer kernels on older releases. This lets us easily figure out if an
> issue is fixed upstream, etc. However, if the patch to install modules
> to /usr/lib goes in, I wonder if that will prevent people from easily
> being able to use such kernels on e.g. f15/f16 which obviously do not
> have the UsrMove feature. Admittedly I haven't looked into it much
> myself yet so perhaps I've missed something obvious that would allow
> this to still work.
Right, converted packages can not be installed on old boxes.
> If there is an issue with that scenario, I'd like to skip the patch
> until F17 becomes the oldest supported release. With things obviously
> still working as-is today, I don't see much issue in doing so.
Yes, I don't see a real problem with that. As soon as it is reasonable
to cut off older releases, we can add a:
Conflict: filesystem < 3
to the kernel RPM, which prevent is from getting installed on older
systems, and finally switch over to the new world.
More information about the kernel