On 14 February 2013 12:32, Florin Sarbu wrote:
> So choosing, for example ${PN} to hold the systemd services, and also choose
> to use sysvinit as the init manager, then I'd end up with a rootfs
> containing useless systemd services.
That would be a packaging bug.
The systemd class only does wor
So choosing, for example ${PN} to hold the systemd services, and also
choose to use sysvinit as the init manager, then I'd end up with a
rootfs containing useless systemd services.
Then can someone detail what is SYSTEMD_PACKAGES used for? If it's only
for adding the packages to PACKAGES, then i
On 14 February 2013 09:09, Florin Sarbu wrote:
> The issue I was referring to was that the individual packages (that contain
> the systemd service files) generated from various recipes, do not end up in
> the rootfs solely by having them declared in the SYSTEMD_PACKAGES and having
> DISTRO_FEATURE
The issue I was referring to was that the individual packages (that
contain the systemd service files) generated from various recipes, do
not end up in the rootfs solely by having them declared in the
SYSTEMD_PACKAGES and having DISTRO_FEATURES_INITMAN ="systemd". You need
now to explicitly add
On 02/13/2013 05:33 PM, Florin Sarbu wrote:
Hi all,
following the transition of the systemd.bbclass from meta-openembedded
to oe-core, I stumbled upon on what seems to me a missing feature that
has not been brought along in the new systemd.bbclass in oe-core.
Seems that if one does not explic
Hi all,
following the transition of the systemd.bbclass from meta-openembedded
to oe-core, I stumbled upon on what seems to me a missing feature that
has not been brought along in the new systemd.bbclass in oe-core. Seems
that if one does not explicitly specify the inclusion of the packages
co
