I was wondering if the following is possible to implement since it would be very useable.
For example I wan't to know which package I should install to get the 'lspci' command available. Maybe it seems very easy to remember that it is the 'pciutils' package but for me (I'm new to gentoo) it is definitly not.
It would be really great if some command like 'emerge --search_for_package_by_file lspci' could be used to get the string 'sys-apps/pciutils' as output.
I know that 'equery' can be used like this:
equery belongs lspci
[ Searching for file(s) lspci in *... ]
but this only works for installed packages.
Are you going to create/maintain a database of what files are installed by *every* ebuild with *every* USE combination? No? Would you expect someone else to? :)
Of course I would not :) However this would be great :) I know that it is kind of implemented in netbsd packages.. it is stored in a separate file in the package directory. Probably if every ebuild would have this info it would be simple to implement. In such case every ebuild creator would add this stuff into the ebuild... however You are right about all the USE combinations.
I close the issue because it is probably just to hard to implement.
Thanks for the clarification.
Here's an unofficial database:
Thank you very much for the hint. I reopen the issue and let the developers decide what to do with it.
In my opinion this unofficial db should be made official and emerge (or equery) should be able to use it if the user has internet connection available. This is just a couple of GET requests and a bit of parsing.. I guess the owner of the database would also like to create a simple soap/corba/whatever interface so things get simpler.
Thanks a lot once again.
We won't make any third-party unverified and pretty likely vastly incomplete database official without checking, and as said in Comment #1 - alas - noone volunteered... So, that's pretty much it.
The sheer complexity generated by combination of different arches, profiles, ebuilds, USE flags and FEATURES simply makes this impossible. And even less complete approaches would need too much maintenance to make this somewhat usable, so I dont think this is going to happen anytime soon.
Ok. I understand. Isuue closed.
Thanks for the information.