1 |
Am Fri, 07 Oct 2011 09:59:54 -0400 |
2 |
schrieb Michael Orlitzky <michael@××××××××.com>: |
3 |
|
4 |
> On 10/07/2011 03:36 AM, Jonas de Buhr wrote: |
5 |
> > Am 07.10.2011 02:55, schrieb Michael Orlitzky: |
6 |
> >> On 10/06/11 19:42, Jonas de Buhr wrote: |
7 |
> >>>> If we have some grub-legacy and some grub2 installs, |
8 |
> >>> why would you do that? |
9 |
> >> Eventually, grub2 will be all that's available from portage. At |
10 |
> >> that point, I can either, |
11 |
> >> |
12 |
> >> 1) Install grub2 on some machines. |
13 |
> >> |
14 |
> >> 2) Maintain grub-legacy (and install media) myself. |
15 |
> > |
16 |
> > i really don't think thats the way its going to be. i think there |
17 |
> > will be grub and grub2 in portage potentially forever. like with |
18 |
> > python 2 and 3. |
19 |
> > |
20 |
> > even if not, 2) takes you one cp command and a little bit of disk |
21 |
> > space for the grub tarball. |
22 |
> |
23 |
> Python2 will stick around because most packages (portage!) don't work |
24 |
> with python3. Grub doesn't have the same problem. |
25 |
> |
26 |
> (2) requires me to at least, |
27 |
> |
28 |
> * Figure out how to build a Gentoo install CD |
29 |
> * Fork grub-legacy on our servers somewhere |
30 |
|
31 |
build a package and put it on an ftp. monitor the bug-grub mailing list |
32 |
for critical bugs. repeat. |
33 |
or mirror it daily and autobuild the package. |
34 |
no need to build an install cd or fork grub. but it is true that this is |
35 |
less convenient than portage. its probably less work to switch to grub2 |
36 |
IF grub legacy really ever gets thrown out of portage. mixing both is |
37 |
the worst idea in my opinion. |
38 |
|
39 |
> * Test it against all future kernel releases |
40 |
> * Document why we're doing this, and how to do the first three |
41 |
> steps. |
42 |
> |
43 |
> |
44 |
> >> * Upgrade a bunch of my servers at 4am? |
45 |
> > why not choose a convenient time to upgrade? |
46 |
> |
47 |
> 4am *is* the convenient time to upgrade. |
48 |
> |
49 |
> >> If you still think it's "not much" then I'd be happy to have you |
50 |
> >> do it while I drink margaritas. |
51 |
> > no, i still don't think its as much of a big deal as you make of |
52 |
> > it. about as much work as a kernel upgrade. let's wait for grub2 to |
53 |
> > go stable before you send me that ticket ;) |
54 |
> |
55 |
> This fails as a debate strategy since you wouldn't have to pay my |
56 |
> mortgage and feed me if you screwed up =) |
57 |
|
58 |
hey, that was *your* idea in the first place ;) |
59 |
|
60 |
> Kernel upgrades usually take me a full day. I get to skip most of the |
61 |
> documentation step, but have to deal with heterogeneous configs. |
62 |
|
63 |
out of interest: why do you have different configs? even if you have |
64 |
different hardware you could still build a "one fits all"-kernel. or |
65 |
are they that specialized? |
66 |
|
67 |
>I'm |
68 |
> not saying that this is some huge problem on a cosmic scale, but it |
69 |
> is going to waste a day and risk downtime for no user-visible benefit. |
70 |
|
71 |
lets just agree on that. im kinda tired of this discussion. there's |
72 |
nothing we can do about it anyway. |