On Tue, Jan 19, 2016 at 6:03 PM, Paul Eggleton <[email protected]> wrote: > On Tue, 19 Jan 2016 13:01:20 Ulf Magnusson wrote: >> On Tue, Jan 19, 2016 at 10:20 AM, Paul Eggleton >> >> <[email protected]> wrote: >> > On Tue, 19 Jan 2016 08:31:09 Ulf Magnusson wrote: >> >> On Mon, Jan 18, 2016 at 9:15 PM, Paul Eggleton >> >> >> >> <[email protected]> wrote: >> >> > On Mon, 18 Jan 2016 10:56:41 Ulf Magnusson wrote: >> >> >> To support an in-house packaging format, we need to partition the root >> >> >> filesystem into a number of packages (called "internal packages" from >> >> >> here on to avoid confusion), where each internal package corresponds >> >> >> to a number of (e.g. IPK) packages. >> >> >> >> >> >> The way this is currently done is by manually maintaining a database >> >> >> (implemented as a PACKAGE_CLASSES class) that maps files in the root >> >> >> filesystem back to packages, along with a list of what packages should >> >> >> go into each internal package. I suspect it is done this way so that >> >> >> post-processing steps on the root filesystem will be included in the >> >> >> internal packages. >> >> >> >> >> >> To me this feels pretty roundabout, and I suspect that there are much >> >> >> nicer solutions (suggestions welcome!). What I'm mostly curious about >> >> >> at the moment though is whether there's some nicer way to map files >> >> >> from the root filesystem back to packages, without having to maintain >> >> >> a separate database. Having the method be independent of the package >> >> >> format (e.g., IPK) would be a bonus, though I'm not sure if it's a >> >> >> strict requirement. >> >> > >> >> > So, aside from the "internal package" concept, there are two ways to do >> >> > this: >> >> > >> >> > 1) oe-pkgdata-util find-path - this will tell you the build-time >> >> > package >> >> > name that provided the specified path within the image (expects a full >> >> > path, wildcards allowed). It also provides some other lookup tools. >> >> > Note >> >> > that this relies on pkgdata so it'll only work for a particular recipe >> >> > after that recipe has been packaged. >> >> > >> >> > 2) Use the Toaster web UI - it allows you to browse through the image >> >> > and >> >> > click through from any file back to the package that contained it. >> >> >> >> Thanks for the hint! >> >> >> >> Do you have any suggestions for the other direction as well, i.e., >> >> mapping packages to files, preferably in a way that's independent of >> >> the packaging format? >> > >> > You'd use the same mechanisms - both of the above options will let you >> > look up a package and then its contents. >> >> Could you provide an example for getting package contests via >> oe-pkgdata-util? I tried >> >> $ oe-pkgdata-util read-value >> tmp/sysroots/i686-xs-baytrail-hmgua1/pkgdata/ FILES_INFO busybox >> {"/bin/busybox.nosuid" >> >> , but as seen from the output, that only gives part of the string after the >> FILES_INFO key in pkgdata/runtime/busybox before the first space. I'm not >> sure if that's the right key to use either. > > Ah, you must be using the version before we fixed that bug. In later versions > we have a "list-pkg-files" command - you can supply it with a package name or > -p recipename; additionally you no longer have to supply the pkgdata path. > > Cheers, > Paul
That must be it. We're currently using 1.8, but are in the process of upgrading to 2.1. Thanks for the hint! Cheers, Ulf -- _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
