From owner-freebsd-x11@FreeBSD.ORG Sun Feb 1 18:18:11 2009 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91277106564A for ; Sun, 1 Feb 2009 18:18:11 +0000 (UTC) (envelope-from tundra@tundraware.com) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) by mx1.freebsd.org (Postfix) with ESMTP id 37BC98FC0C for ; Sun, 1 Feb 2009 18:18:10 +0000 (UTC) (envelope-from tundra@tundraware.com) Received: from [192.168.0.2] (viper.tundraware.com [192.168.0.2]) (authenticated bits=0) by ozzie.tundraware.com (8.14.3/8.14.3) with ESMTP id n11IHxlB091302 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Sun, 1 Feb 2009 12:17:59 -0600 (CST) (envelope-from tundra@tundraware.com) Message-ID: <4985E752.3080503@tundraware.com> Date: Sun, 01 Feb 2009 12:17:54 -0600 From: Tim Daneliuk Organization: TundraWare Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: freebsd-x11@freebsd.org References: <200901311153.58361.vehemens@verizon.net> <1233507786.61410.9.camel@RabbitsDen> In-Reply-To: <1233507786.61410.9.camel@RabbitsDen> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-tundraware.com-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: n11IHxlB091302 X-tundraware.com-MailScanner: Found to be clean X-tundraware.com-MailScanner-From: tundra@tundraware.com X-Spam-Status: No Subject: Re: Unhappy Xorg upgrade X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2009 18:18:11 -0000 Alexandre "Sunny" Kovalenko wrote: > On Sat, 2009-01-31 at 16:25 -0500, Alex Goncharov wrote: >> ,--- You/vehemens (Sat, 31 Jan 2009 11:53:58 -0800) ----* >> | In general when upgrading, you take your chances. If a port upgrade >> | fails, you should fall back to what worked. >> >> So, a *fundamental* (practically an OS component) port is brought in >> -- and it disables my system. What is my way of action? Right -- >> install the old packages, taken from an FTP site (is there a way to >> get the previous "source", that is all the ports/*/*/Makefile files? >> Csup can only go forward -- or can it go back?) >> >> When I install the old packages, I can no longer rebuild and install >> new (say `csup'ed on 2009-03-01) port components, as one whole -- I >> can only do it selectively, excluding from the upgrade most >> X-dependent things. That sucks and will lead to a problem earlier or >> later. > Will combination of sysutils/portdowngrade and HOLD_PKGS variable > in /usr/local/etc/pkgtools.conf accomplish what you are trying to > accomplish? > I spend a fair amount of time doing data center consulting professionally, and the idea of incremental upgrade/ regressions terrifies IT operations people. New production systems are first tested in a non-production mode, and then staged to production. In light of these kinds of issues, some time ago, I came up with a scheme to do "snapshots" of running FreeBSD (or Linux, for that matter) systems. This makes easy to (re)image a given server with a known good production configuration. It is built around an almost trivial backup shell script I did a long time ago: http://www.tundraware.com/Software/tbku/ Specific FreeBSD imaging info using 'tbku' is there as well: http://www.tundraware.com/Software/tbku/Imaging-FreeBSD-With-tbku.html This general approach has saved my on a number of occasions, and I regularly shoot system snapshots of my stable server configurations "just in case"... ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/