1 |
On 2014-02-20 4:04 PM, Canek Peláez Valdés <caneko@×××××.com> wrote: |
2 |
> On Thu, Feb 20, 2014 at 2:06 PM, Tanstaafl wrote: |
3 |
>> Thinking about this more, since apparently using a separate |
4 |
>> profile may just be 'overkill', how about something simpler, like, |
5 |
>> for example, using eselect... |
6 |
>> |
7 |
>> Something like: |
8 |
>> |
9 |
>> # eselect init list |
10 |
>> Available init systems: |
11 |
>> [1] OpenRC * |
12 |
>> [2] systemd |
13 |
>> [3] runit |
14 |
>> |
15 |
>> (whatever choices are supported). |
16 |
|
17 |
> the switching requires reemerging things because you need to set some |
18 |
> USE flags and quit others. That's the "difficult" (which is not, |
19 |
> really) part; if you set the USE flags yourself or via a profile, or |
20 |
> an eselect module, I don't think the difference matters atall. |
21 |
|
22 |
Ok, so, since it really is so simple, wouldn't it be easier to implement |
23 |
this as an eselect module then, as opposed to creating a bunch of |
24 |
separate profiles? |
25 |
|
26 |
(NOTE: to those who might argue it is so trivial that even adding an |
27 |
eselect module is overkill, I would respond: |
28 |
|
29 |
We have eselect modules for changing active profiles and for switching |
30 |
active kernels, and as far as I know, all those do is manage a symlink |
31 |
(/etc/portage/make.profile for the active profile, and /usr/src/linux).) |
32 |
|
33 |
Then, if/when a user attempted to switch, eselect could simply spit out |
34 |
a warning message about what precisely would be required to complete the |
35 |
switch (and this message could be kept updated if/when these |
36 |
requirements change), including scary warnings about breakage if they |
37 |
fail to complete the steps necessary, then prompt them for confirmation |
38 |
(default [n], so an explicit [y] required to execute the change)? |
39 |
|
40 |
I'd also suggest throwing in a test for current running kernel config, |
41 |
to make sure it fully supports booting with systemd, and maybe a new |
42 |
emerge command that can also be maintained to make sure that *all* |
43 |
necessary packages are rebuilt? |
44 |
|
45 |
I know, I know, talk is cheap, but again, if systemd proponents want |
46 |
systemd on gentoo to ever become a reasonably simple option (or even |
47 |
eventually become the new default), I think it is necessary for these |
48 |
tools to be built anyway as part of the vetting process, and ultimately |
49 |
to provide as many (automated) safeguards as possible to keep new and |
50 |
even existing gentoo users from shooting themselves in the foot when |
51 |
installing it. |
52 |
|
53 |
So, the reason I'm explicitly asking is I'd really like for this thread |
54 |
to result in a formal feature request to properly shepherd the addition |
55 |
of systemd as an optional init system for gentoo, including managing the |
56 |
process of switching to it (and back again if desired). |
57 |
|
58 |
Thanks to all who participated in this thread... |