Due to the use of intercept -g these must be combined into a single job definition, otherwise only the config which is loaded first will succeed.
The simplest way would be to add some checks to our postinst and replace the two config files with a single one stored in both packages, but this is hacky, interferes with dpkg-buildpackages expectations for conf files (files in etc) and is exponentially tedious to continue to do when packaging other plugins as you then have to have an additional alternate config for each potential pair of plugins that require this.
This likely means using sed (and similar) to manually edit the yaml, and then the rename the file to indicate which pacakges "own" it i.e. have created or edited it. On postinst, we can check for these names and if we are the only "owner" we can remove the file, otherwise, we reverse the edit process from preinst.
As the packaged config solution may also interfere with any configs written by the user (they won't get removed, but there may be a scenario where the packaged config trumps the user config), preinst should ask in stdin if the user wants to install the default configs or not.
Due to the use of
intercept -gthese must be combined into a single job definition, otherwise only the config which is loaded first will succeed.The simplest way would be to add some checks to our postinst and replace the two config files with a single one stored in both packages, but this is hacky, interferes with dpkg-buildpackages expectations for conf files (files in etc) and is exponentially tedious to continue to do when packaging other plugins as you then have to have an additional alternate config for each potential pair of plugins that require this.
Instead, the configs could be manually constructed, see: https://www.debian.org/doc/debian-policy/ap-pkg-conffiles.html#fully-featured-maintainer-script-configuration-handling
This likely means using sed (and similar) to manually edit the yaml, and then the rename the file to indicate which pacakges "own" it i.e. have created or edited it. On postinst, we can check for these names and if we are the only "owner" we can remove the file, otherwise, we reverse the edit process from preinst.
As the packaged config solution may also interfere with any configs written by the user (they won't get removed, but there may be a scenario where the packaged config trumps the user config), preinst should ask in stdin if the user wants to install the default configs or not.