On Tue, 2023-11-07 at 09:30 +0000, ANQUETIN Mathieu wrote:
> Hello all,
>
> I would like to discuss an architecture solution to ease support for
> alternative init systems.
>
> As of now, OpenEmbedded supports sysvinit and systemd as first-class
> citizens but does so by including required files in the main package
> based on the value of the VIRTUAL-RUNTIME_init-manager variable. This
> forces layers, like meta-openrc for example, to remove files
> generated by other layers before providing their own. This increases
> the maintenance burden for layer maintainers of these alternative
> init systems while making them always feel like second-class
> citizens.
>
> My solution would be to generate specific packages for each init
> system (${PN}-sysvinit, ${PN}-systemd, ...) and RDEPENDS on them
> given the value of the VIRTUAL-RUNTIME_init-manager variable. This
> would simplify recipes because filtering files would no longer be
> required since all packages would be generated and other layers would
> simply provide their ${PN}-altinit package through bbappends.
> I have made a PoC on the 'kirkstone' branch but this kind of
> modification requires all recipes to adapt to the new architecture
> and therefore I would like to know if you would accept such
> modifications.
I'd note that both systemd and sysvinit end up with code which does
manipulate the generated packages depending on which is enabled.
Packages can be generated for systemd only which would result in the
packages not containing sysvinit scripts.
As such, ${PN}-sysvinit and ${PN}-systemd would never exist together
since you have to choose an init system and the ability to swap between
them is limited.
I'd note that you can have init scripts for multiple packages within a
given recipe. I'd also note that packages sometimes aren't actually
useful without their init script.
Also, the packages wouldn't be that useful since if you change
VIRTUAL-RUNTIME_init-manager, all the packages are going to end up
being rebuilt anyway.
As such, I think the proposed solution would need a lot more careful
thought and detail before we'd be able to say whether it would make
sense.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1835):
https://lists.openembedded.org/g/openembedded-architecture/message/1835
Mute This Topic: https://lists.openembedded.org/mt/102442132/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
