1 |
On 05/01/2013 12:04 PM, Fabio Erculiani wrote: |
2 |
> PLEASE DO NOT START A FLAME WAR AND READ ON FIRST. |
3 |
> THIS IS NOT A POST AGAINST OPENRC. |
4 |
|
5 |
Amen |
6 |
|
7 |
> With the release of Sabayon 13.04 [1] and thanks to the efforts I put |
8 |
> into the systemd-love overlay [2], systemd has become much more |
9 |
> accessible and easy to migrate to/from openrc. Both are able to |
10 |
> happily coexist and logind/consolekit detection is now done at |
11 |
> runtime. |
12 |
> It is sad to say that the "territoriality" in base-system (and |
13 |
> toolchain) is not allowing any kind of progress [3] [4]. This is |
14 |
> nothing new, by the way. |
15 |
> |
16 |
> There are several components that need patching in order to work as |
17 |
> expected with systemd: |
18 |
> - polkit needs a patch that enables runtime detection of logind/consolekit |
19 |
> - pambase needs to drop USE=systemd and always enable the optional |
20 |
> module pam_systemd.so |
21 |
> - genkernel needs to migrate to *udev (or as I did, provide a --udev |
22 |
> genkernel option), mdev is unable to properly activate LVM volumes and |
23 |
> LVM is actually working by miracle with openrc. Alternatively, we |
24 |
> should migrate to dracut. |
25 |
|
26 |
[unrelated] Do you have more insights about this part? mdev MUST work, |
27 |
lots of thin recovery options are based on busybox. |
28 |
|
29 |
> - networkmanager need not to install/remove files depending on |
30 |
> USE=systemd but rather detect systemd at runtime, which is a 3 lines |
31 |
> script. |
32 |
|
33 |
Sounds sensible. |
34 |
|
35 |
> - openrc-settingsd needs to support eselect-settingsd, which makes |
36 |
> possible to switch the settingsd implementation at runtime, between |
37 |
> openrc and systemd. This also removes the silly conflict between |
38 |
> openrc-settingsd and systemd friends. |
39 |
|
40 |
Would make sense merge init and settingsd in a single eselect or at |
41 |
least make so switching init would warn if the settingsd doesn't match? |
42 |
|
43 |
> - genkernel should at least support plymouth (work in progress my side) |
44 |
|
45 |
Looking forward to it. |
46 |
|
47 |
> - other ~490 systemd units are missing at this time and writing them |
48 |
> could also be a great GSoC project (don't look at me, I'm busy |
49 |
> enough). |
50 |
|
51 |
Hopefully we might have a gsoc student volunteering to make a |
52 |
runscript/lsb-script/systemd-unit compiler and a small abstraction so we |
53 |
write a single init.d script and generate what's needed. |
54 |
Probably we might even support pure-runit that way with minimal effort. |
55 |
|
56 |
> It looks like there is some consensus on the effort of making systemd |
57 |
> more accessible, while there are problems with submitting bugs about |
58 |
> new systemd units of the sort that maintainers just_dont_answer(tm). |
59 |
> In this case, I am just giving 3 weeks grace period for maintainers to |
60 |
> answer and then I usually go ahead adding units (I'm in systemd@ after |
61 |
> all). |
62 |
|
63 |
See above. |
64 |
|
65 |
> The only remaining problem is about eselect-sysvinit, for this reason, |
66 |
> I am probably going to create a new separate pkg called |
67 |
> _sysvinit-next_, that contains all the fun stuff many developers were |
68 |
> not allowed to commit (besides my needs, there is also the need of |
69 |
> splitting sysvinit due to the issues reported in [4]). I am sure that |
70 |
> a masked alternative sysvinit ebuild won't hurt anybody and will make |
71 |
> Gentoo a bit more fun to use. |
72 |
|
73 |
Exactly, which is the problem at hand? I'd like to be able to safely |
74 |
switch back and forth sysvinit and bb-init as well. |
75 |
|
76 |
> The final outcome will hopefully be: |
77 |
> - easier to migrate from/to systemd, at runtime, with NO recompilation |
78 |
> at all (just enable USE=systemd and switch the device manager from |
79 |
> *udev to systemd -- unless somebody wants to drop the udev part from |
80 |
> systemd, if at all possible) |
81 |
> - we give the users the right to choose without driving them nuts with |
82 |
> weird emerge-fu. |
83 |
> - we make possible to support new init systems in future, and even |
84 |
> specific init wrappers (bootchart anyone?) |
85 |
|
86 |
Here! o/ Currently in my list are |
87 |
|
88 |
- bootchart2 (as an add-on to the other init systems) |
89 |
- bb-init (requires different custom inittab) |
90 |
- runit (openrc can use it instead thanks to benda xu past GSoC) |
91 |
|
92 |
> - we prepare the path towards a painless migration from consolekit |
93 |
> (deprecated for long time now) to logind (we probably need to fork it |
94 |
> off the systemd pkg -- upstream projects are _dropping_ consolekit |
95 |
> support right now!) |
96 |
|
97 |
Again it is something I consider an option for a GSoC project, we have |
98 |
already some openrc variant for other systemd-originated daemons in our |
99 |
git. |
100 |
|
101 |
> - we put back some fun into Gentoo |
102 |
|
103 |
That's always good. |
104 |
|
105 |
> If you want to see a working implementation of my systemd-love |
106 |
> efforts, just go download [1] and see things working yourself. |
107 |
|
108 |
Thank you a lot for your positive attitude and the huge effort =) |
109 |
|
110 |
lu |