On Wed Oct 5, 2022, Maxwell G via devel wrote:
Hi Fedorians,
I think we should define a more through list of blockers/criteria that
dnf5 needs to meet before it can replace the current dnf.
The DNF maintainers have their list of requirements, but it would be
helpful for the wider community to test dnf5 and report which currently
unimplemented features/usecases would block them from adopting it.
Hopefully, the more popular, for lack of a better word, blockers can be
incorporated into the Change Proposal or otherwise required by FESCo as
a prerequisite for this change. This should help the DNF maintainers
prioritize, keep everyone on the same page, and ensure that dnf5 doesn't
prematurely become the default.
Some of mine:
- `dnf repoquery` -- Currently, `dnf5 repoquery` nowhere near meets the
capabilities of the old version. This is the most important to me.
- `dnf config-manager`
- `dnf copr`
- `dnf system-upgrade`
- `dnf needs-restarting` - nice to have
- Documentation for the Python API. Currently, the C++ library is
documented, but the Python bindings are not. I saw someone else ask for
this, and now I'm adding it to my blockers :). The current Python API
documentation is great, so I wouldn't want to lose that.
- A fully populated manpage. dnf5's manpage is nearly empty
right now.
Compatibility:
- The `dnf update` alias is missing
- `--refresh` is missing
- The old dnf has some zypper style aliases (e.g. in for install,
dsync for distro-sync). I don't use them, but I noticed they were
missing.
- I'm not sure what will happen with the old yum-utils aliases (e.g.
/usr/bin/repoquery). I always use `dnf repoquery`, but I'd reckon that
many others use the alias.
--
Best,
Maxwell G (@gotmax23)
Pronouns: He/Him/His