From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from <gentoo-user+bounces-133113-garchives=archives.gentoo.org@lists.gentoo.org>) id 1Rhezs-0005nj-Dr for garchives@archives.gentoo.org; Mon, 02 Jan 2012 10:20:04 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E62BE21C10E; Mon, 2 Jan 2012 10:19:45 +0000 (UTC) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) by pigeon.gentoo.org (Postfix) with ESMTP id 77FD821C048 for <gentoo-user@lists.gentoo.org>; Mon, 2 Jan 2012 10:18:48 +0000 (UTC) Received: by werm12 with SMTP id m12so9027797wer.40 for <gentoo-user@lists.gentoo.org>; Mon, 02 Jan 2012 02:18:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:reply-to:to:subject:date:user-agent:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=qsQSG+Aqj3aqdFNdm8G4dB2/qnB13eFoJa2iDkXJkiU=; b=UMs3B4nAWpl9AN3aqo/9ZTivNsFNJbad48JSD5q9GlkT0Lafd2GhSFihOg0uXgZqUK +RrdAqKdszEFjk1Y+sgGpLbtfjLNPdfDoKZQSWiHphJdSAwNdjmwpqJ/D29kudShvx8W zPwHkfVFYqXgxRAGmDYeT4ZoTfocuUE9eXsDw= Received: by 10.216.134.162 with SMTP id s34mr26707847wei.59.1325499527528; Mon, 02 Jan 2012 02:18:47 -0800 (PST) Received: from dell_xps.localnet (230.3.169.217.in-addr.arpa. [217.169.3.230]) by mx.google.com with ESMTPS id di5sm116502634wib.3.2012.01.02.02.18.46 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Jan 2012 02:18:46 -0800 (PST) From: Mick <michaelkintzios@gmail.com> To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] emerge --update behavior Date: Mon, 2 Jan 2012 10:18:46 +0000 User-Agent: KMail/1.13.7 (Linux/3.0.6-gentoo; KDE/4.7.3; x86_64; ; ) References: <4F00D521.1030702@orlitzky.com> <4F00F943.4000104@orlitzky.com> <20120102120639.19bc852b@rohan.example.com> In-Reply-To: <20120102120639.19bc852b@rohan.example.com> Precedence: bulk List-Post: <mailto:gentoo-user@lists.gentoo.org> List-Help: <mailto:gentoo-user+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-user.gentoo.org> X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1532762.L1F1W6Hrxv"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201201021018.48743.michaelkintzios@gmail.com> X-Archives-Salt: 79c4136f-3ed4-4018-998d-acaa9c8035bc X-Archives-Hash: 2b87630e96577f261322d8d00ad2818a --nextPart1532762.L1F1W6Hrxv Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Monday 02 Jan 2012 10:06:39 Alan McKinnon wrote: > On Sun, 01 Jan 2012 19:24:35 -0500 >=20 > Michael Orlitzky <michael@orlitzky.com> wrote: > > On 01/01/2012 07:09 PM, Neil Bothwick wrote: > > > On Sun, 01 Jan 2012 18:07:45 -0500, Michael Orlitzky wrote: > > >> Usually it's because a world update wants to do both trivial > > >> version bumps and replace major software at the same time. I can't > > >> take a server down for an hour in the middle of the day to update > > >> Apache, but I can bump timezone-data, sure. > > >=20 > > > Why would you need to take it down? All you need to do is restart > > > Apache after the update. > >=20 > > I have to test, like, 200 websites to make sure they still work. > > Something /always/ breaks. > >=20 > > Apache was just an example. PHP is the same way: functions get > > removed, renamed, or just subtly changed. I can't replace Dovecot > > with users logged in. I can't upgrade/restart postgresql while > > clients are hitting it. If I'm working remotely, I don't want to > > update openvpn, iptables, or even openssh. There's a long list of > > packages that I just ain't gonna mess with during the day. >=20 > You have a production machine delivering valuable services to multiple > users. >=20 > Therefore you must only update *anything* on it during planned > maintenance slots. If paying customers are involved then preferably > with a second redundant parallel machine to take over the load during > that slot. You don't have much of an option about this in the real > world, think of it as a constraint that you must simply deal with. >=20 > Or think about it another way, if the machine was running RHEL, you > wouldn't just blindly run yum update in the middle of the working day > and expect it to all be just fine. +1 Even on binary distros I would be apprehensive to update/upgrade a producti= on=20 machine, unless I have run the updates on the test box first. Even so, bec= ause=20 I do not have the luxury of identical hardware some times the odd thing may= =20 break, but it is a very rare occurrence. With everything running on VMs th= ese=20 days (although not yet my case) this is becoming less of a problem I would= =20 think. =2D-=20 Regards, Mick --nextPart1532762.L1F1W6Hrxv Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEABECAAYFAk8BhIgACgkQVTDTR3kpaLbOnwCgv/mhaVl17hkqtApMaj76YAva zP0An3G/EIfY/jq9XOHoFczTc7aoYuy9 =PQKA -----END PGP SIGNATURE----- --nextPart1532762.L1F1W6Hrxv--