❦ 22 mars 2017 20:08 +0100, Lukas Schwaighofer <lukas@schwaighofer.name> : > I would like advice on the concept itself: Is it ok or should a take a > different approach? Can someone point me to a package that handles a > similar service startup situation differently (better)? It seems a good plan. > Other than that I'm quite concerned about the upgrade path: > * I do remove /etc/arpwatch.conf from the package (but this will of > course stay in the filesystem); converting this into individual files > in /etc/arpwatch/IFNAME.iface in a maintainer script would be > possible… You can use dpkg-maintscript-helper rm_conffile which does the right thing when removing a file. I wouldn't bother converting the current configuration. Explain the situation in NEWS.Debian. > * I have a README file in /etc/arpwatch/ which is not a configuration > file. Is there a better solution and, if not, would this be > acceptable? This is acceptable. Lots of packages do that. > * After the upgrade, the service has to be explicitly activated for the > interfaces it should be started on, even if the service was > previously running (again, could be handled in a maintainer script > at least for some cases, but is not easy to do considering how the > different init systems need a different form of activation) Same, let the user handles that. -- He that breaks a thing to find out what it is has left the path of wisdom. -- J.R.R. Tolkien
Attachment:
signature.asc
Description: PGP signature