11843 2017-07-27 09:09:56 +0000 RPM package feed layout doesn't match the documentation or target feed setup 2017-07-28 13:34:24 +0000 1 1 11 Runtime Package Management Issues RPM 2.3.1 All Multiple RESOLVED NOTABUG Medium normal 2.4 1 kai.ruhnau kai.ruhnau alex.kanavin mark.hatle randy.macleod --- --- Yes (doc changes required) oldest_to_newest 75331 0 kai.ruhnau 2017-07-27 09:09:56 +0000 I have set up the build environment according to the documentation for RPM package management. There's a bunch of packages in tmp/depoly/rpm/*/*.rpm after the build. I've also set up the package feed generation by setting up the PACKAGE_FEED_URIS, PACKAGE_FEED_BASE_PATHS and PACKAGE_FEED_ARCHS variables. The latter is set to contain the names of the three folders in tmp/deploy/rpm. The built image then contains a /etc/yum.repos.d/oe-remote-repo-rpm.repo with three sections for the three feeds, and when I run `dnf upgrade` on the target, it queries the remote as expected for example for /rpm/cortexa9hf_neon/repodata/repomd.xml However, running `bitbake package-index` on the build system doesn't create the three expected repodata folders, but instead generates just one tmp/deploy/rpm/repodata/ folder that contains information combined for all three arches at once. The same setup with Morty generates a consistent layout (with three repodata folders) between the built package-index and the image configuration. 75336 1 mark.hatle 2017-07-27 13:10:34 +0000 I believe the newer environment moved to a single index. I prefer the three indexes myself as they allow me to combine different builds/architectures into the same 'release set' and then configure the user of the feed with the right ones to use. Assigning to Alexander as he has taken over this work. 75337 2 mark.hatle 2017-07-27 13:11:38 +0000 I forgot to mention, you can still get the older behavior by running createrepo-c yourself. It just means that you have to manually do what the package-index target does with the raw commands. 75339 3 alex.kanavin 2017-07-27 14:02:45 +0000 Createrepo_c is capable of recursing into subdirectories, and I utilized that feauture to avoid having to deal with architectures altogether when building images. The old smartpm-based code that handled them was basically impenetrable. To make this new behaviour compatible with the remote feed setup, drop the PACAKGE_FEED_ARCHS setting, and you should get a repo config that matches what the indexer does. If you want per-arch indexes, write a recipe that iterates over directories and calls createrepo on each of them - the helper classes are all available to use in meta/lib/oe/package_manager.py. 75344 4 kai.ruhnau 2017-07-27 14:53:08 +0000 I had tried setting PACKAGE_FEED_ARCHS to the empty string "". This resulted in an empty oe-remote-repo-rpm.repo. When it's unset, the generated package feed configuration looks good, indeed. 75390 5 alex.kanavin 2017-07-28 13:34:24 +0000 -