Gentoo Archives: gentoo-dev

From: Tom Wijsman <TomWij@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] eselect init
Date: Sun, 26 May 2013 12:12:08
Message-Id: 20130526141000.2f3a974e@TOMWIJ-GENTOO
In Reply to: Re: [gentoo-dev] eselect init by Robert David
1 On Sun, 26 May 2013 12:01:19 +0200
2 Robert David <robert.david.public@×××××.com> wrote:
3
4 > Newer say that wrapper will grow openrc size, and also dont know why
5 > it would be bad.
6
7 That's what I'd like to know from him, I was quoting both of you,
8
9 > I really dont know how many user will switch inits and how many of
10 > them will do this regularly.
11
12 Users that would like to compare things, users that are bothered by one
13 init system and try to try an alternative one; developers that want to
14 test both init scripts and service units and thus need to change often,
15 people that would want a specific init system but haven't found out how
16 to switch properly to it yet. I think there are more than a hand full.
17
18 > But the wrapper will be executed every boot. So even a tiny mistake
19 > can produce booting problems even for those who did not wanted to
20 > change anything in init process.
21
22 One would properly test the wrapper, perhaps even have multiple members
23 of arch teams test it, before bringing this out to the user base; it's
24 a very critical matter and we can indeed not afford a mistake here.
25 That being said, once the wrapper is in place and works; I don't think
26 we need to touch it often, it's just a wrapper after all. Do other
27 wrappers, desktop files and files of similar nature we use around
28 Gentoo change often; I think not.
29
30 > On the other hand mistake in some system process will affect only
31 > those who would actually switching. It is only calculation of
32 > possible risks.
33
34 If you do risk assessment, you should count in all risks; that
35 therefore also means to take maintainability into account. See my other
36 mail about what it takes to step away from a loosely coupled approach.
37
38 > I also did not say it must be done the reboot way I mentioned, this is
39 > only and different point what can be though about.
40
41 And we're thinking it through, I don't see why you mention this; I can
42 understand that you don't necessarily stand behind it though, that's OK.
43
44 > >
45 > > I'd rather have a clean wrapper that just works than an unclean way
46 > > to cover the reboot madness that comes along; forcing a reboot,
47 > > really?
48 > >
49 >
50 > I do not see point not forcing reboot when I'm switching init, or let
51 > say suggesting. When you update your kernel config, rebuild and
52 > install you also can stay working, but you have to be prepared to have
53 > nonworking modules that was not inserted before.
54
55 My point was that with a wrapper you don't need to force this; the
56 modules problem is irrelevant to this discussion, I don't see any
57 problem in that light with the approaches we are discussing here.
58
59 PS: If this message ends up in a separate thread, it's because I'm
60 forwarding it from my Sent mail because there was no reply-to present.
61
62 --
63 With kind regards,
64
65 Tom Wijsman (TomWij)
66 Gentoo Developer
67
68 E-mail address : TomWij@g.o
69 GPG Public Key : 6D34E57D
70 GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D

Attachments

File name MIME type
signature.asc application/pgp-signature