On Thu, Jan 23, 2020 at 12:43:34PM -0800, Russ Allbery wrote: > Simon McVittie <s...@debian.org> writes: > > > If a package has a single system service with a systemd service unit, > > and the system service's name does not match the package's name, current > > Policy implies that this is probably a (non-RC) bug. > > > I think that's too strong. In particular, because the name of the service > > unit is part of the "API surface" of the system service, aligning the > > name of the service unit with the name used by upstream is usually > > more important than aligning it with the name of the Debian package, > > unless the name used by upstream results in conflicts or is otherwise > > poorly-chosen. This is analogous to the names of executables in the PATH > > and the SONAMEs of libraries, both of which we try not to change. > > Ah, hm, yes, that's a good point that I didn't notice when copying that > Policy recommendation over from the recommendations on init scripts. > > The obvious concern here is that multiple packages could use the same > service name, and making the service name match the package name reduces > that risk considerably. But I think I agree that staying consistent with > upstream is more important than adopting that policy in a strong sense. > > Do you have a suggestion for alternative wording? I think we still need > to say something about matching the name of the init script if any, and if > upstream doesn't provide a service unit, it seems reasonable to use the > name of the package (but maybe that should be encouraged rather than > recommended?).
... or maybe also if the package ship a service unit that is very different from upstream. Cheers, -- Bill. <ballo...@debian.org> Imagine a large red swirl here.