Bug 1208773 - [RFE] Define virtual provides for DNF commands and suggest installing the appropriate one if a command was not found
[RFE] Define virtual provides for DNF commands and suggest installing the app...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
22
Unspecified Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Honza Silhan
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: 1208650
  Show dependency treegraph
 
Reported: 2015-04-03 03:05 EDT by Jan Kratochvil
Modified: 2015-05-30 11:56 EDT (History)
6 users (show)

See Also:
Fixed In Version: dnf-plugins-extras-0.0.8-1.fc22
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-05-08 03:27:10 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jan Kratochvil 2015-04-03 03:05:51 EDT
Description of problem:
When I want to run some plugin functionality I get an error but no clue how to fix that.  One has to start investigating with 'dnf search', 'dnf install' etc. while the original user's goal was unrelated to packages.

Version-Release number of selected component (if applicable):
dnf-0.6.4-2.fc22.noarch

How reproducible:
Always.

Steps to Reproduce:
dnf debuginfo-install zip-3.0-13.fc22.x86_64

Actual results:
No such command: debuginfo-install. Please use /usr/bin/dnf --help
It could be a DNF plugin command.

Expected results:
dnf install /usr/lib/python2.7/site-packages/dnf-plugins/debuginfo-install.py

Additional info:
Maybe it could even run that 'install' command when it is already dnf itself - and re-execute the command afterwards.
Comment 1 Parag Nemade 2015-04-03 03:28:04 EDT
It looks like your installation missed dnf-plugins-core package. I see its already marked as default in comps so it should have been installed on your system.
Comment 2 Jan Kratochvil 2015-04-03 03:35:34 EDT
(1) I use installation by mock where it is not installed by default.
    On iron I use minimal installation where it also would not be installed.
(2) comps does not help for all the dnf-plugins-extras* subpackages.
Comment 3 Radek Holy 2015-04-03 05:18:57 EDT
OK, I see that you know that there are community packages that can add commands to DNF and DNF might have no clue about them. So, what is your suggestion? To treat dnf-plugins-core differently (aka hardcode their command names in DNF) and suggest installation of the concrete package or even install it immediately? Or have a DNF command that can guess which package adds the given command? Or use some virtual provides to easily find them?

We did our best. You've marked the work useless. So I'd expect that you have an idea how to do it better.
Comment 4 Jan Kratochvil 2015-04-03 05:23:26 EDT
(In reply to Radek Holy from comment #3)
> OK, I see that you know that there are community packages that can add
> commands to DNF and DNF might have no clue about them. So, what is your
> suggestion? To treat dnf-plugins-core differently (aka hardcode their
> command names in DNF) and suggest installation of the concrete package or
> even install it immediately? Or have a DNF command that can guess which
> package adds the given command?
+
> So I'd expect that you have an idea how to do it better.

I have said:
(Jan Kratochvil from comment #0)
# Expected results:
# dnf install /usr/lib/python2.7/site-packages/dnf-plugins/debuginfo-install.py


> Or use some virtual provides to easily find them?

That may be even better.

> We did our best. You've marked the work useless.

Sorry for "not helpful", fixed.
Comment 5 Radek Holy 2015-04-03 05:40:01 EDT
The problem is that I can imagine another user who wanted to run "dnf clean" but did a typo and run "dnf cleann". In that case, DNF would start refreshing metadata and searching through all the provides (or even through all the package files - or even through all the files of the packages if we wouldn't use the virtual provides) to find out that the user made just a typo. Well, unless we hardcode a mapping from some known commands to the appropriate packages which is not something I'd be proud of.

Would it be enough for you if DNF would print also a command that would help you to find the plugin? But because of the reasons above I think that DNF shouldn't print a concrete file name / package name (it doesn't know it and the cost of finding it is very high).
Comment 6 Radek Holy 2015-04-03 05:42:19 EDT
(In reply to Radek Holy from comment #5)
> (or even through all the package files
* (or even through all the file provides
Comment 7 Jan Kratochvil 2015-04-03 05:48:36 EDT
(In reply to Radek Holy from comment #5)
> The problem is that I can imagine another user who wanted to run "dnf clean"
> but did a typo and run "dnf cleann". In that case, DNF would start
> refreshing metadata

You reply to the part (b):
  Maybe it could even run that 'install' command 
But the part (a) was just to print:
  dnf install /usr/lib/python2.7/site-packages/dnf-plugins/XXX.py

For the part (b) - if dnf does that then it is a bug, yum had "metadata_expire=never" (although not by default), it is default on Debian.  Metadata should be updated in the background (does dnf-automatic do that?).


> Well, unless we hardcode a mapping from some known commands to the
> appropriate packages which is not something I'd be proud of.

I also think that would do more harm than good.


> Would it be enough for you if DNF would print also a command that would help
> you to find the plugin?

That is what I asked for in the Comment 0.


> But because of the reasons above I think that DNF
> shouldn't print a concrete file name / package name (it doesn't know it and
> the cost of finding it is very high).

Concrete file name should be easy - what is the problem with /usr/lib/python2.7/site-packages/dnf-plugins/XXX.py ?
Concrete package name in fact should be also easy as metadata should be already cached; but I do not think it is needed, suggested 'dnf install ...' command works both for a filename and for a package name.
Comment 8 Radek Holy 2015-04-03 06:07:44 EDT
(In reply to Jan Kratochvil from comment #7)
> (In reply to Radek Holy from comment #5)
> For the part (b) - if dnf does that then it is a bug, yum had
> "metadata_expire=never" (although not by default), it is default on Debian. 
> Metadata should be updated in the background (does dnf-automatic do that?).

Well, I meant in the worst case... E.g. if the metadata have expired exactly in that moment or if the user have just installed DNF or if they have just run "dnf clean"...

> > Would it be enough for you if DNF would print also a command that would help
> > you to find the plugin?
> 
> That is what I asked for in the Comment 0.
> 
[...]
> 
> Concrete file name should be easy - what is the problem with
> /usr/lib/python2.7/site-packages/dnf-plugins/XXX.py ?
> Concrete package name in fact should be also easy as metadata should be
> already cached; but I do not think it is needed, suggested 'dnf install ...'
> command works both for a filename and for a package name.

The problem is that the mapping from command name to the file name is not always 1:1. In theory, the files sometimes must have different name than the commands specified there (e.g. "config-manager") or even one file can specify multiple commands.

It means that in the worst case, DNF has no clue which file provides which command.
Comment 9 Jan Kratochvil 2015-04-03 06:11:24 EDT
(In reply to Radek Holy from comment #8)
> It means that in the worst case, DNF has no clue which file provides which
> command.

So DNF project should either make a requirement for plugin commands<->source files naming or DNF project should make a requirement for plugin virtual provides.
Comment 10 Radek Holy 2015-04-03 06:47:56 EDT
Yes. And the file naming requirement could not be fulfilled by the mentioned "config-manager" plugin so the only remaining variant is using the virtual provides that is actually something I'd really like to have.

But the problem with expired/non-existent metadata is still not solved. So, I think that we can resolve this RFE by:
1) printing also something like "If you are lucky, `dnf install dnf-command(foo) can find the missing plugin for you." and
2) suggesting in the documentation to define these virtual provides in the plugin packages.
Comment 11 Honza Silhan 2015-04-07 13:16:29 EDT
This was already discussed in bug 1132335. We have each plugin name in dnf-plugins-core/extras description so `dnf search` finds it. We could extend the message to "It could be a DNF plugin command. Try `dnf search <arg>`".
Comment 12 Radek Holy 2015-04-08 02:03:34 EDT
OH, I forgot...
Comment 13 Jan Kratochvil 2015-04-08 02:18:08 EDT
(In reply to Jan Kratochvil from comment #0)
> One has to start investigating with 'dnf search', 'dnf install' etc. while
> the original user's goal was unrelated to packages.

But we are back to the Comment 0.  It is obvious one can use 'dnf search' but one has to check its results, copy-paste it to 'dnf install', re-run the original debuginfo-install command and only then return back to the debugging.  User's goal is not to install packages, that is only a technical obstacle.

OT: Printing the debuginfo command from GDB is not right - it should execute it (after a confirmation by user).  The problem is that there are various GUI frontends and there has never been an alternatives way how to execute 'install' command with the preferred package manager frontend.
Comment 14 Radek Holy 2015-04-08 03:10:23 EDT
Then I could repeat the Comment 5... OK, let's not repeat ourselves...

So, if DNF cannot install the missing plugin *by default* and the virtual provides are not worth implementing in this case and the suggested improvement of the printed suggestion is not acceptable for you, we could probably close this as a duplicate of the bug 1132335.

BUT! Let's focus on the use case. If it is about GDB, can GDB require "dnf-plugins-core" so that its users would never hit this issue?

Another solution we can come up with is a plugin that could implement the functionality.

BTW, dnf-plugins-core is in "comps" so it should be installed by default on Fedora.
Comment 15 Jan Kratochvil 2015-04-08 03:16:06 EDT
(In reply to Radek Holy from comment #14)
> BUT! Let's focus on the use case. If it is about GDB, can GDB require
> "dnf-plugins-core" so that its users would never hit this issue?

'requires' seems inappropriate but I have already prepared for next gdb.spec new 'recommends' for 'dnf-plugins-core'.  With missing virtual provides I would rather 'recommends: /usr/lib/python2.7/site-packages/dnf-plugins/debuginfo-install.py' but AFAIK file dependencies are discouraged (as dnf/yum then needs to download files index).

> BTW, dnf-plugins-core is in "comps" so it should be installed by default on
> Fedora.

Already replied by Comment 2.
Comment 16 Radek Holy 2015-04-08 03:31:55 EDT
(In reply to Jan Kratochvil from comment #15)
> With missing virtual provides I
> would rather 'recommends:
> /usr/lib/python2.7/site-packages/dnf-plugins/debuginfo-install.py' but AFAIK
> file dependencies are discouraged (as dnf/yum then needs to download files
> index).

DNF always downloads filelists (bug 968006) and I'd say that e.g. "Requires: /usr/bin/foo" is very common and welcome. Anyway, please note that DNF in rawhide uses Python 3 as the default so the path is slightly different and also it's by no means guaranteed that the file will never be renamed. Especially, in case of debuginfo-install.py, it's very likely that I'll rename it to debuginfo_install.py soon.
Comment 17 Jan Kratochvil 2015-04-08 03:37:29 EDT
(In reply to Radek Holy from comment #16)
> I'd say that e.g. "Requires: /usr/bin/foo" is very common and welcome.

/usr/bin/foo yes but /usr/lib/... not; otherwise you should fix:
https://fedoraproject.org/wiki/Packaging:Guidelines#File_Dependencies
Comment 18 Radek Holy 2015-04-09 03:27:14 EDT
Hello, good news, we unanimously agreed that all of us like the idea of the virtual provides so we've cancelled Ales' decision and we are going to implement it. So, I'd like to remind my suggestion in comment #10 which includes both an improvement of the message and of the documentation. And an improvement of our plugins should follow too of course.
Comment 19 Honza Silhan 2015-04-21 07:59:17 EDT
PR: [1] with modified message + added provides to all plugins with commands

[1] https://github.com/rpm-software-management/dnf/pull/260
Comment 20 Fedora Update System 2015-05-02 09:49:35 EDT
dnf-plugins-core-0.1.7-1.fc22,hawkey-0.5.5-1.fc22,dnf-1.0.0-1.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/dnf-plugins-core-0.1.7-1.fc22,hawkey-0.5.5-1.fc22,dnf-1.0.0-1.fc22
Comment 21 Fedora Update System 2015-05-03 13:24:33 EDT
Package dnf-plugins-core-0.1.7-1.fc22, hawkey-0.5.5-1.fc22, dnf-1.0.0-1.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dnf-plugins-core-0.1.7-1.fc22 hawkey-0.5.5-1.fc22 dnf-1.0.0-1.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-7483/dnf-plugins-core-0.1.7-1.fc22,hawkey-0.5.5-1.fc22,dnf-1.0.0-1.fc22
then log in and leave karma (feedback).
Comment 22 Fedora Update System 2015-05-08 03:27:10 EDT
dnf-plugins-core-0.1.7-1.fc22, hawkey-0.5.5-1.fc22, dnf-1.0.0-1.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 23 Fedora Update System 2015-05-22 13:26:37 EDT
dnf-plugins-extras-0.0.8-1.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/dnf-plugins-extras-0.0.8-1.fc22
Comment 24 Fedora Update System 2015-05-30 11:56:45 EDT
dnf-plugins-extras-0.0.8-1.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.