Avoids parser errors if PACKAGE_ADD_METADATA_DEB is set to an
empty value.

Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

In deb control files, each line of a long description starts with
a single space. Empty lines are represented by a single space
followed by a single full stop character.

Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Unlike rpm, debian packaging does not allow file paths in 'Provides:' field.
When 'usrmerge' distro feature enabled bash/busybox packages adds '/bin/sh' to
it's RPROVIDES to satisfy build dependencies, this entry should be filtered out.

Signed-off-by: Amarnath Valluri <amarnath.valluri@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

Now that the datastore works dynamically we don't need the update_data calls
so we can just remove them. They're not actually done anything at all for
a while.

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

It was discovered that buildtools-tarball can't be built with Debian packaging:

E: Unable to locate package nativesdk-buildtools-perl-dummy

The package exists but dpkg doesn't see it because the Architecture field isn't
valid: for this package the Architecture field is 'allarch' which isn't in the
list of valid architectures we define.

package_deb already has a mapping of OE architectures (PACKAGE_ARCH) to dpkg
architectures (DPKG_ARCH), for example our x86_64 is amd64 in dpkg.  However
allarch.bbclass sets an invalid TARGET_ARCH of 'allarch' (to break anything
which attempts to use the target architecture) and package_deb relied on the
PACKAGE_ARCH check later turning the Architecture field into 'all'.

This usually works, but nativesdk-buildtools-perl-dummy inherits allarch but
then changes PACKAGE_ARCH to buildtools-dummy-nativesdk to isolate the packages
in a separate feed.  We can handle this by explictly checking for allarch in the
TARGET_ARCH check, as that everything that inherits allarch will want to have
Architecture: all in their packages.

[ YOCTO #10700 ]

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

The exception handling in this function seemed mildly crazy. Python will
given perfectly good or in several cases better information if we let its
standard traceback/exception handling happen. Remove the pointless code
along with the duplicated key checking which was broken in the inner loop
by usage of the wrong variable.

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

Currently if the dpkg-deb command fails you see an error message like this:

ERROR: nss-3.27.1-r0 do_package_write_deb: dpkg-deb execution failed
ERROR: nss-3.27.1-r0 do_package_write_deb: Function failed: do_package_deb

which is pretty much useless. If we use subprocess.check_output, we see a
traceback and then:

Exception: subprocess.CalledProcessError: Command '<cmd>' returned non-zero exit status 1

Subprocess output:
<output>

which is much easier to debug from.

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

Add a new variable to allow markup of postinstall (and preinst)
script dependnecies on native/cross tools.

If your postinstall can execute at rootfs creation time rather than on
target but depends on a native tool in order to execute, you need to
list that tool in PACKAGE_WRITE_DEPENDS.

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>

This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.

Motivating quote below:

< kergoth> the *original* intent was for the function/task to error via
           whatever appropriate means, bb.fatal, whatever, and
           funcfailed was what you'd catch if you were calling
           exec_func/exec_task. that is, it's what those functions
           raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself

FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.

Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>