[lfs-dev] Thoughts about LFS and systemd

akhiezer lfs65 at cruziero.com
Thu Mar 27 15:10:14 PDT 2014


> Date: Tue, 25 Mar 2014 11:22:38 -0500
> From: Bruce Dubbs <bruce.dubbs at gmail.com>
> To: LFS Developers Mailinglist <lfs-dev at linuxfromscratch.org>
> Subject: [lfs-dev] Thoughts about LFS and systemd
>
> I've been looking at systemd and had a thought that perhaps both could 
> be put into a single LFS build.  Looking at the installed package 
> contents in the books, I see the following name collisions:
>
> systemd  sysvinit eudev
>                    udevd
> udevadm           udevadm
> halt     halt
> init     init
> poweroff poweroff
> reboot   reboot
> runlevel runlevel
> shutdown shutdown
> telinit  telinit
>
> I don't know if udevd is missing from the systemd page or is really not 
> installed when doing a systemd build, but I suspect it has just been 
> omitted from the page.
>
> In any case, this cursory look indicates to me that both could be 
> installed with custom names and a script written to swap the names and 
> reboot to the desired system.  I also suspect a sysV initialization 
> could use the systemd version of udev and eudev would not be necessary.
>
> I have not looked at boot scripts or possibly different build options in 
> other programs, but wanted to throw out the idea for comments.
>


I'd recommend any such 'lfs-combined' be done in a third branch, separate
from lfs-systemd and lfs-main, and using merges from the latter two:
and *not* try to do all three in a single branch.


If instead all three approaches are (attempted to be) done directly on a
single branch, then inter alia you're practising the kind of 'layering'
that has been argued against (incl by yrself?) quite often - e.g. not
having multilib, avoid too many "ifs'n'buts", &c&c, as it would obscure
central educational goals of the book, &usw.


Certainly I think, in this respect at least, that it'd be wise of Armin to
not give up the separate lfs-systemd branch lightly. Also, sysd is still in
quite a state of flux; so even more reason to keep it essentially contained
in its own branch.


If the three-branches approach appears to be too 'difficult' ... then
maybe that's even more reason to be cautious about any notions of doing
everything on a single branch.



rgds, akh





--



More information about the lfs-dev mailing list