If we had a way to know which recipe(s) resulted in a given package, we could build a search that followed this type of path: libxml2mod -> libxml2-python-2.9.4-r0.corei7_64.rpm -> libxml2_2.9.4.bb This would help with two pain points (possibly more): 1. Quickly finding a recipe that contains a library I want to install 2. Traceability (Why is this library on my image?) This search would be similar to rpmfind built from autobuilder rpm repo data. It would, however, require this type of information be included in the RPM metadata.
adding joshua as it is a infrastructure play.
Can we clarify the goal here? Is it trying to help users find a recipe that produces the output they want to add to their image? We have oe-pkgdata-util that can answer these types of queries based on the PKGDATA generated during builds (i.e. tmp/pkgdata). For example: $ oe-pkgdata-util find-path /usr/lib/libxml2.so.2 libxml2: /usr/lib/libxml2.so.2 $ oe-pkgdata-util lookup-recipe libxml2-python libxml2 it's not a complete solution as it requires a path rather than just the name of a file, for example just searching for libxml2mod doesn't work: $ oe-pkgdata-util find-path libxml2mod ERROR: Unable to find any package producing path libxml2mod $ oe-pkgdata-util find-path libxml2mod.so ERROR: Unable to find any package producing path libxml2mod.so This may be a reasonable enhancement for oe-pkgdata-util? Presumably the infrastructure piece is that we want a shared web-based interface that a user can use to lookup this information?
The main goal is that people developing / compiling on the target will run into errors like: checking for bats... no configure: error: Please install bats We want them to expedite the process of solving this dependency given that small amount of error text. I can see this being a web-based interface, similar to rpmfind.
The intent of this was to effectively mine and make searchable the data generated by the autobuilder builds. Since the autobuilder has a wealth of built package data, it would be nice to be able to search it to figure out what I might want to build. oe-pkgdata-util provides some of this (though enabling a regex search would be nice), but it requires a completed local build. It would be nice to do the equivalent on a site based on the autobuilder build data. There are some extensions we would probably need to oe-pkgdata-util as well. For example, If i want libcow.so, sometimes it is obvious what recipe I need to build, sometimes it is not.... It looks like we may be able to do everything with a slightly enhanced (maybe?) oe-pkgdata-util + something like lucene? Thus obviating the need to include metadata in the RPMS.
We don't have public package feeds so adding the data to rpm doesn't really help us. There is such a field already in ipks. In modern terms a way to solve this may be to extend the layer index with optional supplementary information about the output from a given recipe. We'd then have a web searchable UI for this kind of data which is what is being requested.
Bulk move from 4.99 or 0.00 to 5.99
Closing as this is vague. The pkgdata (and thus oe-pkgdata-util) has the metadata, so in a local build you can search around. On target, at least opkg and rpm files contain the name of the recipe (albeit mangled in the Source RPM field for .rpms) which gives you more context, although pkgdata also knows the target package names too. There are other bugs for "we need packages.debian.org for yocto".