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/46010f8b6ab077bfbec45a59b1de99fb7871ee0a.
Normally the fpc announces changes, I don't remember if they did so
in this case.
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
