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.
Vít
, directly adjacent to the line for the unit file,
then one or two lines somewhere in the header part of the spec file. (I
say two, because you'd probably also want a comment explaining why that line
is added.)
Are *-filesystem packages considered deprecated?
Officially, no. But we certainly don't add as many new ones as in the
past.
Zbyszek
_______________________________________________
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
_______________________________________________
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
