OPTIONS (was: editors/vim installs to /)

[David O'Brien]

On Wed, Oct 06, 2010 at 02:12:18PM +0200, David DEMELIER wrote:
> 2010/10/5 David O'Brien <obrien at freebsd.org>:
> > On Sun, Oct 03, 2010 at 10:22:46AM +0200, David DEMELIER wrote:
> >> 2010/10/2 David O'Brien <obrien at freebsd.org>:
> >> > 2. With the way OPTIONS handling is done, there isn't a way for me
> >> > to query if I built with the defaults or not.
> >> > Thus leading to every port I manually install looking like it was
> >> > customized just because /var/db/ports/${PORTNAME} exists. Â Thus
> >> > implying I can no longer install the pre-build package.
> >>
> >> make rmconfig ?
> >
> > I think you've missed my point.
> >
> > That does not tell me if I, in the past, made a decision that did not
> > like the maintainer's defaults, or if I just wanted to extract the
> > sources so I could read the license or figure out what the OPTIONS knobs
> > were about, etc..
> 
> I understood, you prefere a file like make.conf or ports.conf to see
> which options/knob is defined, isn't it ?

That is true - but doesn't isn't really what's behind #2 above.

In this case, I really want to now which packages are OK to upgrade using
'portupgrade -PP' (or portmaster) -- to quickly do upgrades using the
pre-built packages Portmgr spends a lot of time making available to us.

I use a script that looks for a non-zero byte /var/db/ports/$PKG/options
or any $PKG knobs in /etc/make.conf.  If either is found, then
'portupgrade -PP', else just 'portupgrade'.

This is where things like 'make extract' cause a problem - since one
cannot even extract without going thru OPTIONS dialog.

-- 
-- David  (obrien at FreeBSD.org)
Q: Because it reverses the logical flow of conversation.
A: Why is top-posting (putting a reply at the top of the message) frowned upon?
Let's not play "Jeopardy-style quoting"