From owner-freebsd-current@FreeBSD.ORG Tue Jun 15 14:07:22 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2AD8106567F for ; Tue, 15 Jun 2010 14:07:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6F5448FC15 for ; Tue, 15 Jun 2010 14:07:22 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 071F146C0B; Tue, 15 Jun 2010 10:07:22 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DEC718A04E; Tue, 15 Jun 2010 10:07:20 -0400 (EDT) From: John Baldwin To: Garrett Cooper Date: Tue, 15 Jun 2010 09:49:47 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <201006101346.59824.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006150949.47185.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 15 Jun 2010 10:07:20 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: current@freebsd.org Subject: Re: RFC: etcupdate tool in base? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 14:07:22 -0000 On Monday 14 June 2010 5:22:32 pm Garrett Cooper wrote: > On Thu, Jun 10, 2010 at 10:46 AM, John Baldwin wrote: > > I've had several folks ask me recently about importing etcupdate > > (http://www.FreeBSD.org/~jhb/etcupdate) into the base system as an alternate > > tool for updating /etc during upgrades. Do folks have any strong objections > > to doing so? More details about how it works and an HTML version of the > > manpage can be found at the URL above. > > Finally got around to looking at this. > > Some comments: > > 1. Script doesn't check to see whether or not it has write access (and > doesn't catch some errors): > > $ etcupdate > mkdir: /var/db/etcupdate: Permission denied > /usr/sbin/etcupdate: cannot create /var/db/etcupdate/log: No such file > or directory > > Eventually it stops though, so maybe it's not really a big issue... It does actually check, but it does so after it opens the log file. :-/ > 2. Some messages are a bit misleading: > > $ etcupdate > /usr/sbin/etcupdate: cannot create /var/db/etcupdate/log: Permission denied > $ ls -l /var/db/etcupdate/log > -rw-r--r-- 1 root wheel 0 Jun 14 14:06 /var/db/etcupdate/log > $ whoami > garrcoop That is the shell complaining due to this: exec 3>$LOGFILE Arguably the shell is emitting the correct message since it is attempting to recreate the file. > 3. Workflow comments. > > i. Ok... I know I'm doing a downgrade, but what now? > > $ sudo etcupdate > No previous tree to compare against, a sane comparison is not possible. > > ii. Did a bit more reading, and I think that `etcupdate build' is what > I want... but it wasn't happy when I did that: Did you read this part of the manpage: EXAMPLES If the source tree matches the currently installed world, then the fol- lowing can be used to bootstrap etcupdate so that it can be used for future upgrades: etcupdate extract To merge changes after an upgrade via the buildworld and installworld process: etcupdate To resolve any conflicts generated during a merge: etcupdate resolve Also, the README file at http://www.FreeBSD.org/~jhb/etcupdate/ may be useful. > $ sudo etcupdate build > Missing required tarball. > > usage: etcupdate [-nBF] [-d workdir] [-r | -s source | -t tarball] [-A patterns] > [-D destdir] [-I patterns] [-L logfile] [-M options] > etcupdate build [-B] [-d workdir] [-s source] [-L logfile] [-M options] > > etcupdate diff [-d workdir] [-D destdir] [-I patterns] [-L logfile] > etcupdate extract [-B] [-d workdir] [-s source | -t tarball] [-L logfile] > [-M options] > etcupdate resolve [-d workdir] [-D destdir] [-L logfile] > etcupdate status [-d workdir] > > So uh... ok? Manpage and usage were a bit confusing (but not too bad). > After I fixed my arguments, here's what I came up with: > > $ sudo etcupdate build -s /data/scratch/src/stable/8/ > /root/etcupdate-stable8.tbz > $ sudo etcupdate extract -t /root/etcupdate-stable8.tbz > $ You could just do 'etcupdate extract -s /data/scratch/src/stable/8' in this case. :) However, when you do an extract, you are doing a one-time bootstrap. This step needs to be pointed at a source tree that matches what you already have installed. You can do an 'etcupdate diff' after the extract to see what local differences you have and make sure those look sane. Once you have done this, then you can use etcupdate for future upgrades by just running 'etcupdate'. -- John Baldwin