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