Fedora 22 is out, Fedora 23 is coming :)

Josh Boyer jwboyer at fedoraproject.org
Fri Jul 10 14:16:49 UTC 2015

On Fri, Jul 10, 2015 at 9:58 AM, Dusty Mabe <dusty at dustymabe.com> wrote:
> On Fri, Jul 10, 2015 at 07:44:25AM -0400, Josh Boyer wrote:
>> On Thu, Jul 9, 2015 at 10:35 PM, Dusty Mabe <dusty at dustymabe.com> wrote:
>> > On Tue, Jun 16, 2015 at 09:31:27AM -0400, Dusty Mabe wrote:
>> >> On Mon, Jun 15, 2015 at 01:10:58PM -0400, Josh Boyer wrote:
>> >
>> >
>> > In this case kernel-core could be installed without any modules and thus not needing
>> > linux-firmware.
>> >
>> > Does this make sense? Is it more complicated than that? I don't know. This is a
>> No, it doesn't really make sense.  Yes, it's more complicated.  Why
>> would you want to create yet another subpackage for modules instead of
>> just moving them into kernel-modules?
> I guess I didn't know moving them into kernel-modules was an option. I
> thought they were left in kernel-core (and thus separate from kernel-modules)
> for a reason.

Sort of.  The kernel-core package is kernel-core, not kernel-cloud.
It's useful for things outside of just the cloud image.

>> > genuinely innocent attempt at trying to propose a solution that might be an alternative.
>> Filtering modules to different subpacakges based on whether or not
>> they need firmware is pretty time consuming for really little gain.
>> You have to detect if they need firmware, move them, make sure depmod
>> on kernel-core isn't broken, etc.  The steps we use now are based on
>> kernel subsystem and for the most part work relatively well.  Making
>> that even more complicated just to move firmware-requiring modules
>> would mean it is more fragile and error prone.
> The proposal I laid out doesn't really require evaluating each of
> them. It was simply to move the ones that are currently in kernel-core
> into kernel-core-modules. Yes it would be more complicated simply
> because there is another package. Maybe this would be more fragile and
> error prone.

If this isn't done programmatically then it will break the next time a
module in kernel-core adds firmware requirements.  In other words,
just moving the existing modules but not future proofing it by
checking for that requirement is a half-assed solution that will lead
to breakage.  I don't like breakage.

>> Why don't you just add a Provides: linux-firmware to
>> fedora-release-cloud if this must be done on a packaging level?
> There are a lot of ways to do it. We could blank or remove the files
> after install. We could add a provides to fedora-release-cloud, etc.
> These are all pretty easy to do and will probably be what we have to
> do. The only reason I don't like these solutions is because a user
> could decide that they do need modules and firmware (these can easily
> be installed on bringup) and then they have to work with a botched
> system to figure out what they need to do to get them.

Why is a user installing the cloud image on real hardware for bringup?
 I mean, that problem exists regardless of how not including firmware
in the cloud image is done.  If they use an image that lacks firmware
on a machine that needs firmware, it won't work.  It doesn't matter
what technical solution is used to accomplish the goal of removing the
firmware from the image.

I understand the concern, but I don't think trying to code around
people doing intentionally weird things is a great idea.


More information about the cloud mailing list