On Wed, 2022-10-05 at 22:10 -0500, Maxwell G via devel wrote: > 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 > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue
This is not a blocker but a "nice to have". dnf5 doesn't seem to currently report unimplemented commands, you just infer it from it doing nothing. - `dnf5 search` is not implemented - plugins like tracer, snapper, etc. these are not mandatory, but would break my workflow - better documentation than dnf4 - failover priority in repo files So far the help/usage is good. This is more of a "when it's implemented" type of thing. The help/usage for dnf4 is god awful and hard to interpret. The man page is better, but not much. I suspect that the documentation was written more for developers than end users. Better machine readable output for scriptability. Maybe my dnf4 foo is not good enough, but much of the command output is not machine readable without using grep/sed etc.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
