❦ 22 mars 2017 20:08 +0100, Lukas Schwaighofer <[email protected]> :
> 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
signature.asc
Description: PGP signature
