On Wed, Aug 04, 2021 at 10:27:10AM +0200, Petr Menšík wrote:
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
I don't think so. This is an intrusive solution: visible to users
in package upgrade outputs, annoying to package maintainers.
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?
No, I don't think -filesystem packages are a solution we should be
recommending nowadays. If you want strict conformance to the guidelines,
insert '%dir %_unitdir' in the package: this is also a one-line solution
and doesn't require any other changes.
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?
This was changed in in 2019 in
https://pagure.io/packaging-committee/c/46010f8b6ab077bfbec45a59b1de99fb7....
Normally the fpc announces changes, I don't remember if they did so
in this case.
Zbyszek