Bug 11843

Summary:	RPM package feed layout doesn't match the documentation or target feed setup
Product:	[Runtime] Package Management Issues	Reporter:	Kai Ruhnau <kai.ruhnau>
Component:	RPM	Assignee:	Kai Ruhnau <kai.ruhnau>
Status:	RESOLVED NOTABUG	QA Contact:
Severity:	normal
Priority:	Medium	CC:	alex.kanavin, mark.hatle, randy.macleod
Version:	2.3.1
Target Milestone:	2.4
Hardware:	All
OS:	Multiple
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	Yes (doc changes required)

Description Kai Ruhnau 2017-07-27 09:09:56 UTC

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.

Comment 1 Mark Hatle 2017-07-27 13:10:34 UTC

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.

Comment 2 Mark Hatle 2017-07-27 13:11:38 UTC

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.

Comment 3 Alexander Kanavin 2017-07-27 14:02:45 UTC

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.

Comment 4 Kai Ruhnau 2017-07-27 14:53:08 UTC

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.

Comment 5 Alexander Kanavin 2017-07-28 13:34:24 UTC