Upgrade-check implant script can't handle ostree remote configuration files very well
If a configuration file in /etc/ostree/remotes.d
is used to manage an ostree remote instead of the ostree remotes ...
commands the implant script creates a problematic situation. The --force
flag causes ostree to create a second remote in a secondary data structure in conflict with the remote managed in the configuration file. This causes the ostree commands to fail with an error later and especially in the upgrade check test.
My work-around for this problem is to remove any configuration files in the implant script before creating the remote with ostree again.
Unfortunately ostree commands do not alter configuration files and configuration files are not named by their contained remote which makes it slightly harder to identify which configuration file belongs to which remote (one would have to parse the files to get that knowledge). Remotes managed by ostree or through configuration files can't be distinguished by ostree commands unfortunately.
It may be safe to assume, that when using the upgrade check script or more specifically the implant script, that one can remove any configuration files because the test is taking over the ostree remote configuration anyway. It may also be an example why having unified test scripts is not straight forward and easily breaks with each new use-case.
I argue that the work-around is good enough for addition into rose. I don't think that anything more sophisticated has a justified benefit nor that the configuration-file-case should be ignored by rose's default test scripts.