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