Taking run-postinsts and building for two machines which have different
OVERRIDES leads to two different sets of stamps for an allarch package.

We don't need to depend on OVERRIDES in these classes, the end resulting
variables are good enough. We can therefore exclude the dependency
and allow a single package to be generated for run-postinsts.

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

The 'and' logic for the check is wrong. To make things clear, please
see the example below.

Say that we have a recipe A, which has a sysv-init style init script named
initA and no corresponding service file. The recipe inherits update-rc.d,
but it doesn't inherit systemd.bbclass. The DISTRO_FEATURES has 'systemd'
inside it, but it doesn't have 'sysvinit'. Now if we build an image, with
the 'and' logic in the check, the symlinks for initA would not be installed
into /etc/rc?.d directory.
This is incorrect. Because there's no corresponding service. The symlinks
in /etc/rc?.d/ should be created so that the service would be correctly
started at boot time.

The logic should really be 'or' in the check. This is actually what the code
was when it was originally written.

Several different situations are listed below to prove the correctness of the
'or' logic.

If 'sysvinit' is in DISTRO_FEATURES, the initA script would always be installed
with corresponding preisnt/postinst generated and added.

If 'sysvinit' is not in DISTRO_FEATURES, we have three situations.
1) A has initA and A.service.
   In such situation, systemd.bbclass would set INHIBIT_UPDATERCD_BBCLASS,
   so no preinst/postinst about update-rc.d would be added and the symlinks
   for initA would not be created.

2) A has initA, and the functionality of initA is not implemented internally
   in systemd.
   In such situation, symlinks for initA would be installed.

3) A has initA, and the functionality of initA is implemented internally in
   systemd or in some other recipe.
   Examples for such situation are alsa-state and keymaps in OE.
   In such situation, we need to set INHIBIT_UPDATERCD_BBCLASS in the recipe
   so that there would be no preinst/postinst scripts about update-rc.d added.

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

* until now all recipes were respecting VIRTUAL-RUNTIME_initscripts
  variable but commit bba835fed88c3bd5bb5bd58962034aef57c408d8
  hardcoded "initscripts" runtime dependency

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>

These dependcies are needed to ensure that thier packages are created
correctly since these classes have runtime dependiences in their packages
but they are not actually created yet at rootfs time.

[YOCTO #6072]

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

When building multilib, we also have to add the multlib prefix otherwise
we get a WARNING:
WARNING: Multilib QA Issue: lib32-dbus package lib32-dbus - suspicious values 'initscripts-functions' in RDEPENDS

[YOCTO #6164]

Signed-off-by: Saul Wold <sgw@linux.intel.com>

BitBake has the exact same code as oe.utils.contains so there's no
reason to duplicate it. We now rely on the bb.utils.contains code for
metadata.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

In update-rc.d.bbclass it checks variable INHIBIT_UPDATERCD_BBCLASS to
inhibit from inheriting this class. But it is wrong logic that when
'sysvinit' is in 'DISTRO_FEATURES', INHIBIT_UPDATERCD_BBCLASS will not
be checked.

Replace 'or' with 'and' to fix it.

Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>

The virtclass overrides will go away at some point (apart from the multilib one).
Change them all to class-xxx instead since people enjoy copy and pasting them.

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

Automatically add 'initscripts-functions' to packages when needed.

This extra dependency is added only when the package's init script
would be used at system start-up. In other words, in a systemd based
image, if the package has already got its service files, it will not
have this extra dependency.

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>

Using the contains function results in more optimal sstate checksums
resulting in better cache reuse as we as more consistent code.

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