Do better at handling old configuration versions, failing to start is not acceptable
Following the switch to pipewire by default in Fedora 34, I'm aware of two known cases where updating pipewire causes it to stop working because it can't read a previous version of one of its own configuration files. If the user never modifies any configuration they should not run into this as the package will update the stock files to a working version. However, it is not at all unusual for users to modify configuration.
One case is https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1931384 . The other was reported in a later F34 pipewire update, https://bodhi.fedoraproject.org/updates/FEDORA-2021-2c994d0609#comment-1949412 .
I honestly don't think it's acceptable for something as core as the main system audio server to fail to start up because it can't read an older version of its own configuration file. This is something that can and should be avoided with proper design and planning - e.g. having stock configuration in /usr/share
and not allowing it to be modified (at the distro packaging level, these files are not marked as configuration and so are always overwritten on package updates) and allowing the site admin to modify/override the defaults via files in /etc
; at worst, with this design, you can just ignore the overridden config in /etc
if it can truly no longer be parsed or understood, and start up with a logged warning.
It is also a good idea to allow for config snippets at the /etc
and user home dir levels, as opposed to expecting a modified copy of the entire configuration file to be present. systemd has very good design in this area; I'd encourage you to look into that and copy it.