Hi Kay and Harald,
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).
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.
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.
josh
[1] http://harald.fedorapeople.org/downloads/usrmove/kernel-usrmove.patch
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
On Tue, Feb 07, 2012 at 02:22:22AM +0100, Kay Sievers wrote:
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.
Ah, right. Though if some other package is doing e.g. Requires: /usr/lib/modules/<whatever>/kernel/fs/fat/fat.ko I think I would track that maintainer down and remove their commit privs ;)
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.
Sounds great. Thanks for the quick reply.
josh
kernel@lists.fedoraproject.org