linux/poky.git/meta/classes/update-rc.d.bbclass, branch python3

update-rc.d.bbclass: explicitly dep on initscripts

2015-08-30T11:35:58+00:00

update-rc.d doesn't just want an initscripts package, it wants initscripts-functions. In the case where VIRTUAL-RUNTIME_initscripts is set to nothing, update-rc.d still needs initscripts-functions to satisfy its runtime dependencies. Further, we shouldn't be using a *runtime* virtual in a *build time* variable. This should resolve image creation failures with configurations without sysv initscripts when a recipe inherits update-rc.d and doesn't inherit systemd. (From OE-Core rev: e6642ae0849e5ac3174c643a7693af25d829d6d1) (From OE-Core rev: 833302761df924bb503cc2ad04ecae1023381f8f) Signed-off-by: Christopher Larson Signed-off-by: Richard Purdie

updated-rc.d: Only add dependencies in target case

2015-07-26T08:14:30+00:00

Avoid errors like: ERROR: Nothing PROVIDES 'nativesdk-update-rc.d' (but virtual:nativesdk:dbus_1.8.18.bb DEPENDS on or otherwise requires it). (From OE-Core rev: 270a1716b02981aad353c266d3d19735fc85cf10) Signed-off-by: Richard Purdie

update-rc.d: Include updated-rc.d in DEPENDS

2015-07-25T22:06:59+00:00

If you build a user of updated-rc.d like udev, as things stand currently nothing pulls in updated-rc.d but there is a dependency added on the package at do_package time. This can lead to errors during rootfs construction either with licensing. The fact its a RRECOMMEND means the image are not deterministic. A particularly good test case for reproducing this is: MACHINE=A bitbake core-image-minimal MACHINE=B bitbake core-image-minimal-initramfs and since the second machine can find the package but not the license manifest, a failure will result. Extending the DEPENDS is the easy way to fix the issues. (From OE-Core rev: 164b1b54c4b3127733bcd0a21b379bb6869693cc) Signed-off-by: Richard Purdie

meta: Add explict getVar param for (non) expansion

2015-06-23T10:57:25+00:00

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 *` (From OE-Core rev: ab7c1d239b122c8e549e8112c88fd46c9e2b061b) Signed-off-by: Richard Purdie

update-rc.d.bbclass: add MLPREFIX when set RRECOMMENDS

2015-06-11T22:59:16+00:00

Fixed when build with multilib: WARNING: Multilib QA Issue: lib32-alsa-state package lib32-alsa-state - suspicious values 'update-rc.d' in RRECOMMENDS WARNING: Multilib QA Issue: lib32-modutils-initscripts package lib32-modutils-initscripts - suspicious values 'update-rc.d' in RRECOMMENDS WARNING: Multilib QA Issue: lib32-init-ifupdown package lib32-init-ifupdown - suspicious values 'update-rc.d' in RRECOMMENDS WARNING: Multilib QA Issue: lib32-xserver-nodm-init package lib32-xserver-nodm-init - suspicious values 'update-rc.d' in RRECOMMENDS WARNING: Multilib QA Issue: lib32-sysklogd package lib32-sysklogd - suspicious values 'update-rc.d' in RRECOMMENDS (From OE-Core rev: 43e8192606444c339ef732d611d4cbc18dee21e4) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie

update-rc.d: Improve RRECOMMENDS handling

2015-05-29T09:17:14+00:00

Unfortunately the combination of: RRECOMMENDS_${PN} = "X" UPDATERCPN = "${PN}" RRECOMMENDS_${UPDATERCPN}_append = "Y" is tricky for bitbake to order correctly since RRECOMMENDS_${UPDATERCPN} can become "Y" which can then completely overwrite RRECOMMENDS_${PN}. Avoid these issues and improve handling in general by explictly setting the RRECOMMENDS on the list of packages modified in the general code. (From OE-Core rev: 053b8a4e6b9a4b02c0b1b4bc1e297a1251a901a9) Signed-off-by: Richard Purdie

update-rc.d: use '-f' option in updatercd_postrm

2015-02-17T22:35:03+00:00

Use '-f' ('--force') option so that while removing packages using deb, we don't fail because of the following error: update-rc.d: $initd/$bn exists during rc.d purge (use -f to force) Using '-f' option would make this a warning but continue to execute. update-rc.d: $initd/$bn exists during rc.d purge (continuing) We need this option because dpkg package backend have special handling for configuration files. And if files under /etc/init.d are treated as configuration files, we will have errors. (From OE-Core rev: ebb2d557bbf410d98040cdaabbddd7e3ee0a9709) Signed-off-by: Chen Qi Signed-off-by: Richard Purdie

update-rc.d/systemd: Remove OVERRIDES dependency

2014-09-23T20:38:59+00:00

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. (From OE-Core rev: fdc949154e64afb41dd4db3a97be74a15963128d) Signed-off-by: Richard Purdie

update-rc.d: fix logic in populate_packages_updatercd

2014-09-03T10:09:04+00:00

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. (From OE-Core rev: 6272c81509bbdb5d602056ceaa6f2c02bbf47a41) Signed-off-by: Chen Qi Signed-off-by: Richard Purdie

update-rc.d: Allow to use different initscripts provider

2014-06-10T16:24:19+00:00

* until now all recipes were respecting VIRTUAL-RUNTIME_initscripts variable but commit bba835fed88c3bd5bb5bd58962034aef57c408d8 hardcoded "initscripts" runtime dependency (From OE-Core rev: 8b4256758ba55dcabe80dd1bf3884cdf1cc39909) Signed-off-by: Martin Jansa Signed-off-by: Saul Wold Signed-off-by: Richard Purdie