Wip/hughsie/fwupd sync.service #6337
Conversation
…ranch This allows the device to set a branch (e.g. the modem carrier configuration) and for the client to be able to *downgrade* the firmware version to make the device work.
|
@superm1 insane? |
Ohh for downgrade -- maybe we could run the -sync service as root always? |
A service that runs as root and potentially fetches stuff from the web? I'm a bit wary of that. |
Ew, indeed -- agreed. I guess it could work for things we already have in the cache -- e.g. an "offline only" mode -- we already store the firmware .cab for all modem carrier configs and so that's more likely than you'd expect. Similarly for a BKC, in that case a directory remote is going to be much more common as you probably don't want random things downloading GBs of data without some kind of user confirmation. |
|
How about instead having a mode for the daemon to auto-sync without a client? |
|
Thought about it more, here's my idea. When a bkc is specified in fwupd.conf you change fwupd refresh service behavior to cache not just metadata but also anything that is part of the bkc. The daemon reads the same key and if those devices show up will automatically upgrade/downgrade to match them. It will also forbid clients from upgrading/downgrading them manually. |
|
@superm1 I'm struggling with the idea of the daemon doing anything itself -- so far the story is that daemon is "dumb" and just listens for requests from the client. It feels wrong for the daemon to get the device hotplug event and then just start deploying without any kind of user notification. The same can be said of this PR of course. |
|
Well the important part is that it's only a manual opt in and that a log is saved somewhere of everything that happens. That's why I think only doing it with a BKC for example makes sense. |
Type of pull request: