On Tue, Nov 7, 2023 at 10:57 PM Mathieu Anquetin
<[email protected]> wrote:
>
> On Tue, Nov  7, 2023 at 11:17 PM, Ross Burton wrote:
> >
> > On 7 Nov 2023, at 09:30, ANQUETIN Mathieu via lists.openembedded.org
> > <[email protected]> wrote:
> > > 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.
> >
> > No, it doesn’t.
> >
> > Remove sysvinit and systemd from DISTRO_FEATURES and the relevant classes 
> > will
> > delete the initscripts/systemd units from the packages.
> >
> > I wasn’t aware of meta-openrc, but it should just have an openrc init
> > feature and behave the same as the existing init classes.
> >
> Thanks for the clarification. In fact, it does behave the same as the existing
> init classes. But reading the corresponding classes, it felt convoluted to 
> inhibit
> running 'update-rc.d.bbclass' in other classes and to delete files in each 
> class.
> To me, it looked like some sort of coupling and I will find it easier if each 
> class
> only handled its files regardless of the others. Also, recipes would no longer
> need to filter files in 'do_install' given the DISTRO_FEATURES value.
>
> I came up with this proposition after reading some documentation about init
> systems and after seeing how Artix Linux handled the possibility of providing
> multiple init systems.
>

I have another init system we're using here, based around s6
(https://skarnet.org/software/), which we then deploy as either a pure
s6-linux-init/s6-rc solution using an init manager fragment like this:

# enable s6-linux-init/s6-rc for init
DISTRO_FEATURES_BACKFILL_CONSIDERED:append = " sysvinit systemd"
VIRTUAL-RUNTIME_init_manager = "s6-linux-init"
VIRTUAL-RUNTIME_initscripts = ""
VIRTUAL-RUNTIME_login_manager = "busybox"
S6_LINUX_INIT_SERVICE_MANAGER ??= "s6-rc"

With this setup, the only package that leaks anything sysvinit/systemd
related into our images is dbus (which having just had a quick look
seems it'd be a trivial fix). For some reason update-rc.d gets brought
in via an RRECOMMENDS, not looked into why.

We have a second hybrid arrangement with s6-linux-init as pid 1, but
using initscripts (it's ugly, but was what we needed...)

# enable s6-linux-init/sysvinit for init
# this is clearly a lie, but the easiest way to ensure we have the necessary
# infrastructure
DISTRO_FEATURES:append = " sysvinit"
DISTRO_FEATURES_BACKFILL_CONSIDERED:append = " systemd"
VIRTUAL-RUNTIME_init_manager ??= "s6-linux-init"
VIRTUAL-RUNTIME_initscripts ??= "initscripts"
VIRTUAL-RUNTIME_login_manager ??= "busybox"
S6_LINUX_INIT_SERVICE_MANAGER ??= "sysvinit"

This one's more ugly as we have to pick out pieces of sysvinit so that
initscripts has the necessary infrastructure to run, I guess a small
amount of refactoring in sysvinit would allow this to work better.

(as an aside I've no idea why we used ??= for some of these and = for
the other... I suspect we got it working and stopped!)

-- 
Alex Kiernan
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1841): 
https://lists.openembedded.org/g/openembedded-architecture/message/1841
Mute This Topic: https://lists.openembedded.org/mt/102439769/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to