> > +BBCLASSEXTEND += "native" > > We've long avoided a systemd-native recipe as the meaning can be easily > confused and I'm not thrilled to be adding one now. > > Perhaps this should be as a separate systemd-tools-native recipe to > make it clear this isn't full systemd?
There is another catch: ukify depends on sbsign for some options. Here, this dependency is not expressed as RDEPENDS on the systemd components but only on the uki class. That of course gets around the meta-security-core dependency for systemd, but not sure how pretty that is. So we got: * python3-pefile in meta-python * sbsigntool in meta-signing-key [meta-security-core] It looks like we have these options: 1. Add the systemd-tools (or however we call it) recipe and the uki class in meta-signing-key or friends. This might become a bit icky with different systemd recipes scattered over different repos... 2. Do not put a RDEPENDS += "sbsigntool" into the systemd-tools recipe. Move python3-pefile to oe-core. This means that some ukify options will fail. Users will need to add [R]DEPENDS on their recipes if they want signing. This would allow adding the systemd-tools recipe in oe-core while adding the rest in meta-security-core. 3. Also move the signing tools to oe-core. Next to the python module, this also requires to move sbsigntool to oe-core... In the end it allows to set the RDEPENDS in systemd-tools. I got no particular strong feeling on any of those outcomes... Any opinions? 🤔 - Erik
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#190984): https://lists.openembedded.org/g/openembedded-core/message/190984 Mute This Topic: https://lists.openembedded.org/mt/101106095/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
