portmaster: print /usr/ports/UPDATING on update
rwmaillists at googlemail.com
Wed Dec 29 02:48:41 UTC 2010
On Tue, 28 Dec 2010 16:38:57 -0800
Doug Barton <dougb at FreeBSD.org> wrote:
> On 12/28/2010 15:10, RW wrote:
> > On Tue, 28 Dec 2010 10:55:04 -0800
> > Doug Barton<dougb at 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.
More information about the freebsd-ports