UsrMove and installing kernels on older releases

[Kay Sievers]

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