search

fpv-wtf / wtfos-configurator

Configurator for wtfos, with built in margerine
GNU Affero General Public License v3.0
42 stars 16 forks source link

Allow export and import of installed packages and package configurations #366

Open j005u opened 1 year ago

j005u commented 1 year ago

I've seen a number of users recently ask for a way to "CLI dump" their packages and package configs in preparation for upgrading the underlaying FW in order to be able to restore them after.

Technically all we'd need is to export a file with a list of user-selected installed packages + a dump of the package-config config.json-s.

Export could largely be achieved with the package debug info export mechanism we implemented, but never shipped. Import would need different handling.

TBH a few recent issues could also have been solved a lot quicker if msp-osd did write a debug log of major events. @stylesuxx I presume that old log export feature is hopelessly behind master anyway?

stylesuxx commented 1 year ago

Sorry, totally missed that issue.

Yeah, I closed the PR some time ago, but I can re-open and re-base it and see how much work it would be to get it going. Although I am not fully convinced that this is what we need.

Export of the config files could be easily done, but what are the constraints for this? I mean, are we going to only allow configs to be re-imported if the packages have the same versions, or do we simply "try" to import what is possible? I think it would make the most sense to only allow this for the same version of packages.

j005u commented 1 year ago

I imagine it might be able to re-use some code from the log export stuff, but that wasn't the main point.

Given the current ipk schema makes packages responsible for upgrading (or having defaults for missing keys in) their own config files this should work fine without locking versions. Effectively restoring from an older backup is equivalent to having upgraded from that earlier version. I'm not aware of any packages manipulating config files during the install/upgrade process.

In any case, this is definitely not a must have, but since multiple users have mentioned it, I thought I might as well at least document it here.

Edit: thinking about it some more - packages can also have files such as manually installed fonts (although this specific issue should go away with font packages) that might also need backing up. So the same mechanism where a package can optionally provide a list of files to be dumped for diagnostics would also make sense for config export, in addition to just the config.json.

stylesuxx commented 1 year ago

I'd then start with a mechanism to back up the configs first and go from there. I think we could at least re-use the packaging of the files from the old PR.

Restore would then just be extracting that backup package but making sure that the packages we restore the config files of are already installed. Or do you have anything else in mind here?

j005u commented 1 year ago

I would export the full list of user installed (rather than dep pulled in) packages and write that to a separate export file. The import would then first ensure all packages in the list are installed and then extract the rest of archive to / (or /opt/). Specifically to / so packages can export arbitary paths for backup, rather than strictly config.json.

We can't just rely on which packages we have config export for as not all packages have a config at all.