Could we add the following section to the reference manual? I've seen many people wonder how to list package contents. The oe-pkgdata-util utility is currently undocumented, and the bb utility very hard to discover, so getting some coverage for those is nice too. 2.3.4. Listing package contents Listing the files inside a package can be a useful debugging aid. Below are a few different ways to do it. 1. Build the recipe that generates the package and then run the following command: $ oe-pkgdata-util list-pkg-files <package> If you are unsure what the name of the package is, the following command will list all packages for which package information is available: $ oe-pkgdata-util list-pkgs You can also search for packages using wildcards. For example, the following command lists all package names starting with "foo": $ oe-pkgdata-util list-pkgs "foo*" oe-pkgdata-util lives in the scripts/ directory under the [Source Directory]. 2. Install the 'bb' utility from https://github.com/kergoth/bb. This utility has a 'contents' subcommand that can be used to list the contents of all packages generated by a given recipe. Like with oe-pkgdata-util, the recipe must be built before package contents can be listed. Also make sure that you do not have [rm_work](http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#ref-classes-rm-work) enabled, as this will remove needed information. 3. List the contents of the ${WORKDIR}/packages-split directory for the recipe that generates the package. This directory has one subdirectory per package generated by the recipe, containing the files stored in that package. Make sure that you have built the recipe first and are not running with rm_work enabled. 4. Finally, it is always possible to directly inspect the generated packages in ${DEPLOY_DIR_IPK}, ${DEPLOYR_DIR_RPM}, etc. How this is done depends on the packaging format. Cheers, Ulf
'bb' isn't part of official releases, thus I don't think it should be part of the manual. If we had no alternative for this use case that was part of the official release there would be a good case to document it, but that's not true here.
Set up some parameters so the bug is not flagged later for me as missing target and time.
(In reply to comment #1) > 'bb' isn't part of official releases, thus I don't think it should be part > of the manual. If we had no alternative for this use case that was part of > the official release there would be a good case to document it, but that's > not true here. I think it's useful enough (in relation to manual spaminess :) to be worth mentioning, even if it's third-party. Removing that bullet isn't a huge deal though. Cheers, Ulf
FWIW what I'm concerned about with bb is that the user might try to use it and it doesn't work because something changed in the current release that broke it. For a concrete example, if my reworking of tinfoil goes in for this release it will definitely break bb. Chris may well fix it up immediately, but I don't know if that's guaranteed.
If this is documented, it would probably be better placed in the "Working with Packages" section in the development manual, which tries to be procedural, rather than the reference manual, which tries to be a reference. We could reference the procedure section from within the debugging section of the reference manual. Scott
(In reply to comment #4) > FWIW what I'm concerned about with bb is that the user might try to use it > and it doesn't work because something changed in the current release that > broke it. For a concrete example, if my reworking of tinfoil goes in for > this release it will definitely break bb. Chris may well fix it up > immediately, but I don't know if that's guaranteed. I'm fine with leaving it out in that case. If it's worthwhile, it could always be added later. Cheers, Ulf
(In reply to comment #5) > If this is documented, it would probably be better placed in the "Working > with Packages" section in the development manual, which tries to be > procedural, rather than the reference manual, which tries to be a reference. > We could reference the procedure section from within the debugging section > of the reference manual. > > Scott I'm fine with moving it. Placing it under Debugging Build Failures felt like a bit of a stretch to begin with. Cheers, Ulf
If it's moved, the opening sentence could be rewritten like this: While working on a recipe, it can be useful to see what files are in packages produced by the recipe. Below are a few different methods for listing the contents of a package. Cheers, Ulf
Hello, Here's an updated version that removes the mention of 'bb' and adds some information. I think it would fit pretty well under '2.3. Debugging Tools and Techniques' now, after it was renamed from '2.3. Debugging Build Failures'. There is already a bunch of sections on viewing different kinds of recipe- and package-related information, so this would just be another one. Finally getting some documentation for oe-pkgdata-util would be nice too. :) 2.3.4. Viewing package contents Listing the files inside a package can be a useful debugging aid. Below are a few different ways to do it. 1. Build the recipe that generates the package and then run the following command: $ oe-pkgdata-util list-pkg-files <package> If you are unsure what the name of the package is, the following command will list all packages for which package information is available: $ oe-pkgdata-util list-pkgs You can also search for packages using wildcards. For example, the following command lists all package names starting with "foo": $ oe-pkgdata-util list-pkgs "foo*" oe-pkgdata-util uses information from [PKGDATA_DIR]. 2. List the contents of the ${WORKDIR}/packages-split directory for the recipe that generates the package. This directory is created by the [do_package] task and has one subdirectory per package generated by the recipe, containing the files stored in that package. Make sure that you have built the recipe first and that you are not running with [rm_work](http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#ref-classes-rm-work) enabled. 3. Finally, it is always possible to directly inspect the generated packages in ${DEPLOY_DIR_IPK}, ${DEPLOYR_DIR_RPM}, etc. How this is done depends on the packaging format. Cheers, Ulf
Here's a slightly updated version. All packages that have been built should have package information available, so the list-pkgs description was changed to be more concrete. 2.3.4. Viewing package contents Listing the files inside a package can be a useful debugging aid. A few different ways to do it are listed below: 1. Build the recipe that generates the package and then run the following command: $ oe-pkgdata-util list-pkg-files <package> If you are unsure what the name of the package is, the following command will list all packages that have been built: $ oe-pkgdata-util list-pkgs You can also search for packages using wildcards. For example, the following command lists all package names starting with "foo": $ oe-pkgdata-util list-pkgs "foo*" oe-pkgdata-util uses information from [PKGDATA_DIR]. 2. List the contents of the ${WORKDIR}/packages-split directory for the recipe that generates the package. This directory is created by the [do_package] task and has one subdirectory per package generated by the recipe, containing the files stored in that package. Make sure that you have built the recipe first and that you are not running with [rm_work](http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#ref-classes-rm-work) enabled. 3. Finally, it is always possible to directly inspect the generated packages in ${DEPLOY_DIR_IPK}, ${DEPLOYR_DIR_RPM}, etc. How this is done depends on the packaging format. Cheers, Ulf
Hello, I thought about it some more, and I think it would be better to have a section about oe-pkgdata-util more generally. Here's a bug I filed for that: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10216 That bug would replace this one completely.
Yes - I put the Bug 10216 out for review. Check that. I am marking this as RESOLVED/MOVED since there is a new bug for it. Scott
Forgot to reset the doc flag to "No" Scott