10066 2016-08-02 20:04:14 +0000 Suggested new section on listing package contents 2016-09-07 21:02:53 +0000 1 1 9 Documentation Reference handbook 2.2 x86 Multiple RESOLVED MOVED 07 Sept 2016: RESOLVED/MOVED Medium enhancement 2.2 M4 1 ulfalizer srifenbark bluelightning poky.doc.watcher poky.watcher sgw srifenbark --- --- No (bug/feature does not impact docs) oldest_to_newest 64795 0 ulfalizer 2016-08-02 20:04:14 +0000 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 64803 1 bluelightning 2016-08-02 20:34:52 +0000 '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. 64805 2 srifenbark 2016-08-02 20:40:45 +0000 Set up some parameters so the bug is not flagged later for me as missing target and time. 64806 3 ulfalizer 2016-08-02 20:45:01 +0000 (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 64809 4 bluelightning 2016-08-02 20:49:49 +0000 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. 64810 5 srifenbark 2016-08-02 20:51:36 +0000 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 64811 6 ulfalizer 2016-08-02 20:53:03 +0000 (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 64812 7 ulfalizer 2016-08-02 20:55:01 +0000 (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 64814 8 ulfalizer 2016-08-02 21:00:09 +0000 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 65763 9 ulfalizer 2016-09-02 10:13:40 +0000 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 65764 10 ulfalizer 2016-09-02 10:22:01 +0000 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 65786 11 ulfalizer 2016-09-03 15:17:14 +0000 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. 65890 12 srifenbark 2016-09-07 21:01:03 +0000 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 65891 13 srifenbark 2016-09-07 21:02:53 +0000 Forgot to reset the doc flag to "No" Scott