This code is old and was of it's time, rewrite it to use modernish (we support
Python 3.4, so can't use subprocess.run()) subprocess and re idioms instead.

Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

The existing code is looking for libraries in all paths which end in ${libdir}.
This caused false-positives for recipes such as lz4 which had files called
/usr/lib/lz4/ptest/usr/lib/liblz4.so, and resulted in lz4-ptest being
incorrectly renamed to liblz4.

Solve this by explicitly looking for ${libdir} etc under the packages-split
directory.

Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

To make it easier to debug problems with renaming caused by debian.bbclass,
explicitly log when packages are renamed.

Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

getVar() now defaults to expanding by default, thus remove the True
option from getVar() calls with a regex search and replace.

Search made with the following regex: getVar ?\(( ?[^,()]*), True\)

Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

PKG_ can be set to something like ${MLPREFIX}<name> and the lack of expansion here
means the case where MLPREFIX is empty leads to a bogus RPROVIDES.

Use expansion of the variable to avoid this.

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

Recently, libspeexdsp-dev added RCONFLICTS = "speex-dev < 1.2rc2". where
libspeexdsp is 1.2rc3. That all seems reasonable, except there is a problem.

debian.bbclass renames speex-dev to libspeex-dev and adds a "Provides: speex-dev"
which the packaging backends duly note. The trouble is rpm sees that as having no
version at all. This means that "speex-dev < 1.2rc2" conflicts with "speex-dev"
and the -dev package simply cannot be installed.

We can't simply version all Provides for rpm since some dependencies clearly
shouldn't be versioned (e.g. the locale ones).

The solution that seems to work best is to add the versions in debian.bbclass.
If the backend doesn't like these, the backend can then strip them off
(separate patch does this).

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>

Rather than just use d.getVar(X), use the more explict d.getVar(X, False)
since at some point in the future, having the default of expansion would
be nice. This is the first step towards that.

This patch was mostly made using the command:

sed -e 's:\(getVar([^,()]*\)\s*):\1, False):g' -i `grep -ril getVar *`

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

Currently its hard for a packagegroup recipe to depend on something who's name
can change unpredictably. We therefore add in RPROVIDES for the original
package name so that these are also available to use as dependencies.

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

Might as well move this default to the class which uses it allowing
for easier reading/understanding of the class.

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

This class defines a package_name_hook implementation but as EXPORT_FUNCTIONS is
order-dependent it needs to inherit package.bbclass first to ensure that the
"base" definition in there is defined first, otherwise with a suitable inherit
order of debian and then a packaging class can result in the stub
package_name_hook being incorrectly used.

Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>