The function that "bitbake package-index" relies upon when using the RPM
package backend (package_update_index_rpm()) uses MULTILIB_PREFIX_LIST
to get the list of package architectures to be indexed, but that
variable is only set when populate_sdk_rpm or rootfs_rpm are inherited,
which is not the case for the package-index recipe. Until we're able to
refactor this properly, for minimal impact just use the value of
ALL_MULTILIB_PACKAGE_ARCHS if MULTILIB_PREFIX_LIST does not give us any
architectures (the equivalent function in the ipk backend uses the
former variable).

Having "bitbake package-index" working is important because it's the
only practical way of indexing RPM packages for use as a feed; host
versions of createrepo won't work properly because they won't support
indexing recommends relationships.

Stopgap fix for [YOCTO #5278].

(From OE-Core rev: 9359719c563e1ab0ff10186d1a1b6bde7840dbf3)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

1, In bitbake.conf
   PKGR ?= "${PR}${EXTENDPRAUTO}"
   EXTENDPKGV ?= "${EXTENDPKGEVER}${PKGV}-${PKGR}"
   RDEPENDS_${PN}-dev = "${PN} (= ${EXTENDPKGV})"

2, When PR Server is enabled, EXTENDPRAUTO is not none which means PKGR and PR
don't have the same value.

3, When multilib is enabled, RDEPENDS_${PN}-dev is not expanded correctly
which uses PR rather than PKGR in the versioned dependency string.

4, Make sure PKGR rather than PR in version string when do_package_rpm.

[YOCTO #4050]

Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

This fixes build failures introduced with "classes/buildhistory: implement history
collection for SDK" by moving the functions to files where only the specific image
type which is enabled is inherited. The failures occured when multiple PACKAGE_CLASSES
were enabled.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

SDKs are constructed in a similar manner to images, and the contents can
be influenced by a number of different factors, thus tracking the
contents of produced SDKs when buildhistory is enabled can help detect
the same kinds of issues as with images.

This required adding POPULATE_SDK_POST_HOST_COMMAND and
SDK_POSTPROCESS_COMMAND variables so that data collection functions can
be injected at the appropriate points in the SDK construction process,
as well as moving the list_installed_packages and
rootfs_list_installed_depends functions from the rootfs_{rpm,ipk,deb} to
the package_{rpm,ipk,deb} classes so they can also be called during
do_populate_sdk as well as do_rootfs.

Implements [YOCTO #3964].

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

The tclibc file for uclibc already empties IMAGE_LINGUAS, so there's no point
to this conditional as far as I can tell, and it can cause issues for certain
values of TARGET_OS.

Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

The previous change to this function fixed one manipuation at
the expense of the other, depending on ow expanded the versioned
dependency string was when the AUTOINC substitution was made.

This update ensures we cover both cases and ensures the classextended
version works as as well as the normal case.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

If a recipe has versioned dependencies on another package within
the same recipe, there are potentially races where the version
remapping may not happen correctly.

This issue triggered with neard in multilib builds since it
uses a "-" character in its PV which is illegal in an rpm version
field. The remapping to "+" was not occuring.

It only triggers in the multilib case since in this case, expansion
of the datastore happens at slightly different points.

The correct fix is to search for PV, not PKGV but substitute the
PV value.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Currently the process for injecting the per file rpm dependencies into
rpmbuild is painfully slow. Its done through the repeated execution of
a script which has to return the correct value in each case. This continual
execution means the CPU usage of rpmbuild is low.

This patch allows the option of collapsing the per file dependencies to
a per package basis and injecting them through the .spec file. This removes
the execution overhead and allows rpmbuild to run at 100% of cpu.

Ultimately it would be nice to inject the per file dependencies through
the .spec file however that is not currently possible.

Since few people use the per file dependency information, this patch
goes for the faster approach. It can be enabled if anyone needs it although
I'd mention that its being used to us as this code may well go away in
the future if nobody complains.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

When the OE arch is of the format "foo_bar-foobar" the previous
comparison routine did not selectively translate the '-' causing
a failed comparison.

In order to work around this issue, we -always- compare the
RPM translated version of the package architectures.

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

When write rpm spec file, one description line

"# pkgname - script_type"

is added to pre/post scriptlets for base package but no such line
writted for subpackage.

Add similiar line to subpackage to facilitate handling the pre/post
scriptlets.

Signed-off-by: Kang Kai <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>