| Summary: |
systemd.class does not handle multilib well when package has multiple services |
| Product: |
[Build System, Metadata & Runtime] OE-Core
|
Reporter: |
Saul Wold <sgw> |
| Component: |
core | Assignee: |
Ross Burton <ross.burton> |
| Status: |
RESOLVED
FIXED
|
QA Contact: |
|
| Severity: |
normal
|
|
|
| Priority: |
Medium
|
CC: |
meta.mr.watcher, meta.watcher, ross.burton, sgw
|
| Version: |
unspecified | |
|
| Target Milestone: |
1.5 | |
|
| Hardware: |
Other | |
|
| OS: |
Multiple | |
|
| Whiteboard: |
|
|
OS type for building Yocto:
|
---
|
Type of Regression:
|
---
|
|---|
|
Verified:
|
|
Documentation change:
|
No (bug/feature does not impact docs)
|
|---|
I was building a multilib system with systemd enabled and found that avahi is reporting installed / not shipped issues with /lib/systemd. I tracked this down to the systemd.bbclass spliting and matching on SYSTEMD_SERVICE and SYSTEM_PACKAGES. When I ran bitbake with -e, I got the following: env:# $SYSTEMD_SERVICE_avahi-dnsconfd env:SYSTEMD_SERVICE_avahi-dnsconfd="avahi-dnsconfd.service" env:# $SYSTEMD_PACKAGES [2 operations] env:SYSTEMD_PACKAGES="lib64-avahi-daemon lib64-avahi-dnsconfd" env:# $SYSTEMD_SERVICE_avahi-daemon env:SYSTEMD_SERVICE_avahi-daemon="avahi-daemon.service" Seems the SYSTEMD_PACKAGES has lib64- while the _SERVER is from the recipe (ie not autogenerated from systemd.bbclass) When there is only one PACKAGE/SERVICE then systemd.bbclass auto generates the values and they look correct and both have the lib64- prefix env.ssh:# $SYSTEMD_PACKAGES env.ssh:SYSTEMD_PACKAGES="lib64-openssh" env.ssh:# $SYSTEMD_SERVICE_${PN} [2 operations] env.ssh:# "SYSTEMD_SERVICE_lib64-openssh"