I would also remind that we used to have separate PN-systemd packages when
systemd support was in meta-systemd layer:
https://git.openembedded.org/meta-openembedded/log/meta-systemd
This was later replaced with init scripts being usually in main PN and
sysvinit and systemd in DISTRO_FEATURES controlling which init systems your
DISTRO supports. So I guess to build images with only openrc script and no
sysvinit nor systemd, you should start by removing these DISTRO_FEATURES
and possibly providing patches where recipes still install either of them
(not respecting DISTRO_FEATURES).
Regards,
On Tue, Nov 7, 2023 at 2:15 PM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> 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 (#106453):
https://lists.openembedded.org/g/openembedded-devel/message/106453
Mute This Topic: https://lists.openembedded.org/mt/102439770/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
