1 |
On 07/18/2015 11:30 PM, J.Rutkowski wrote: |
2 |
> |
3 |
> |
4 |
> On Sat, Jul 18, 2015, at 07:06 PM, hasufell wrote: |
5 |
> |
6 |
>> The handbook consists of different sections. Installation is only one of |
7 |
>> them. An installer would just "replace" that part, not the others. |
8 |
> |
9 |
> Agreed. I think that any proposed or actual installer shouldn't replace |
10 |
> any part of the handbook (and most would probably say the same). My |
11 |
> opinion is that an installer should follow the steps (in order) already |
12 |
> outlined in the handbook and up front, leave the rest to automation. |
13 |
> Nothing then changes in the installation and configuration process. The |
14 |
> only difference is making all choices up front and let the installer do |
15 |
> the rest by itself. |
16 |
> For example, once I prepare my disks I tell the installer "I want x, y, |
17 |
> or z stage3; I want openrc or systemd; I want x,y, or z profile; I want |
18 |
> the following xxx in my kernel; etc." then set it and forget about it |
19 |
> til morning. |
20 |
|
21 |
|
22 |
I agree with what has been stated so far. I would just like to add that |
23 |
eventual support for embedded platforms like PPC, arm (particular |
24 |
arm8v) as well as new files systems like btrfs would been keenly |
25 |
appreciated, even if they are not yet specifically mentioned in the |
26 |
handbook. I.E. I see no reason to limit the new installer to what is |
27 |
strictly included in the handbook. Maybe those more aggressive (wider |
28 |
support) hardware issues are better off being tested in an experimental |
29 |
version(s) of the installer first. The handbook moves at a glacial pace |
30 |
and that's OK, but experimental versions of the installer could be |
31 |
targeted at the rich variety of gentoo and gentoo-derived installs; |
32 |
whilst a stable version mirrors the handbook? |
33 |
|
34 |
|
35 |
Also, I'd like the new installer to use usb media and persistence as the |
36 |
primary media for installation. Many new devices do not readily connect |
37 |
to cd/dvd type devices; maybe this is another stable vs experimental |
38 |
issue for the installer, rather than trying to create one system for |
39 |
disparagingly differ installation semantics. In that venue maybe |
40 |
resurrecting 'netconsole' code as a way to stream the output remotely |
41 |
is another approach for installing on smaller devices? |
42 |
|
43 |
hth, |
44 |
James |