Hi Zbyszek,
thanks for your comment. Wouldn't it be much clearer instead of turning
bind eye on the issue creating noarch systemd-filesystem subpackage,
which would own:
%files filesystem
%dir %_unitdir
%dir %_userunitdir
%dir %_tmpfilesdir
%dir %_sysusersdir
and systemd would just contain requirement on it
Requires: %{name}-filesystem
This would be 100% according to the Guidelines, every automated tools
should not raise any warning and developers would not have to pretend
they haven't seen it. Instead of silently breaching our guidelines, can
we adjust it to follow them?
Shall I try a pull request on systemd?
Few notes below.
On 8/3/21 5:31 PM, Zbigniew Jędrzejewski-Szmek wrote:
> 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
Unfortunately many packages will drag systemd into containers/mock
without ever needing it. I think that was recommended not long ago. That
includes bind and dnsmasq packages I own. Is the latest best practice to
remove %systemd_requires everywhere with just common services and use
just %systemd_preun macros to handle it? I have missed such
recommendation, was it in some announced change or at least here on
devel list?
It seems to be a smart change, but I found it just by pure coincidence.
I might not be the only one.
Cheers,
Petr
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
