Gentoo Archives: gentoo-installer

From: Ti Leggett <leggett@×××××××.gov>
To: gentoo-installer@l.g.o
Subject: Re: [gentoo-installer] Why not GLIS?
Date: Thu, 18 Mar 2004 15:23:54
Message-Id: 1079570468.1813.48.camel@scraz.mcs.anl.gov
In Reply to: Re: [gentoo-installer] Why not GLIS? by Scott Hadfield
1 I'm going to throw in here. I've been using GLIS here to try and get up
2 a custom installer and it's a good first pass but it has severe
3 limitations. While just about everything in the install process can boil
4 down to a command on the shell command line, that does not make bash a
5 natural choice for an install script. Take for example, there is no easy
6 way to do multi-dimensional arrays in bash and doing something as
7 seemingly simple as define 2 raid arrays with different numbers of
8 partitions, becomes increasingly hard to do in bash.
9
10 Also, I've had to make some significant changes to GLIS to get it to do
11 what I'd like it to. Namely, my plan is to be able to install gentoo on
12 clusters of machines that need to be exact, and the build process needs
13 to be fast. I will *not* stand for having to compile a kernel on every
14 install. GLIS got the ball rolling and got people thinking about what's
15 good and bad, but I agree that a new method, that's engineered from the
16 ground up to handle all of these things is "a good thing"(tm).
17
18 Just my piece.
19
20 On Thu, 2004-03-18 at 00:17, Scott Hadfield wrote:
21 > Eric Sammer wrote:
22 >
23 > > Short answer is that it doesn't cover all the features users want.
24 > > (Remember we're talking about users, not just ourselves, etc.)
25 >
26 > It doesn't cover ALL of the features, but it does cover a lot of them.
27 > Just briefly reviewing over the initial specifications:
28 > * Multiple front ends - Definately
29 > * Reusible back end framework - Sort of, but arguably not.
30 > * Automated deployement - Definately
31 > * Dry run profile generation - Yes
32 > * Full support for all Gentoo architectures - I doubt it. And it
33 > definately hasn't been tested on much more than x86
34 > * Specialized profiles - Possible, but no one's done any work to create any.
35 > * Open policies and standards use - No, not really.
36 > * Integration with future configuration projects - No.
37 >
38 > As far as design goes, GLIS is fairly similar to what is specified (at
39 > least as far as my untrained eyes can tell).
40 >
41 > >> It even seems to me that an initial goal of GLI is to get to the
42 > >> point where GLIS is at right now, i.e. working, based on a
43 > >> configuration file, and highly flexible.
44 > >
45 > > It's coincidence. The reason it's being rebuilt is because the
46 > > architecture had to change to accommodate the required features.
47 >
48 > Probably not coincidence, probably just good practice if you want to
49 > write a serious installer. :-)
50 >
51 > >> GLIS is written in bash and made up of about 8 small bash scripts
52 > >> (except for the partition code, which is way too big for bash), and
53 > >> in my opinion this is really all you need for a gentoo installer
54 > >> since all it takes to install gentoo is a few bash commands.
55 > >
56 > > And while it's good that something such as that works for you, there's
57 > > somewhere around 250,000 - 500,000 gentoo users out there (last I
58 > > heard) that this doesn't work for. If it did, they wouldn't be asking
59 > > for something else.
60 >
61 > While, a few bash commands do work for me, but in my next sentence I
62 > said that "GLIS simply takes those commands and puts them into scripts."
63 > Maybe I'm wrong, but I think most of the 250-500 thousand potential
64 > gentoo user's would be willing to type in ./glis to get gentoo
65 > installed, and the rest would be willing to wait for a GUI. Of course
66 > most of those people wouldn't be willing to sit down and take two hours
67 > or so editing the glis config file the first time they do it. And a good
68 > interface to the config file would be a must if glis was going to be
69 > taken seriously.
70 >
71 > >> I've followed this installer project from its beginning in January,
72 > >
73 > > This may come off wrong, but if you've been following it since its
74 > > beginning, the differences in goals between GLIS and the GLI should be
75 > > clear, as should the need for the GLI.
76 >
77 > This is partially the main reason I wrote this email now, and not in
78 > January. Perhaps I just need it spelled out for me. As I said
79 > previously, to install gentoo takes a few bash commands, these commands
80 > would fit ideally into a bash script. There's a few areas that this idea
81 > fails though, as can be proven just by reading over the partitioning
82 > code in glis. Bash is not an ideal language to write a partitioner, 400
83 > lines of bash code full of nested loops is just too much for any normal
84 > person to handle. Another area where this fails is in editing system
85 > config files, the way glis does this, in my opinion, is not pretty and
86 > full of potential bugs. I think it would be very difficult to write a
87 > good, stable config parser/editor in bash.
88 >
89 > So, I do understand a few of the reason's for GLI, but after two months
90 > the difference is still not fully clear to me.
91 >
92 > >> but it seems like most of core developer's don't have as much spare
93 > >> time to devote to the project as they may have initially thought.
94 > >
95 > > Not entirely true... just because cvs activity isn't streaming,
96 > > doesn't mean it's not being worked on.
97 >
98 > I didn't mean to imply that no work had been done or that the work that
99 > has been done is not significant. I believe quite the opposite, all I
100 > was trying to imply was that the project may take a bit longer than
101 > previously thought. (I'm aware that no one has really even given a
102 > ballpark estimate of the eta for gli, but I think it's hard to argue
103 > that it's progressing as fast as it seemed it would at the end of January).
104 >
105 > >> If you adopted GLIS as gentoo's installer right now then at least
106 > >> gentoo would have something, and in 6-12 months when GLI is done you
107 > >> could switch over it.
108 > >
109 > > Unfortunately, that would cause even further upset. See, if you
110 > > introduce something new, get them to learn it, and then replace it
111 > > with something with a very different feature set and design, well,
112 > > you'll piss people off.
113 >
114 > This is something I definately overlooked. But how different will the
115 > feature set actually be? The way I see it GLI will have (pretty much)
116 > everything GLIS had but way more, and be way cooler. Of course the
117 > configuration file will be completely different and somebody who's use
118 > to the GLIS config file would likely be pissed at having to switch.
119 > However, I'm not convinced that this is a real issue. If people are
120 > upset that gentoo switched "official" installers then so-be-it, it's not
121 > like they won't be able to use the old way anymore and it's not like
122 > they chose gentoo because of it's cool assed installer. I'm just trying
123 > to say, if GLI was lacking in features compared to GLIS, I'd sympathize
124 > with the pissed-off, otherwise, as long as they were given sufficient
125 > warning, I wouldn't be too worried about them.
126 >
127 > > It's a bit more complicated than that. There's more to application
128 > > design than drawing two boxes on a white board and labeling one
129 > > "Backend" and one "GUI" no matter what people say.
130 >
131 > For a lot of applications I would agree, but not for this one. If a gui
132 > was developed for glis and then we wanted to switch it to gli, with the
133 > foresight that it would be switched, it could easily be made up of three
134 > main parts. 1) reading in the config 2) asking the user questions 3)
135 > writing the config. 1 and 3 would need to be completely rewritten for a
136 > different installer, 2 (which is the essence of the GUI and most
137 > difficult) could remain largely the same, except for maybe a few more
138 > features that would need to be added to it.
139 >
140 > > there have probably been few bugs in GLIS because it doesn't meet the
141 > > needs of the majority of users.
142 >
143 > You're probably right. Small user base generally equals small number of
144 > bugs found. But I think glis doesn't meet the needs of the majority for
145 > two main reasons, 1) no interface to the config file 2) no one really
146 > knows about it.
147 >
148 > > As a (rather contrived) for-instance...
149 > >
150 > > We build an installer like GLI with multiple front ends,
151 > > auto-deployment for large networks, reusable... [SNIP] The world is a
152 > > better place. Gentoo is a better distro. Linux gains more acceptance.
153 > >
154 > It's a nice story, but I'm not really sure I see it's relevance to not
155 > using GLIS. In fact I see exactly the opposite, why hold an installer
156 > back only to delay the world being a better place ;-).
157 >
158 > Basically, I was just seeing if anyone thought it would be a worthwhile
159 > idea to adopt glis as an "unofficial-official" installer until gli is
160 > ready, develop a working UI that could be easily interchanged between
161 > both, and give the user's a little something right now. There's a lot of
162 > issues involved in doing this and perhaps for now it's best to just
163 > remain focussed on one installer instead of having the worry of two.
164 >
165 > Thanks for your reply though, it definately cleared a few things up for me.
166 >
167 > Scott
168 >
169 > --
170 > gentoo-installer@g.o mailing list
171 >
172
173
174 --
175 gentoo-installer@g.o mailing list