On Fri, Jul 10, 2015 at 10:16:49AM -0400, Josh Boyer wrote: > 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. I think I understand better now. Yes, I agree that it would need to be programmatic and reliable. Would be great if there was a way to detect modules that have firmware requirements, but I think you mentioned earlier that it's not. > > >> 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? This might be a result of me being naive about when firmware is really needed or not. If it is safe to say that it is only ever needed for bringup on bare metal then I think doing the provides in fedora-release-cloud would be the right thing to do. Thanks again for being patient, Dusty _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
