Open d4s opened 9 months ago
I'd much rather have a dbus call e.g. something like fwupdmgr delete-remote test-lvfs
-- would that work?
For my purposes yes -- but since I know about the issue, I can cleanup it by my own.
However it doesn't solve the issue with manual removing of the remote.conf file.
How about additional check during fwupd refresh
? It might be enough to remove metadata for unknown folders in /var/lib/fwupd/metadata/
@superm1 how do you feel about this? I'm hesitant to delete files like this -- I don't think it's valid to have /var/lib shared on something like NFS -- but it does feel a bit magic.
A few thoughts
I personally feel like that /var/lib/fwupd is owned by fwupd process. Contents should only be removed if fwupd knows the remote is gone.
It might be better to put repo cache in /var/cache/fwupd.
Voting for /var/cache/fwupd
.
@hughsie additional thought -- it might be useful to check the timestamp of metadata and remove the outdated ones anyway
Describe the bug I've added test remote by copying LVFS remote config file into
/var/lib/fwupd/remotes.d/test-lvfs.conf
, did some tests and removed configuration file for remote. Stalled metadata exists:Steps to Reproduce
cp /etc/fwupd/remotes.d/lvfs.conf /var/lib/fwupd/remotes.d/test-lvfs.conf
fwupdmgr refresh
rm /var/lib/fwupd/remotes.d/test-lvfs.conf
Expected behavior Metadata cached for removed remote should be wiped out.
fwupd version information
Additional questions