systemd/sysvinit in the 1.4 release

systemd/sysvinit in the 1.4 release

[Richard Purdie]

I just wanted to be clear with people what has gone on with sysvinit and
systemd in the 1.4 release. 

Basically I took some patches recently on a trust that certain things
had been checked and it was found that there were problems with the
changes after they went in. At some point I have to trust the data I'm
getting and in this case things broke down. 

Since systemd is one of the priority features of this release, releasing
with it broken was not the right thing to do so at the last minute we've
basically reverted some of the recent changes to systemd and udev
(the /sbin relocation) and then tried to fix various issues that arose
from that (even with the reverts, there were still several issues). I
appreciate this isn't an ideal thing to do either.

We now have a build of the dylan branch which is likely to become rc2
and get tested by QA and may well be the final release. We're past the
point we can consider any changes unless something is seriously broken.
We're trying to do some additional testing today to determine whether
there is anything seriously wrong with the recent changes.

I would point out that having the "systemd + sysvinit" hybrid mode which
is not something we'd originally planned for gives us a ton of headaches
since we have to test:

systemd only
systemd+sysvinit in systemd mode
systemd+sysvinit in sysvinit mode
sysinit only

and for each we need to test for each architecture and we then need to
look at for example multilibs in each case. Currently the autobuilder
isn't able to help with this although obviously that is something we
need to fix in the 1.5 cycle.

Cheers,

Richard

Re: systemd/sysvinit in the 1.4 release

[Yi Qingliang]

Who need hybrid mode?

On Thursday, April 18, 2013 08:29:20 AM Richard Purdie wrote:
> I just wanted to be clear with people what has gone on with sysvinit and
> systemd in the 1.4 release.
> 
> Basically I took some patches recently on a trust that certain things
> had been checked and it was found that there were problems with the
> changes after they went in. At some point I have to trust the data I'm
> getting and in this case things broke down.
> 
> Since systemd is one of the priority features of this release, releasing
> with it broken was not the right thing to do so at the last minute we've
> basically reverted some of the recent changes to systemd and udev
> (the /sbin relocation) and then tried to fix various issues that arose
> from that (even with the reverts, there were still several issues). I
> appreciate this isn't an ideal thing to do either.
> 
> We now have a build of the dylan branch which is likely to become rc2
> and get tested by QA and may well be the final release. We're past the
> point we can consider any changes unless something is seriously broken.
> We're trying to do some additional testing today to determine whether
> there is anything seriously wrong with the recent changes.
> 
> I would point out that having the "systemd + sysvinit" hybrid mode which
> is not something we'd originally planned for gives us a ton of headaches
> since we have to test:
> 
> systemd only
> systemd+sysvinit in systemd mode
> systemd+sysvinit in sysvinit mode
> sysinit only
> 
> and for each we need to test for each architecture and we then need to
> look at for example multilibs in each case. Currently the autobuilder
> isn't able to help with this although obviously that is something we
> need to fix in the 1.5 cycle.
> 
> Cheers,
> 
> Richard
> 
> 
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
-- 
Nanjing Jilong
Yi Qingliang
niqingliang2003@gmail.com

Re: systemd/sysvinit in the 1.4 release

[Paul Eggleton]

On Thursday 18 April 2013 17:27:50 Yi Qingliang wrote:
> Who need hybrid mode?

The most reasonable use-case is for using systemd in the main root filesystem 
and sysvinit within a rescue/initramfs image (without having to use two 
separate distro configurations).

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre