On Fri, Jul 10, 2015 at 9:58 AM, Dusty Mabe <dusty(a)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(a)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.
josh