Rename dnf5-makecache timer to dnf-makecache.

[gordonmessmer]

Some maintainers of Fedora presets would prefer that the dnf-makecache timer use the unversioned name so that the presets (and Ansible playbooks, etc) do not need to be updated to account for renaming it. This change would create a file conflict between the "dnf" and "dnf5" packages in Fedora, but it's already impossible to install them simultaneously because dnf5 "obsoletes" the old dnf package.

This PR will use the unit name "dnf-makecache" when "dnf5_obsoletes_dnf", and "dnf5-makecache" when it does not obsolete dnf.

@keszybz @Conan-Kudo

[keszybz]

I didn't test this, but it looks like it DTRT.

[gordonmessmer]

$ tito build --builder=mock --arg mock=fedora-40-x86_64 --rpm --test --verbose
$ rpm -qpl /tmp/tito/dnf5-5.2.10.0-1.git.3820.9a81c30.fc40.x86_64.rpm | grep systemd | grep makecache
/usr/lib/systemd/system/dnf5-makecache.service
/usr/lib/systemd/system/dnf5-makecache.timer

$ tito build --builder=mock --arg mock=fedora-41-x86_64 --rpm --test --verbose
$ rpm -qpl /tmp/tito/dnf5-5.2.10.0-1.git.3827.921b6c1.fc41.x86_64.rpm | grep systemd | grep makecache
/usr/lib/systemd/system/dnf-makecache.service
/usr/lib/systemd/system/dnf-makecache.timer

[gordonmessmer]

Please do not squash these two commits.

[Conan-Kudo]

Realistically, we are not ever going to default to renaming the prefix to dnf- upstream. We didn't do it for the binaries, so we aren't going to do it for the systemd units either.

[keszybz]

But… why? What is the state you envision two years from now? People installing dnf-4 alongside dnf5 for funsies? This whole transition was dragged out way more than it ever made sense, but we should be thinking how to finish it. And this means making the transition as easy as possible for users, avoiding incompatibilities unless absolutely necessary, and in general completely replacing the old codebase.

[Conan-Kudo]

We are going to have to be able to use dnf4 and dnf5 on the same system for as long as RHEL 8 and RHEL 9 are supported, simply because of Mock. And that is going to be for a very long time.

[Conan-Kudo]

And also, DNF5 is a significant break from DNF4 and even YUM. Implying things that aren't true isn't going to get us any favors.

[keszybz]

"python 3000" was a significant break from python 2.x too. Some similar choices were made: gratuitous incompatibilities, refusing to add aliases and workarounds for compatibility, introducing all the pent up janitorial cleanups together with the bigger architectural changes. This caused people to delay adoption and dragged the transition out to more than a decade. And similarly to this transition, because the incompatibilities were inflated, people insisted on parallel installation and different binary names. But at some point, the transition needs to be over. New maintainers and users come in that have never even used the old version and they drop the baggage. Everybody expects python to just be the latest python version now, end of story.

I don't want to pretend that dnf-4 and dnf5 and yum are the same. I like the new dnf because it is different and significantly better than the old version. Allowing parallel installs and having measures in place to allow downstreams to adjust the packaging is all reasonable. But the defaults should be that dnf version 5 is "the dnf", expected to be the one package manager on the system. The name, examples, docs, etc., should be targeted towards the future where there is just one dnf version, not towards the past.

[gordonmessmer]

"Realistically, we are not ever going to default to renaming the prefix to dnf- upstream"

Is that a comment on this PR generally, or on the comment in CMakeLists.txt?

dnf5 already takes many of the unversioned "dnf" names when dnf5_obsoletes_dnf is defined in the spec, so I think this change is consistent with existing practice.

[Conan-Kudo]

Is that a comment on this PR generally, or on the comment in CMakeLists.txt?

This is a comment about you renaming the unit files in Git. All "unversioned" stuff is in the spec file (which is Fedora-specific).

[gordonmessmer]

What would you consider to be an acceptable approach?

Would it be acceptable to revert the first commit and continue renaming the files on install in cmake?

Would it be acceptable to revert both commits and simply rename the unit files in the spec when dnf5_obsoletes_dnf ?