On 8/5/21 6:47 PM, Zbigniew Jędrzejewski-Szmek wrote:
> 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.)
No, that is the reason why I proposed it. Guidelines already state
*-filesystem packages does not have to be depended on [1]. Just one,
probably systemd or systemd-libs, should depend on it to get it
installed. All other can then just ignore the directory exactly as you
have proposed. In this case it would not be breaking guidelines, but
according to them instead.
1.
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_ownership
>
> 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, 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.)
Imagine the required work, if someone realizes after a year that the
directory should be owned by a different group. This way would create so
many repetitions in different packages, which I think should be put into
single shared piece. The same way as the code.
>
>> Are *-filesystem packages considered deprecated?
> Officially, no. But we certainly don't add as many new ones as in the
> past.
>
> Zbyszek
--
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
