Re: UsrMove and installing kernels on older releases
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[1] 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:
Requires: </path/to/file>
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
matter.
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.
Kay