tar version 1.27 returns:

tar: --same-order option cannot be used with -c

with the commandlines we have been using. We can remove the -s option (which
is --same-order) to remove the error.

(From OE-Core master rev: 3d5a6d0a480a0fa98260a3b3ffc71b8d9e3e58af)

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

The names used to generate the binary-localdata packages need to match the location
the dependencies are added. In one case the dash replacement is made, in the other it
is not leading to packages which cannot be installed:

	eglibc-binary-localedata-af-za.iso88591 is needed by locale-base-af-za.iso-8859-1-2.16-r22.i586
	eglibc-binary-localedata-cs-cz.iso88592 is needed by locale-base-cs-cz.iso-8859-2-2.16-r22.i586
	eglibc-binary-localedata-ru-ru.koi8r is needed by locale-base-ru-ru.koi8-r-2.16-r22.i586
	eglibc-binary-localedata-pl-pl.iso88592 is needed by locale-base-pl-pl.iso-8859-2-2.16-r22.i586
	eglibc-binary-localedata-hu-hu.iso88592 is needed by locale-base-hu-hu.iso-8859-2-2.16-r22.i586
	eglibc-binary-localedata-de-at+euro.iso885915 is needed by locale-base-de-at+euro.iso-8859-15-2.16-r22.i586
	eglibc-binary-localedata-sv-fi.iso88591 is needed by locale-base-sv-fi.iso-8859-1-2.16-r22.i586

This fixes things so the names are consistent.

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

This avoids the hardcoding of ${libdir}/locale which is all over the place,
and will facilitate use of ${exec_prefix}/lib/locale instead of
${libdir}/locale.

This doesn't actually change any output at this time. Verified this with
buildhistory against the packages produced from core-image-base.

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

The bb and os modules are always imported so having these extra import calls
are a waste of space/execution time. They also set a bad example for people
copy and pasting code so clean them up.

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

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

needed for new architecture support

Signed-off-by: Khem Raj <raj.khem@gmail.com>

Added multilib prefix to the locale related package names/dependencies.

Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

We need to add MLPREFIX when set RDEPENDS by setVar() function.

Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>

There were a couple problems with the handling of precompiled locales.

- it gathered the list of locales from the directories - this breaks due to
  the naming mismatch, e.g. en_US.UTF-8 vs en_US.utf8.
- it retained its hardcoded assumption that the non-suffixed locale (en_US, as
  opposed to en_US.*) is UTF-8, while the others are otherwise. Hardcoding
  this is both inflexible and just plain wrong for some toolchains. It's most
  common in desktop distros for 'en_US' to be non-utf8, and ''en_US.UTF-8' is
  utf8, and this is the case in some external toolchains as well.

The code now uses the SUPPORTED file to hold the knowledge it needs. This file
not only holds the list of locales to generate, but also maps the locale names
to the charsets they correspond to. The code now uses this to assemble its
charset map, falling back to the '.' suffix as charset when the locale is not
in the map. For precompiled, it now uses the locale->charset knowledge it has,
thereby allowing non-utf8 non-suffixed locale names, whereas for
non-precompiled, it reverts to the previous assumption, renaming the utf8
locale and forcibly suffixing the others.

So, a person maintaining an external toolchain recipe is responsible for
ensuring that the SUPPORTED file they provide matches up with the compiled
locales in the toolchain, if they want to utilize precompiled locales.

I believe in the long term the compiled case should do the same thing
precompiled does, and use SUPPORTED or a similar mechanism to encode the
knowledge, and if people want all the non-suffixed names to be utf8, they can
change that file to do so. This would avoid the hardcoded assumption in the
code, as well as consolidating the behavior between the compiled and
precompiled cases.

Signed-off-by: Christopher Larson <kergoth@gmail.com>

MLPREFIX is needed in RDEPENDS for multilib build

Signed-off-by: Zhai Edwin <edwin.zhai@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>