On Tue, Aug 03, 2021 at 05:12:22PM +0200, Petr Menšík wrote:
> It seems to me most of common services do not require systemd for
> functionality. They might be able to be installed in container without
> systemd involved. The more I look at [1], the more I think common
> package with some service should usually include just
> %systemd_{post,preun,postun_with_restart} snippets and instead of
> %systemd_requires just %{?systemd_ordering}. If the service does not
> require systemd to start, it should not require it, right? Snippets are
> prepared already to handle situation without systemd gracefully.
Yes. Even further, services should not require systemd, even if
systemd is normally used to start them. On normal installations systemd
is already installed anyway, so the dependency is moot. Not having
a hard dependency makes it easier to do custom installations,
tests in mock, containers, etc. So even %{?systemd_ordering} is
not necessary in most cases. The guidelines have been updated to
drop the Requires a while back.
> In that case, who should own %_unitdir and similar? systemd is not tiny
> enough to not make a difference. On the other hand number of package
> owning %_unitdir might be quite high. Could there be minimal 'virtual'
> owner?
It's fine to co-own %_unitdir. But I would say that it's also fine to
just ignore this issue, and let only systemd own the directory, even
if the package installing files under the directory doesn't have a
hard dependency on systemd. Owning directories is useful when the user
may install the package, uninstall it, and then be left with a "dangling"
empty directory. But this is unlikely to happen in the case of anything
systemd-related: systemd cannot be uninstalled on normal systems,
and on the other hand, on custom images that *never* had systemd,
you're unlikely to install and uninstall packages. So I'd advocate
this small breach of the guidelines, since it doesn't cause any real
problems and makes packager life easier.
Zbyszek
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
