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.
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?
Your package require systemd?Systemd own this directory?If yes it is OK
If you mean warning from fedora-review then it tool may be old. But reviewer must manually check all points and not use only automatic reviewing tools.
вт, 3 авг. 2021 г., 13:05 Petr Menšík <pemensik@xxxxxxxxxx>:
Hello,
I just did package review and noticed systemd service files are
installed into %_unitdir without proper. I failed to notice all my
packages install into the same directory without depending on that
directory.
I did not find explicit note about the issue anywhere in Packaging
Guidelines. Unowned directories [1] note only 'core packages' without
precise specification, how can one identify core package. While I agree
systemd IS core package for sure, is there reason why systemd-filesystem
noarch subpackage does not own %_unitdir, %_userunitdir and %_tmpfilesdir?
I admit systemd might be missing only in few containers without init
system. Does systemd have special expection? Can be guidelines updated
to mention this is okay? In that case fedora-review should be adjusted
to not warn about those directories.
I would propose creation of systemd-filesystem package required by
systemd, which would pass general rule about *-filesystem package not
required.
Any opinions?
Regards,
Petr
1.
https://docs.fedoraproject.org/en-US/packaging-guidelines/UnownedDirectories/
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik@xxxxxxxxxx
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
_______________________________________________
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
_______________________________________________ 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
-- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemensik@xxxxxxxxxx PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
_______________________________________________ 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
