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.
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.
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.
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.
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.
-