-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ship fwupd #449
Comments
yeah I like |
PR to move python dependency to sub-package: https://src.fedoraproject.org/rpms/fwupd/pull-request/2 |
This has recently landed in Fedora: https://bodhi.fedoraproject.org/updates/FEDORA-2020-728951fb41 |
Yep. Looks like this will ship when we move to F33 unless something drastically changes. |
OK so...there's a lot to like about fwupd but broadly speaking it's only useful on bare metal environments. A bit like usbguard...I'm hesitant to say that it makes sense to include fwupd in e.g. AWS instances. But saying one needs an extension to update the Secure Boot DBX isn't great (which would be true now that fwupd/fwupd#2326 merged). There are other sub-threads to discuss here, such as part of the CoreOS philosophy is automatic updates, but fwupd is "inert" by default. Should we try to have zincati enable firmware updates by default? I think eventually the MCO should support fwupd in the same way it supports rpm-ostree too. (And tangentially related the MCO will need to gain support for bootupd too) |
Can you do the dep list again on f33 please? I think we can certainly split out a lot of things as subpackages; for instance making the modem updating optional (but installed by default on workstation) gets rid of libmbim, libqml, and ModemManager; splitting out the coreboot support gets rid of flashrom, libftdi and pciutils-libs -- but I'd appreciate if you could identify what were the most problematic deps other that those. The python stuff should all be gone now. |
@hughsie Would it be possible to make dbxtool a subpackage? Seems odd that installing that pulls in all of fwupd.
I don't think I'd want the OS to presume this is safe to do by default. So I'd say at least making it opt-in. Though I'm not sure if that functionality should belong in Zincati in the first place. The sophistication Zincati brings is in update graphs, but that's not something we can realistically provide for all firmwares that fwupd supports. (Edit: to clarify, I agree otherwise with everything in #449 (comment)!) My proposal is to try to get dbxtool into a subpackage and ship it in FCOS, and then make fwupd an extension. |
I think that would also mean splitting out fwupd-libs, but that's probably no bad thing either. I do think (UEFI?) firmware updates are just as security sensitive (and thus as important) as dbx updates, if that helps. There's a binary called |
Ahh OK, so the new |
I think it links to libfwupdplugin, which then depends on libfwupd -- not a huge problem either way but I didn't want to cause a confusion. |
How's this for starters: fwupd/fwupd#2451
|
Thanks Richard, that sounds useful. Long term though this gets trickier because e.g. in IoT cases one might actually have a cell connection for devices and want to update the firmware, etc. (In general IoT spans the middle ground between laptops and data center servers and handling it too means we need more sophistication than just "minimal" and "full") |
Thanks @hughsie - do you think you could submit an update for Fedora 33 with those changes? |
Monday; that should be when the 1.5.0 release gets released upstream if nothing explodes in the interim. |
All, is the only remaining work item here to chase down dependency sprawl (which may already be done with Richard's work upstream)? |
1.5.0 was released this morning and is available in f32 and f33 too if that helps. Yell if anything explodes. |
fwupd is currently included in the next stream. Looking at the dependencies there, I only see the
Looks like this is related to proxy support. |
If you forcibly remove glib-networking, what breaks? At 4.4 Mb for the schemas it seems like something we should untangle.... |
The full dependency chain is: The bulk of the package is coming from the locales:
Looking into if this is really needed. |
From https://codesearch.debian.net/search?q=org.gnome.system.proxy&literal=1 (found via https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/issues/27), it looks like we will not be able to remove the package entirely. |
I mean, if we switched it to Reccomends rather than Requires, does libsoup explode in a ball of fire or just ignore the GNOME proxy settings? |
I think we want to keep proxy settings supported on FCOS so I will try to split this package in two. |
If you can, super; otherwise don't panic -- the IoT people also are quite upset with fwupd using libsoup rather than libcurl. |
As libcurl is already in FCOS, moving to a single HTTP library would indeed be beneficial for us too. |
Work in progress fwupd libcurl branch here: fwupd/fwupd#2601 -- review feedback or fixes very welcome. |
Does |
fwupd just released with libcurl dep: https://blogs.gnome.org/hughsie/2020/11/23/fwupd-1-5-2/ -- packages building in Fedora now. |
Wow, that was fast! Thanks! |
Neither |
This is now included in last week testing release. The package diff for this release is as follow (note that those packages may not have been pulled in by fwupd, this is the raw package diff between the F32 and F33 FCOS release):
I don't think that anything stands out here. |
You want fwupd 1.5.2 -- that drops a lot of the deps you just added. |
BTW as soon as we merge this it will bring back |
@cgwalters Reading coreos/bootupd#1 (comment), do we still need work on the bootupd side for fwupd support? |
Full list of deps removed with all the fwupd dep cutting:
|
I will close this one as fwupd should be included in the next stable release happening this week and the deps cut will happen in the next. Additional work will be tracked in new issue. Thanks @hughsie for the libcurl work! |
The fix for this went into stable stream release |
A lot of work has gone into fwupd - it's important to apply firmware updates too.
But it looks like their dependency set is pretty broken from our PoV:
The text was updated successfully, but these errors were encountered: