Bug#949690: debian-policy: "service unit should have the same name as the package" seems too strong
On Thu, Jan 23, 2020 at 12:43:34PM -0800, Russ Allbery wrote:
> Simon McVittie <smcv@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. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: