portmaster: print /usr/ports/UPDATING on update

[Doug Barton]

On 12/28/2010 15:10, RW wrote:
> On Tue, 28 Dec 2010 10:55:04 -0800
> Doug Barton<dougb at FreeBSD.org>  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/