Re: Systemd unit files installed into unowned directories

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Dne 06. 08. 21 v 12:56 Zbigniew Jędrzejewski-Szmek napsal(a):
On Fri, Aug 06, 2021 at 11:43:52AM +0200, Vít Ondruch wrote:
Dne 05. 08. 21 v 18:47 Zbigniew Jędrzejewski-Szmek napsal(a):
On Thu, Aug 05, 2021 at 04:45:31PM +0200, Petr Menšík wrote:
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.
But most of those 1600 packages would need to add Requires:systemd-filesystem.
(As discussed earlier in the thread, no Requires:systemd dependency is
needed nowadays.)

N.B.: If we're going to add a line to 1600 packages, I think it's much better
to add one line in %files

Not expert on systemd or unit files, but if there is some directory
structure, where there is basically just one file, isn't it better
to own some of the top levels of the directory structure instead of
the specific file? Maybe the guidelines should be updated to specify
the package should own %_unitdir instead of the unit file.
The guidelines already specify that. (They say that package must either
depend on a package that owns the directory, which would generally be
systemd, though there are other packages which co-own the directory,
or own the directory itself.) We're discussing how to satisfy this without
depending on systemd. Björn's idea of adding it to filesystem I think is
the most reasonable solution.


Sorry, I think I did not explained it understandably. So there is this %files section [1] in the systemd guidelines where could be something like:


~~~

Do not list each individual unit file in the %files section. Instead list just /usr/lib/systemd (or whatever suitable macro there is) directory to properly own the unit files as well as the directory structure where they reside.

~~~


IOW if there was %{sytemd_unit_files} macro which would be listed in %files section and it would expand to /usr/lib/systemd, that would be enough. This will do its job correctly unless there are some other files in the directory structure, which I assume is unlikely.


This is very naive example for Postgres:


~~~

$ git diff
diff --git a/postgresql.spec b/postgresql.spec
index cc59dd4..29cf2fe 100644
--- a/postgresql.spec
+++ b/postgresql.spec
@@ -1136,7 +1136,7 @@ make -C postgresql-setup-%{setup_version} check
 %{_mandir}/man1/postmaster.*
 %{_sbindir}/postgresql-new-systemd-unit
 %{_tmpfilesdir}/postgresql.conf
-%{_unitdir}/*postgresql*.service
+/usr/lib/systemd
 %attr(700,postgres,postgres) %dir %{?_localstatedir}/lib/pgsql
 %attr(644,postgres,postgres) %config(noreplace) %{?_localstatedir}/lib/pgsql/.bash_profile
 %attr(700,postgres,postgres) %dir %{?_localstatedir}/lib/pgsql/backups

~~~


Vít


[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Systemd/#_files_section




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
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux