9:20 p.m.
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
10:10 p.m.
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
10:35 p.m.
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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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.
8:32 a.m.
On Thu, Oct 6, 2022 at 5:11 AM Maxwell G via devel
<devel(a)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
2:15 a.m.
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.
4:48 a.m.
On Mon, Oct 10, 2022 at 9:15 AM Jaroslav Mracek <jmracek(a)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
6:13 a.m.
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(a)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
4:21 p.m.
On Tue, Oct 11, 2022 at 7:13 AM Zbigniew Jędrzejewski-Szmek <
zbyszek(a)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(a)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.
--
Paul
6:39 a.m.
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(a)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(a)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
5:18 a.m.
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
6:36 a.m.
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 -
7:17 a.m.
On Tue, 11 Oct 2022 at 07:54, Panu Matilainen <pmatilai(a)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*)'.
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
7:34 a.m.
On 10/11/22 15:17, Stephen Smoogen wrote:
On Tue, 11 Oct 2022 at 07:54, Panu Matilainen <pmatilai(a)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 -
7:53 a.m.
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
8:32 a.m.
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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
563
days inactive
574
days old
14 comments
9 participants
participants (9)
-
Fabio Valentini -
Jaroslav Mracek -
Maxwell G -
Panu Matilainen -
Paul Frields -
Richard W.M. Jones -
Stephen Smoogen -
Tommy Nguyen -
Zbigniew Jędrzejewski-Szmek