On Wed, Nov 8, 2023 at 7:53 AM Martin Jansa <[email protected]> wrote: > > > > On Wed, Nov 8, 2023 at 8:32 AM Alex Kiernan <[email protected]> wrote: >> >> 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: >> .... >> seems it'd be a trivial fix). For some reason update-rc.d gets brought >> in via an RRECOMMENDS, not looked into why. > > > Any reason not to add update-rc.d to BAD_RECOMMENDATIONS for you? > > webOS OSE uses that for a while (and doesn't use upstart anymore) in: > https://github.com/webosose/meta-webosose/blob/master/meta-webos/conf/distro/include/webos-preferred-providers.inc#L82 > > # With upstart we don't need update-rc.d, as bonus fixes following avahi > issue for us: > # > http://lists.openembedded.org/pipermail/openembedded-core/2013-November/086901.html > BAD_RECOMMENDATIONS += "update-rc.d" > UPDATERCD:class-target = ""
I expect something exactly like that will work! -- Alex Kiernan
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1843): https://lists.openembedded.org/g/openembedded-architecture/message/1843 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]] -=-=-=-=-=-=-=-=-=-=-=-
