I'm unsure how to make it correct. Actually, two different packages provide the file.

I think we should leave it here. If you strongly consider this should be deleted - I will remove.

@oturpe Please review. It's my first PR to pagure.io. I'm new to the system, sorry for closing previous PRs.

@oturpe Please review. It's my first PR to pagure.io. I'm new to the system, sorry for closing previous PRs.

Unfortunately, I cannot do a full review, nor approve this pull request.
The main reason is that I am not in the Packaging Committee.
Also, I am not familiar with sysysers.
I just subscribe to notifications to see what is going on,
and decided to comment because I was wondering about mentioning end-of-life releases.
I should have explained this in the original comment.

However, I can give another random bit of feedback:
in the BuildRequires:, use %{_bindir} instead of /usr/bin.

As I said in https://pagure.io/packaging-committee/pull-request/1077#comment-160052, we probably can not change the way we setup users (moving from our macro to systemd-sysusers) without a system wide change request.

A good first step to get there would be to go over all the packages and move them to the new sysusers format first (which is something I'm slowly and progressively doing) and then we can do a simple macro switch behind the scene to switch all packages at once in a coherent fashion.

However, I can give another random bit of feedback:
in the BuildRequires:, use %{_bindir} instead of /usr/bin.

This is not a good idea. %{_bindir} might be modified by some additional %{_prefix}, like /app during RPM builds for Fedora flatpaks. This is one of the reasons why using the fully expanded expected path of binaries instead of using macros is the right thing to do in BuildRequires. (Those paths are not determined by the value of %{_bindir} in the current package, but by the value of %{_bindir} during the build process of the package that contains that binary, and those two values might not necessarily be the same.

@siosm I do not understand why we can't change packaging recommendations right now ? AFAIK it works, and we don't have to change all the packages to this new system, because all previous macroses still work.

However, I can give another random bit of feedback:
in the BuildRequires:, use %{_bindir} instead of /usr/bin.

This is not a good idea. %{_bindir} might be modified by some additional %{_prefix}, like /app during RPM builds for Fedora flatpaks. This is one of the reasons why using the fully expanded expected path of binaries instead of using macros is the right thing to do in BuildRequires. (Those paths are not determined by the value of %{_bindir} in the current package, but by the value of %{_bindir} during the build process of the package that contains that binary, and those two values might not necessarily be the same.

OKAY, changed back to /usr/bin

@mmarkk See https://docs.fedoraproject.org/en-US/program_management/changes_policy/#_fedora_packaging_committee.

Those kind of changes should be submitted to the Fedora Packaging Committee first.

We're going to close this PR now, as we think the best thing to do has now changed with some rpm changes?
Someone please do open a new PR (and change request) with something that means packages don't have to call programs.