On 3/31/14 3:47 PM, Kevin Oberman wrote: > This is something I've wanted to have for quite a while, but never > enough to dig through the Makefiles. > > I think the proper way would be for "make showconfig" to print out the > current config as it does now, but to tag default options (e.g. '+') so > that it would be easy to note that some option that you never touched > and probably don't really even understand had had the default changed > and you probably want to match that change.
There are two dimensions, though, and the showconfig annotations you
describe captures just one of them.
1. Is this option set the same as the default?
2. Is this an option I care about pinning?
Your proposal addresses #1. I already solved this for myself in an
ad-hoc manner. I placed an additional requirement on my solution that it
generate machine-readable output. Incidentally, there was a compelling
thread a few months ago which briefly discussed [0] the possibility of
teaching core CLI tools to output structured data like XML, JSON, etc.
The ports machinery would be another great candidate for that kind of
capability.
Anyway, I used the information from #1 as hints about what I was
thinking about #2 at the time I originally configured the port. Then I
put ${OPTIONS_NAME}_SET=FOO and ${OPTIONS_NAME}_UNSET=BAR in make.conf
as a way to express and record #2.
For example:
devel_git_SET= GITWEB GUI
editors_vim_UNSET= RUBY
I can feed this, and little else, to poudriere and remain confident that
as long as devel/git knows about the options GITWEB and GUI, and
editors/vim knows about the option RUBY, I can update my ports tree and
rebuild my packages until the sun comes up and those options will remain
pinned.
> A 'pkg info' option to provide a list of changed defaults in installed
> ports would be even nicer. Something equivalent to "pkg version -vl\<"
> perhaps. But just doing it in "make showconfig" would make a script that
> would parse 'pkg version' optput and do a "make showconfig", only
> printing out the tagged lines, when any changes are noted would be trivial.
Would pkg-info be the place for this? It's looking at state data that
has no notion of history. pkg-info could show available options,
defaults, and built-with options, all as of build-time. It would be up
to pkg-upgrade to send up a flare, on request, if these sets changed
from the currently-installed package to the about-to-be-installed package.
I would also be interested in an equivalent a poudriere feature, because
it's at the moment I update a ports tree in preparation for building new
packages that I want to know if a port I build just grew a new option
that I might want to pin per #2.
Regards,
John
[0]
http://lists.freebsd.org/pipermail/freebsd-stable/2013-December/076205.html
signature.asc
Description: OpenPGP digital signature
