1 |
On Monday 03 May 2004 16:15, Nathaniel McCallum wrote: |
2 |
> Most of your questions below have already been answered in previous |
3 |
> emails. But we'll do it again. |
4 |
|
5 |
|
6 |
|
7 |
> > If genkernel is broken - why not redo^H^H^Hfix genkernel instead? |
8 |
> |
9 |
> Why fix a build system that isn't part of portage when it could be, |
10 |
> fairly easily integrated with portage. |
11 |
|
12 |
|
13 |
|
14 |
> As I mentioned before, I left this fairly ambiguous on purpose. |
15 |
> GentooInstaller will create a solution for this. And if people like it, |
16 |
> we can use it system-wide. |
17 |
|
18 |
Until you address this ambiguity, I don't think this GLEP is safe to approve. |
19 |
|
20 |
> This is no more "risk" than the current genkernel solution. |
21 |
|
22 |
Yes there is. genkernel isn't the default way of installing a kernel. In |
23 |
your emails and in your GLEP, you are stating that your proposal will become |
24 |
default behaviour. That alone increases risk substantially. |
25 |
|
26 |
> Besides, |
27 |
> you can either just make your own custom config or just trigger the use |
28 |
> flag "-buildkernel" and do it the old fashioned way (you can even still |
29 |
> use genkernel if you want). We are talking about 100% backwards |
30 |
> compatability. I'm not removing anyone's choice. |
31 |
|
32 |
It's not the choice I'm looking at. It's the technical merits of your |
33 |
proposal. |
34 |
|
35 |
> This will be dealt with in the same fashion as every other package in |
36 |
> gentoo. |
37 |
|
38 |
> If you re-install it, it re-builds it and replaces the old |
39 |
> kernel. |
40 |
|
41 |
Unless I'm missing something here, isn't that going to leave a machine in an |
42 |
unbootable condition - seeing as you haven't designed a solution for updating |
43 |
the bootloader yet? |
44 |
|
45 |
> emerge -C removes the kernel. Its that simple. |
46 |
|
47 |
What happens if the kernel being removed is the kernel that is currently |
48 |
booted? |
49 |
|
50 |
> Before you |
51 |
> complain that we should be able to have 2 kernels from the same tree, |
52 |
> currently, genkernel doesn't support this without manually copying |
53 |
> files. So this GLEP does not take functionality away that exists with |
54 |
> genkernel. |
55 |
|
56 |
I don't care about genkernel ;-) You started off your reply to me by saying |
57 |
that genkernel is only fit for the scrapheap - and now you're justifying your |
58 |
design by saying "well, it's just the same as genkernel"? |
59 |
|
60 |
> If you want 2 kernels from the same tree, trigger the |
61 |
> "-buildkernel" use flag and just do it the old fashioned way. > Or you |
62 |
> can also "emerge kernel" then manually move the files, then "emerge |
63 |
> kernel" again, which would give you the desired results. Either way |
64 |
> this is the same exact functionality of genkernel. |
65 |
|
66 |
Any well-configured Linux box has at least two kernels in the grub/lilo boot |
67 |
menu - and you'll often see advanced users keep a third entry in there. |
68 |
That's one entry for the new kernel, one entry for the last kernel (in case |
69 |
the new one didn't work), and one entry for a fallback kernel in case the |
70 |
first two get hosed up somehow. These scheme was even supported directly by |
71 |
the kernel's 'make bzlilo' target, which would move kernels from the first |
72 |
slot to the second for you. |
73 |
|
74 |
It would seem prudent (and good for our users) for any new default |
75 |
kernel-building solution to support such a scheme. |
76 |
|
77 |
You haven't addressed 'emerge -u' at all in your reply. |
78 |
|
79 |
> I have several revisions for the GLEP already, I'll try to put them all |
80 |
> in. |
81 |
|
82 |
> I answered this in another email. All we are tracking is the config |
83 |
> files themselves. Users benefit by knowing when we make changes to |
84 |
> kernel config files. That is all I'm saying. |
85 |
|
86 |
How do users benefit? Seriously - I've no idea. I've got four x86 machines |
87 |
in the house running Linux right now, and they all have unique kernel configs |
88 |
to support the differences in hardware. I have trouble visualising how a |
89 |
'one config fits all' approach is going to work. |
90 |
|
91 |
> Thats cause this is an initial draft. However, it will be an external |
92 |
> app. You would call it manually, not as part of an ebuild/eclass. The |
93 |
> program is only needed if you don't want to use/can't use the supplied |
94 |
> generic kernel config. |
95 |
|
96 |
I don't understand how that will work. if 'emerge <kernel-of-your-choice>' |
97 |
downloads, compiles, and installs your kernel automagically - all from the |
98 |
one command - where does the user get to run the external app? Is the user |
99 |
going to run it before the kernel has been downloaded? Is the user going to |
100 |
run the app after the kernel is installed? There doesn't seem to be the |
101 |
possibility of the user running the app in between those two. |
102 |
|
103 |
> > The GLEP says that Stage 2 is not optional - but then goes on to say that |
104 |
> > this stage can be skipped by USE=-buildkernel. This part of the |
105 |
> > Specification is broken. |
106 |
> |
107 |
> It is not optional. In stage 2 you either have to build the kernel |
108 |
> ("buildkernel") or install sources ("-buildkernel"). Either way, you |
109 |
> still have to do stage 2. |
110 |
|
111 |
I think your specification could be improved to make this clear and precise. |
112 |
|
113 |
> The Stage 1 config app would provide for this. Also, the Stage 1 app |
114 |
> *DOES* configure the kernel the traditional way. All it does is make |
115 |
> sure kernel configs get copied to the right place. |
116 |
|
117 |
That needs adding to the specification. |
118 |
|
119 |
> > There's no justification given for creating this kernel tarball. The |
120 |
> > specification does not state where this tarball will be stored, or how it |
121 |
> > will be removed from the system when no longer required. |
122 |
> |
123 |
> I'm not sure what you mean by "kernel tarball". |
124 |
|
125 |
That's because your specification is vague on what will go into the tarball it |
126 |
says will be created in Stage 3. |
127 |
|
128 |
> If you mean the |
129 |
> kernel-headers tarball, it gets removed if you do a emerge -C on the |
130 |
> kernel. It should probably be stored in /usr/src/. |
131 |
|
132 |
Are you sure that keeping just the kernel headers is sufficient? Have you |
133 |
performed tests to validate that you don't need any other files from the |
134 |
kernel in order to compile all of the third-party kernel modules currently in |
135 |
Portage? |
136 |
|
137 |
> What happens if there is a security bug in a kernel (as there have been |
138 |
> about 6 this year)? genkernel can't notify you and portage can only |
139 |
> upgrade your sources if you even used the sources from portage. However |
140 |
> in this GLEP system, "emerge --security" (when it gets implimented) |
141 |
> would see a problem with your kernel, upgrade to the non-buggy kernel, |
142 |
> build it, install it, and remove the old one (or warn you to remove it, |
143 |
> whichever you prefer). |
144 |
|
145 |
That is a good justification - you should add it to your GLEP. |
146 |
|
147 |
> You mean warpzero and I and the members of the kernel team we spoke |
148 |
> with. <sarcasm> We all know how the kernel team knows nothing about |
149 |
> kernels. </sarcasm> |
150 |
|
151 |
Do I mean you and Warpzero? Yes, because your names are on the document as |
152 |
authors. But you haven't run this past johnm yet, and when it comes to |
153 |
kernel stuff him and gregkh are the two I'd put most faith in - and you've |
154 |
already seen Greg's response to your proposal ;-) |
155 |
|
156 |
> I agree with this. This was my first GLEP and as such, I missed some of |
157 |
> the finer points. |
158 |
|
159 |
I think your aim's a bit further off than that ;-) |
160 |
|
161 |
> However, its just a Proposal. And if devs get this |
162 |
> much negative "your idea can't work" criticism from a simple GLEP, how |
163 |
> do you think a Gentoo user would ever feel comfortable filing a GLEP |
164 |
> (which is what they were intended for!). |
165 |
|
166 |
I think any submitted proposal needs to be able to stand up to rigorous |
167 |
technical scrutiny. If the idea has merit, or a groundswell of support, then |
168 |
the proposal will be the better for it. If the idea is weak, flawed, or |
169 |
substantially incomplete - it's important we catch these things now before |
170 |
it's our users catching the results ;-) |
171 |
|
172 |
A commonly-taught method of evaluating any proposal is de Bono's hats - where |
173 |
you look at a proposal from a specific viewpoint. Look it up, and you'll see |
174 |
where I'm coming from. |
175 |
|
176 |
> In the same way as not bashing a user for contributing an ebuild |
177 |
> (remember, they could be a future contributer to Gentoo), we should, |
178 |
> when faced with a GLEP, stop and think if there is anything posative |
179 |
> about it, then try to come up with working scenarios. Remember, devs |
180 |
> are contributers to Gentoo. |
181 |
|
182 |
Yes they are. And you're right - anyone should be able to put forward a GLEP |
183 |
without fear. |
184 |
|
185 |
> Thats also fine with me. I don't want the GLEP approved right away, I |
186 |
> just wanted it to be a sounding board for discussion to develop a good |
187 |
> prototype. Isn't that what a GLEP is for? |
188 |
|
189 |
Maybe it would help if that discussion happened first, and the results were |
190 |
written up into a GLEP for approval. That's happened in the past, and seems |
191 |
a successful model to reproduce. |
192 |
|
193 |
Best regards, |
194 |
Stu |
195 |
-- |
196 |
Stuart Herbert stuart@g.o |
197 |
Gentoo Developer http://www.gentoo.org/ |
198 |
Missed the php|cruise? http://dev.gentoo.org/~stuart/cruise-2004/ |
199 |
|
200 |
GnuPG key id# F9AFC57C available from http://pgp.mit.edu |
201 |
Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C |
202 |
-- |