Date: Wed, 29 Dec 2010 02:48:35 +0000 From: RW <rwmaillists@googlemail.com> To: ports@freebsd.org Subject: Re: portmaster: print /usr/ports/UPDATING on update Message-ID: <20101229024835.53e0c155@gumby.homeunix.com> In-Reply-To: <4D1A8321.1000801@FreeBSD.org> References: <4D15D275.6000308@gmail.com> <4D194421.9080304@FreeBSD.org> <SaPpQ%2B%2BiANujx2z50Bs5SbHA8lc@QsmfhJNucgI88DfvPJdT1/nyboE> <4D1A3288.70604@FreeBSD.org> <20101228231012.76520263@gumby.homeunix.com> <4D1A8321.1000801@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 28 Dec 2010 16:38:57 -0800 Doug Barton <dougb@FreeBSD.org> wrote: > On 12/28/2010 15:10, RW wrote: > > On Tue, 28 Dec 2010 10:55:04 -0800 > > Doug Barton<dougb@FreeBSD.org> wrote: > > 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. It's not really a question of classification, the issue is that some entries will cause ports to be permanantly noteworthy. At the moment I see that perl entry once (I diff UPDATING). What if I don't want to switch for months? Is it going to show me that information over and over again until I do? Is it going to recorded that I read it, do I have to manually acknowledge it? > > 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. > > 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. I was thinking in terms of abstracting it, so that it describes what need to be done, rather than how.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101229024835.53e0c155>