Rename dnf5-makecache timer to dnf-makecache when dnf5_obsoletes_dnf

[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

[gordonmessmer]

This version renames the unit only in the spec file, similar to the creation of the "yum" and "dnf" bindir symlinks.

$ rpm -qpl /tmp/tito/dnf5-5.2.10.0-1.git.3819.127cb98.fc40.x86_64.rpm | grep systemd | grep makecache
/usr/lib/systemd/system/dnf5-makecache.service
/usr/lib/systemd/system/dnf5-makecache.timer
$ rpm -qpl /tmp/tito/dnf5-5.2.10.0-1.git.3819.127cb98.fc41.x86_64.rpm | grep systemd | grep makecache
/usr/lib/systemd/system/dnf-makecache.service
/usr/lib/systemd/system/dnf-makecache.timer

[evan-goode]

I'm not sure it's a good idea to change this now. Won't this mean that users who have enabled dnf5-makecache.timer would now have a broken symlink in /etc/systemd/system/timers.target.wants? Could we perhaps instead provide a symlink from dnf-makecache.timer to dnf5-makecache.timer?

[gordonmessmer]

As far as I can tell from testing:

• a symlink could be valuable if any users have noticed that there was a timer, and if they'd written any management playbooks to turn it on -- the symlink would keep those playbooks working
• a symlink named dnf-makecache -> dnf5-makecache would still require Fedora to modify presets. The symlink alone is insufficient to enable the timer by default
• a symlink named dnf5-makecache -> dnf-makecache (that is, symlink and renaming the regular file) would enable the timer by default and it would protect management playbooks developed since the release of dnf5 5.2.7.0, but any existing symlinks to dnf5-makecache in timers.target.wants will be ignored.

The dnf5-makecache unit has existed since mid November '24, while the dnf-makecache unit has existed since Fedora 22 in '14. I'm inclined to believe that renaming the regular files is the right thing to do.

If there is a symlink in timer.target.wants that enables the timer on any system, renaming the unit may leave a broken symlink, but the new (renamed) unit will be enabled by default. So I'm not sure the dangling symlink is a major issue.

[Conan-Kudo]

a symlink named dnf-makecache -> dnf5-makecache would still require Fedora to modify presets. The symlink alone is insufficient to enable the timer by default

This is not hard for us to do. In fact, enabling the dnf5-makecache unit in presets is absolutely the easiest thing for us to do in Fedora. So this is not a valid objection.

[gordonmessmer]

This is not hard for us to do. In fact, enabling the dnf5-makecache unit in presets is absolutely the easiest thing for us to do in Fedora. So this is not a valid objection.

Every solution involves a number of compromises, and I am simply listing them. I don't think any description is "invalid" unless it's incorrect.

Having said that, I can't tell from your feedback if you are in favor of this change, against this change, or what solution you would consider acceptable.

[Conan-Kudo]

My core issue is that we can't really pretend dnf5 is like dnf4 or yum. There are tons of breaking changes and behavioral differences, even if we ignore the not-yet-reimplemented features. I get people want to do this, but we decided as a project to explicitly not do this because it creates mismatched expectations for people.

[keszybz]

I think that's a misunderstanding of how the users view this. From a user's POV, yum/dnf/dnf5 are the thing that you call to install/update/remove/list/query packages. And those commands operate on rpms and repositories in the same way and actually even use the same repo config data. The internal architecture may be quite different, but as a user, I really really don't care about this. If it's faster and slightly more reliable, then I'm happy. If the option was renamed without providing backwards compat (why ever do that?!), then I'm a bit annoyed. If some feature is gone, I might delay upgrade… But it's still the same tool, and I won't install or use two in parallel, because it just doesn't make sense to have two separate views of the installed package set. I think that for some reason you're concentrating on developers, who would care about the APIs and architecture and all that, but the name of the main binary is for users. Our goal when creating the distro is to have a smooth experience where you don't need to figure out things and solve problems after every upgrade. Every time a program gets renamed, or options are changed incompatibly, or users need to reconfigure things after an update, we move further from this goal. Sometimes we don't have a choice, but let's agree that this is not a good thing.

Or in other words: yes, I understand that the libraries and code are quite different, and many things changed with dnf5, and some features changed incompatibly. Let's describe those in the docs and have users adjust, but let's not make any additional incompatible changes.