Re: [Cluster-devel] kernel packaging split up landing in Rawhide
On Wed, Apr 30, 2014 at 07:56:29 -0400, Josh Boyer wrote: Nothing at the moment. Later this week I'm going to look at enabling auto-provides for kernel modules in the various kernel packages. This will make situations like this much more flexible, as gfs2-utils will be able to Requires: gfs2.ko (or whatever it is) instead of the package name. That will allow us to move modules around without breaking packages, and potentially get ride of k-m-e down the road. Once the auto-provides are enabled, I'll go through the tracker bug Bruno has open and fix up the userspace package requires. Thanks for this update. I was going to nag about this soon, if someone else hadn't.
Re: [Cluster-devel] kernel packaging split up landing in Rawhide
On Wed, Apr 30, 2014 at 5:41 AM, Steven Whitehouse wrote: > Hi, > > > On 29/04/14 22:41, Josh Boyer wrote: >> >> Hi All, >> >> As part of the F21 "Modular Kernel Packaging for Cloud" Feature[1], >> I've committed and pushed the kernel packaging split up into >> kernel-core and kernel-drivers subpackages. For those of you running >> rawhide, this really shouldn't be a major impact at all. When you do >> a yum update, you will see "kernel", "kernel-core", and >> "kernel-drivers" packages being installed. The end result should be >> in line with today's rawhide kernels. >> >> Note: Unless you're using a typical VM or Cloud image, don't uninstall >> the kernel or kernel-drivers packages. The machine may boot with just >> kernel-core, but it will lack drivers for a significant portion of >> bare-metal hardware without kernel-drivers installed. >> >> Despite best efforts in testing, it's always possible a bug or two >> snuck through. In the event that you do have an issue with this, >> please file a bug against the kernel package. >> >> josh >> >> >> [1]https://fedoraproject.org/wiki/Changes/Modular_Kernel_Packaging_for_Cloud > > > Just wondering how this will (or will not) affect kernel-module-extras ? Great question. It won't affect it. > Currently there is a dependency (largely for backwards compatibility > purposes) on kernel-module-extras from gfs2-utils and I'm wondering if that > will need to be changed (or dropped) as a result of this, Nothing at the moment. Later this week I'm going to look at enabling auto-provides for kernel modules in the various kernel packages. This will make situations like this much more flexible, as gfs2-utils will be able to Requires: gfs2.ko (or whatever it is) instead of the package name. That will allow us to move modules around without breaking packages, and potentially get ride of k-m-e down the road. Once the auto-provides are enabled, I'll go through the tracker bug Bruno has open and fix up the userspace package requires. josh
Re: [Cluster-devel] kernel packaging split up landing in Rawhide
Hi, On 29/04/14 22:41, Josh Boyer wrote: Hi All, As part of the F21 "Modular Kernel Packaging for Cloud" Feature[1], I've committed and pushed the kernel packaging split up into kernel-core and kernel-drivers subpackages. For those of you running rawhide, this really shouldn't be a major impact at all. When you do a yum update, you will see "kernel", "kernel-core", and "kernel-drivers" packages being installed. The end result should be in line with today's rawhide kernels. Note: Unless you're using a typical VM or Cloud image, don't uninstall the kernel or kernel-drivers packages. The machine may boot with just kernel-core, but it will lack drivers for a significant portion of bare-metal hardware without kernel-drivers installed. Despite best efforts in testing, it's always possible a bug or two snuck through. In the event that you do have an issue with this, please file a bug against the kernel package. josh [1]https://fedoraproject.org/wiki/Changes/Modular_Kernel_Packaging_for_Cloud Just wondering how this will (or will not) affect kernel-module-extras ? Currently there is a dependency (largely for backwards compatibility purposes) on kernel-module-extras from gfs2-utils and I'm wondering if that will need to be changed (or dropped) as a result of this, Steve.
