On Tue, Nov 7, 2023 at 02:15 PM, Richard Purdie 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.
This specific code will still exist but in the corresponding package. My
proposition is to generate packages everytime, regardless of the init
system selected but to force installation of the desired package using
RDEPENDS.
>
> 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.
They would both exist but only one would be installed during image
generation. I agree that the init system is part of what defines a distribution.
That's why I am proposing something to ease integration of alternatives while
not increasing the maintenance burden on layer maintainers.
>
> 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.
This wouldn't change. That's why I recommend a RDEPENDS to make
sure the package is not installed without its initscript.
>
> 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.
I am trying to port my patches on master, so we can discus on something
more concrete.
>
> Cheers,
>
> Richard
>
>
>
Best regards,
Mathieu ANQUETIN
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1837):
https://lists.openembedded.org/g/openembedded-architecture/message/1837
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]]
-=-=-=-=-=-=-=-=-=-=-=-
