Depends on how many maintainers should fix their package, more below.
On 8/4/21 4:22 PM, Zbigniew Jędrzejewski-Szmek wrote:
> 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.
Does it bother users to include new dependencies during upgrades? I
would not certainly notice when I upgrade ~500 packages every week.
Annoying to how many package maintainers? Would owning those directories
by every package using those directories would be less annoying?
Alternative would be moving these empty directories into systemd-libs,
which is installed in fedora:rawhide podman container. It seems also in
mock build environments. No public visible changes, what would you think?
[root@8fec9bc0b895 /]# rpm -qf /usr/lib/systemd/system/
file /usr/lib/systemd/system is not owned by any package
>> 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.
What I don't like about this approach, it would result in ~1600 times
single line for every package delivering some unit file. Or the same
number of rules violation. Versus single package change working for all
of them. I admit it would mean your package should be updated instead of
mine (and others). I would update it if I were in your position.
Are *-filesystem packages considered deprecated?
>> 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
Cheers,
Petr
--
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
