On Fri, Jul 10, 2015 at 9:58 AM, Dusty Mabe <dusty@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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. josh _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
