Bug 1208773

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.

(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.

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.

(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.

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).

(In reply to Radek Holy from comment #5)
> (or even through all the package files
* (or even through all the file provides

(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.

(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.

(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.

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.

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>`".

OH, I forgot...

(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.

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.

(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.

(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.

(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

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.

PR: [1] with modified message + added provides to all plugins with commands

[1] https://github.com/rpm-software-management/dnf/pull/260

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

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).

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.

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

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.