systemd/sysvinit in the 1.4 release
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
Who need hybrid mode?
Quoted 47 lines · 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 onlyand 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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Signature · 3 lines
Nanjing Jilong Yi Qingliang [email protected]
Quoted 1 line · 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
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre