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.
-- Best,
Maxwell G (@gotmax23) Pronouns: He/Him/His
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
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-leave@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.
On Thu, Oct 6, 2022 at 5:11 AM Maxwell G via devel devel@lists.fedoraproject.org wrote:
Some of mine:
- `dnf repoquery` -- Currently, `dnf5 repoquery` nowhere near meets the capabilities of the old version. This is the most important to me.
I agree, repoquery is an absolutely essential tool for me. Without it, it would be impossible to maintain the number of packages I do without breaking things left and right twice a week.
At the very least, dnf5-repoquery will need to support the most common things from "dnf repoquery", otherwise things will be very broken in many people's packaging automation, release engineering scripts, etc.
- `dnf system-upgrade`
That also seems to be important ... Isn't "dnf system-upgrade" the "officially blessed" way of upgrading from one Fedora release to another on the command line?
I also need "dnf repoclosure" ... without it, I'd need to either completely reimplement or shut down the service that provides "broken dependencies" / fails-to-install data for the Fedora Packager Dashboard.
Fabio
Please can you be more specific which kind of functionality is required for particular command? Why is it important to know what user case you want to resolve it? Commands has multiple options and some of them could be unused. Specially repoquery has tons of options. Knowing critical usercase will help us a lot to not only provide the same option but to improve DNF5 behavior in comparison to DNF4.
I recommend to create for each user case or command an issue - https://github.com/rpm-software-management/dnf5/issues. Please provide as much as possible information to understand the user case to be able to set a proper priority.
On Mon, Oct 10, 2022 at 9:15 AM Jaroslav Mracek jmracek@redhat.com wrote:
Please can you be more specific which kind of functionality is required for particular command? Why is it important to know what user case you want to resolve it? Commands has multiple options and some of them could be unused. Specially repoquery has tons of options. Knowing critical usercase will help us a lot to not only provide the same option but to improve DNF5 behavior in comparison to DNF4.
I recommend to create for each user case or command an issue - https://github.com/rpm-software-management/dnf5/issues. Please provide as much as possible information to understand the user case to be able to set a proper priority.
Determining the scope of such big Changes is usually done by the person who proposes the change ... I think it's safe to assume that most commands / options are used by at least some people / tools / scripts, so dropping features is going to be painful, and should be avoided, if possible.
Fabio
On Tue, Oct 11, 2022 at 11:48:14AM +0200, Fabio Valentini wrote:
On Mon, Oct 10, 2022 at 9:15 AM Jaroslav Mracek jmracek@redhat.com wrote:
Please can you be more specific which kind of functionality is required for particular command? Why is it important to know what user case you want to resolve it? Commands has multiple options and some of them could be unused. Specially repoquery has tons of options. Knowing critical usercase will help us a lot to not only provide the same option but to improve DNF5 behavior in comparison to DNF4.
I recommend to create for each user case or command an issue - https://github.com/rpm-software-management/dnf5/issues. Please provide as much as possible information to understand the user case to be able to set a proper priority.
Determining the scope of such big Changes is usually done by the person who proposes the change ... I think it's safe to assume that most commands / options are used by at least some people / tools / scripts, so dropping features is going to be painful, and should be avoided, if possible.
Yes. And looking at this from the other angle: if you ask people what features they need, the answer will be "yes" ;) Essentially, pretty much every feature ever created has *some* user, and often people will only remember about a feature when it turns out that it is missing in the new implementation. Also, other things being equal, people prefer that the interface is unchanged. This just makes life easier for them.
Thus, if we're switching to an entirely new system where reimplementing every feature and interface of the old system is not possible, people proposing the change need to figure out what *can* be implemented, and weigh the efforts required against how needed the feature really is, propose alternatives for things which are too hard or too costly to reimplement, and in the end make some judgement calls. This exploratory and design work is hard, but without it things will be much harder later on.
Zbyszek
On Tue, Oct 11, 2022 at 7:13 AM Zbigniew Jędrzejewski-Szmek < zbyszek@in.waw.pl> wrote:
On Tue, Oct 11, 2022 at 11:48:14AM +0200, Fabio Valentini wrote:
On Mon, Oct 10, 2022 at 9:15 AM Jaroslav Mracek jmracek@redhat.com
wrote:
Please can you be more specific which kind of functionality is
required for particular command? Why is it important to know what user case you want to resolve it? Commands has multiple options and some of them could be unused. Specially repoquery has tons of options. Knowing critical usercase will help us a lot to not only provide the same option but to improve DNF5 behavior in comparison to DNF4.
I recommend to create for each user case or command an issue -
https://github.com/rpm-software-management/dnf5/issues. Please provide as much as possible information to understand the user case to be able to set a proper priority.
Determining the scope of such big Changes is usually done by the person who proposes the change ... I think it's safe to assume that most commands / options are used by at least some people / tools / scripts, so dropping features is going to be painful, and should be avoided, if possible.
Yes. And looking at this from the other angle: if you ask people what features they need, the answer will be "yes" ;) Essentially, pretty much every feature ever created has *some* user, and often people will only remember about a feature when it turns out that it is missing in the new implementation. Also, other things being equal, people prefer that the interface is unchanged. This just makes life easier for them.
I agree with you Zbyszek. OTOH "identical interface" doesn't seem like a fair requirement. (I don't believe you were suggesting it was.)
Thus, if we're switching to an entirely new system where
reimplementing every feature and interface of the old system is not possible, people proposing the change need to figure out what *can* be implemented, and weigh the efforts required against how needed the feature really is,
This sounds reasonable -- describe what will be provided at a minimum.
propose alternatives for things which are too hard or too costly to reimplement,
This sounds reasonable if all we're asking is to provide suggestions or alternatives for a few things that are more prominent changes. Not alternatives for every possible function. That would divert too much energy from more useful work.
and in the end make some judgement calls.
Are you suggesting the DNF team can make these calls? That sounds like a collegial level of trust and seems okay, if so. But it seems at odds with the original request, so it should be clear who's accountable for making what calls.
On Wed, Oct 12, 2022 at 05:21:58PM -0400, Paul Frields wrote:
On Tue, Oct 11, 2022 at 7:13 AM Zbigniew Jędrzejewski-Szmek < zbyszek@in.waw.pl> wrote:
On Tue, Oct 11, 2022 at 11:48:14AM +0200, Fabio Valentini wrote:
On Mon, Oct 10, 2022 at 9:15 AM Jaroslav Mracek jmracek@redhat.com
wrote:
Please can you be more specific which kind of functionality is
required for particular command? Why is it important to know what user case you want to resolve it? Commands has multiple options and some of them could be unused. Specially repoquery has tons of options. Knowing critical usercase will help us a lot to not only provide the same option but to improve DNF5 behavior in comparison to DNF4.
I recommend to create for each user case or command an issue -
https://github.com/rpm-software-management/dnf5/issues. Please provide as much as possible information to understand the user case to be able to set a proper priority.
Determining the scope of such big Changes is usually done by the person who proposes the change ... I think it's safe to assume that most commands / options are used by at least some people / tools / scripts, so dropping features is going to be painful, and should be avoided, if possible.
Yes. And looking at this from the other angle: if you ask people what features they need, the answer will be "yes" ;) Essentially, pretty much every feature ever created has *some* user, and often people will only remember about a feature when it turns out that it is missing in the new implementation. Also, other things being equal, people prefer that the interface is unchanged. This just makes life easier for them.
I agree with you Zbyszek. OTOH "identical interface" doesn't seem like a fair requirement. (I don't believe you were suggesting it was.)
I wasn't. An identical interface (or part thereof) is in fact often easiest for both sides, both people writing the interface and people consuming the interface. But in various cases it's too hard to provide an identical interface. Thus: try to provide an identical or at least a backwards-compatible interface, but deviate if necessary.
Thus, if we're switching to an entirely new system where reimplementing every feature and interface of the old system is not possible, people proposing the change need to figure out what *can* be implemented, and weigh the efforts required against how needed the feature really is,
This sounds reasonable -- describe what will be provided at a minimum.
propose alternatives for things which are too hard or too costly to reimplement,
This sounds reasonable if all we're asking is to provide suggestions or alternatives for a few things that are more prominent changes. Not alternatives for every possible function. That would divert too much energy from more useful work.
Well, maybe. I think some such answer will need to be provided for pretty much every feature that people ask about. Maybe not at level of all implementation details, but at the feature level certainly.
and in the end make some judgement calls.
Are you suggesting the DNF team can make these calls? That sounds like a collegial level of trust and seems okay, if so. But it seems at odds with the original request, so it should be clear who's accountable for making what calls.
I think the DNF team should make those calls but then submit the resulting plan for public discussion and vote by FESCo.
Zbyszek
I agree.
The thread was created by community to ask community what should be the minimal scope to approve the change proposal. As a DNF team lead I would be very happy to get any input from community, because it will help us to prioritize tasks.
Jaroslav
On 10/10/22 10:15, Jaroslav Mracek wrote:
Please can you be more specific which kind of functionality is required for particular command? Why is it important to know what user case you want to resolve it? Commands has multiple options and some of them could be unused. Specially repoquery has tons of options. Knowing critical usercase will help us a lot to not only provide the same option but to improve DNF5 behavior in comparison to DNF4.
I recommend to create for each user case or command an issue - https://github.com/rpm-software-management/dnf5/issues. Please provide as much as possible information to understand the user case to be able to set a proper priority.
The mission of repoquery is basically to provide scriptable access to all available repository metadata. That necessarily involves helluva many switches, added over time to address all manner of use-cases. Don't assume anything is there just for giggles.
- Panu -
On Tue, 11 Oct 2022 at 07:54, Panu Matilainen pmatilai@redhat.com wrote:
On 10/10/22 10:15, Jaroslav Mracek wrote:
Please can you be more specific which kind of functionality is required
for particular command? Why is it important to know what user case you want to resolve it? Commands has multiple options and some of them could be unused. Specially repoquery has tons of options. Knowing critical usercase will help us a lot to not only provide the same option but to improve DNF5 behavior in comparison to DNF4.
I recommend to create for each user case or command an issue -
https://github.com/rpm-software-management/dnf5/issues. Please provide as much as possible information to understand the user case to be able to set a proper priority.
The mission of repoquery is basically to provide scriptable access to all available repository metadata. That necessarily involves helluva many switches, added over time to address all manner of use-cases. Don't assume anything is there just for giggles.
Maybe it makes sense to put it just as a dedicated command like I thought it was until 'recently (*cough* sorry N years ago *cough*)'.
On 10/11/22 15:17, Stephen Smoogen wrote:
On Tue, 11 Oct 2022 at 07:54, Panu Matilainen <pmatilai@redhat.com mailto:pmatilai@redhat.com> wrote:
On 10/10/22 10:15, Jaroslav Mracek wrote: > Please can you be more specific which kind of functionality is required for particular command? Why is it important to know what user case you want to resolve it? Commands has multiple options and some of them could be unused. Specially repoquery has tons of options. Knowing critical usercase will help us a lot to not only provide the same option but to improve DNF5 behavior in comparison to DNF4. > > I recommend to create for each user case or command an issue - https://github.com/rpm-software-management/dnf5/issues <https://github.com/rpm-software-management/dnf5/issues>. Please provide as much as possible information to understand the user case to be able to set a proper priority. The mission of repoquery is basically to provide scriptable access to all available repository metadata. That necessarily involves helluva many switches, added over time to address all manner of use-cases. Don't assume anything is there just for giggles.
Maybe it makes sense to put it just as a dedicated command like I thought it was until 'recently (*cough* sorry N years ago *cough*)'.
Yup. There were more than one reason for it to be a dedicated utility originally.
- Panu -
On Wed, Oct 05, 2022 at 09:20:47PM -0500, 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.
Is there a way to test it? This didn't work:
# dnf install dnf5 Last metadata expiration check: 0:52:30 ago on Thu 06 Oct 2022 13:00:16 BST. No match for argument: dnf5 Error: Unable to find a match: dnf5
Anyway, as previously mentioned "dnf5 download" should work as for dnf, and especially must not require root privileges.
Rich.
On Thu, 2022-10-06 at 13:53 +0100, Richard W.M. Jones wrote:
On Wed, Oct 05, 2022 at 09:20:47PM -0500, 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.
Is there a way to test it? This didn't work:
# dnf install dnf5 Last metadata expiration check: 0:52:30 ago on Thu 06 Oct 2022 13:00:16 BST. No match for argument: dnf5 Error: Unable to find a match: dnf5
Anyway, as previously mentioned "dnf5 download" should work as for dnf, and especially must not require root privileges.
Rich.
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
It's in a COPR.
sudo dnf copr enable rpmsoftwaremanagement/dnf5-unstable