From owner-freebsd-ports@FreeBSD.ORG Wed Dec 29 00:38:59 2010 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C06A106566C for ; Wed, 29 Dec 2010 00:38:59 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 466F38FC14 for ; Wed, 29 Dec 2010 00:38:58 +0000 (UTC) Received: (qmail 31943 invoked by uid 399); 29 Dec 2010 00:38:58 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 29 Dec 2010 00:38:58 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4D1A8321.1000801@FreeBSD.org> Date: Tue, 28 Dec 2010 16:38:57 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101210 Thunderbird/3.1.7 MIME-Version: 1.0 To: RW References: <4D15D275.6000308@gmail.com> <4D194421.9080304@FreeBSD.org> <4D1A3288.70604@FreeBSD.org> <20101228231012.76520263@gumby.homeunix.com> In-Reply-To: <20101228231012.76520263@gumby.homeunix.com> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org Subject: Re: portmaster: print /usr/ports/UPDATING on update X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2010 00:38:59 -0000 On 12/28/2010 15:10, RW wrote: > On Tue, 28 Dec 2010 10:55:04 -0800 > Doug Barton wrote: > > >> When I wrote, "we need a tool with striking similarities to >> portaudit" without providing the details I was assuming that people >> are already familiar with it, how it works, etc. > > I don't think it's quite as simple as dealing with vulnerabilities. For > example 20100715, the announcement of lang/perl5.12. This affects all > version of lang/perl5.10 (and IMO any ports that depend on perl). > At the moment, I read it once, make a mental note, and come back to it > when I need it. I don't think a portaudit style tool could handle it > as well. Sure it could, you just have to use a little imagination. :) You'd need categories of entries. Eygene touched on this in his post, but you'd want things that are relevant pre- and post-upgrade, optional elements (like the one you pointed out), etc. > If you update ports regularly, UPDATING is a non-issue. I can skip the > irrelevant entries in seconds. To me the chief problems are delayed > entries and incomplete entries. Good point you're making #1, I'm looking at this from the standpoint of, "I just inherited this system that hasn't had ports updated in 14 months. Where do I start in order to not make a complete mess?" Now the obvious/flippant answer is, "You start over from scratch," but that's not always possible. > What I think would make it worthwhile is it it could abstract all > those simple update recipes like recursive updates, deleting packages, > moving origins, so that a build tool could roll them up and handle > them automatically. ... and this is good point #2. There are a lot of entries in UPDATING of the form, "If you use tool X, do Y; if you use tool A, do B. I'd like to see a standardized form of representing that kind of thing so that users of portmaster would see just the instructions relevant to them, for example. For the most part this wouldn't be hard to do, especially for the -o and -r type entries. For the more complex stuff it may be necessary to have separate entries per-tool, but once again that's not particularly hard to do. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/