So, coming back to the steps needed for this to happen as discussed
in the FESCo ticket, I
think the first one is to decide how users can start testing dnf5 on
"expendable" machines.
The proposal says that dnf5 can be installed in parallel with dnf. I think this
doesn't highlight what things will be broken, as tools will still use dnf. Also,
@zbysek asked in the FESCo ticket what data from the RPM database is shared between the
two, but didn't receive a reply: say, as a user, I install dnf5 in parallel with
dnf,
will I be able to "dnf install foo" and then "dnf5 uninstall foo"?
Thank you for pointing it out. I will provide additional information in both Fedora
proposals (replacement of DNF
https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5#Scope and microdnf
https://fedoraproject.org/wiki/Changes/MajorUpgradeOfMicrodnf#Scope). Using DNF and DNF5
in parallel to manage your system is safe. Both packagers will see content modification
correctly, but they will not have not additional information to performed transaction. The
situation will be the sile like when you do operation using RPM directly.
For those two things I wrote above, if in the end dnf5 will be renamed back as dnf to be
a
drop in replacement, wouldn't be better to have dnf5 obsolete dnf starting from now?
I
don't think anyone is going to test it on a production machine anyway...
Mattia
There is no plan to rename DNF5 to DNF. Our team already shipped YUM as DNF and we
discovered that it is not good idea. DNF5 upstream is not going to repeat the same
mistake.
Jaroslav