Date: Sun, 30 Mar 2014 17:13:15 -0400 From: "John W. O'Brien" <john@saltant.com> To: FreeBSD Ports <freebsd-ports@freebsd.org> Subject: Discover stored options different from port defaults/defines Message-ID: <533888EB.2060503@saltant.com>
next in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Qq8wlt8r93sV1uGiMjOlUN47d0aooSCeq
Content-Type: multipart/mixed;
boundary="------------020709060304000201070301"
This is a multi-part message in MIME format.
--------------020709060304000201070301
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hello ports@,
In the bad old days before poudriere and various improvements to
OptionsNG came to town, when I was using portmaster* to handle upgrades,
I cobbled together a configuration management practice that involved
using rsync and git to store /var/db/ports in a repository. The usual
workflow looked roughly like this:
svn up /usr/ports
portmaster -dga
# handle changes to OPTIONS_DEFINE and its brethren here
rsync -rpt --del --exclude distfiles /var/db/ports/ /path/to/repo
cd /path/to/repo
git commit -a -m "Store options that changed"
A downside of this approach is that it couldn't distinguish between
options I care about ("Always do this" and "Never do this") and options
I don't care about ("Do what the maintainer thinks is best"). The only
upstream changes that would bubble to the surface of their own accord
were NEW_OPTIONS when OPTIONS_DEFINE changed.
When I switched from portmaster to poudriere+pkgng, I migrated
/var/db/ports to /usr/local/etc/poudriere.d/$jail-$ports-$set-options
and that worked OK for a little while. However, this compounded the old
problem in that now even NEW_OPTIONS would arrive silently.
The first part of my solution to these problems is to store only the
options that I know I care about. That is, I know I need to find out
where a stored option disagrees with the default.
I couldn't figure out how to use the stock tools to peel apart currently
stored options from current default options, so I wrote a
``nondefaultconfig`` target for Mk/bsd.port.mk (see attached), set all
the common options (DOCS, IPv6, etc) explicitly in /etc/make.conf using
OPTIONS_SET/OPTIONS_UNSET, and ran the new target against all of my
installed ports, replacing a subtree full of options files with a
single, quite modest make.conf. To make this more generally-useful, it
would need to behave more like NEW_OPTIONS.
cd /usr/ports
pkg info -aoq | sort | xargs -n1 make nondefaultconfig -C \
>> /usr/local/etc/poudriere.d/$jail-make.conf
rm -fr /usr/local/etc/poudriere.d/$jail-$ports-$set-options
At this point, any option not configured by $jail-make.conf will be
allowed to vary according to the whims of the maintainer. The next part
of the problem that I would like to solve is learning about options that
I don't yet know I care about (OPTIONS_DEFINE gains a member), and
secondarily to learn when an option is past caring (OPTIONS_DEFINE loses
a member that I used to care about), so that I can update
$jail-make.conf in an orderly fashion.
I welcome any comments on my approach so far, or suggestions about how I
might proceed.
Regards,
John
* Made the bad old days less bad.
--------------020709060304000201070301
Content-Type: text/plain; charset=UTF-8;
name="patch-Mk__bsd.port.mk-nondefault.txt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="patch-Mk__bsd.port.mk-nondefault.txt"
SW5kZXg6IE1rL2JzZC5wb3J0Lm1rCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIE1rL2JzZC5wb3J0Lm1r
CShyZXZpc2lvbiAzNDk1OTcpCisrKyBNay9ic2QucG9ydC5tawkod29ya2luZyBjb3B5KQpA
QCAtNjA2MCw2ICs2MDYwLDI3IEBACiAuZW5kaWYKIC5lbmRpZiAjIGNvbmZpZy1jb25kaXRp
b25hbAogCitOT05ERUZBVUxUX09QVElPTlNfU0VUPQorTk9OREVGQVVMVF9PUFRJT05TX1VO
U0VUPQorLmZvciBvcHQgaW4gJHtBTExfT1BUSU9OU30KKy4gICBpZiBlbXB0eShPUFRJT05T
X0RFRkFVTFQ6TSR7b3B0fSkgJiYgIWVtcHR5KFBPUlRfT1BUSU9OUzpNJHtvcHR9KSAmJiBl
bXB0eShPUFRJT05TX1NFVDpNJHtvcHR9KQorTk9OREVGQVVMVF9PUFRJT05TX1NFVCs9JHtv
cHR9CisuICAgZW5kaWYKKy4gICBpZiAhZW1wdHkoT1BUSU9OU19ERUZBVUxUOk0ke29wdH0p
ICYmIGVtcHR5KFBPUlRfT1BUSU9OUzpNJHtvcHR9KSAmJiBlbXB0eShPUFRJT05TX1VOU0VU
Ok0ke29wdH0pCitOT05ERUZBVUxUX09QVElPTlNfVU5TRVQrPSR7b3B0fQorLiAgIGVuZGlm
CisuZW5kZm9yCisKKy5pZiAhdGFyZ2V0KG5vbmRlZmF1bHRjb25maWcpCitub25kZWZhdWx0
Y29uZmlnOgorLiAgIGlmICFlbXB0eShOT05ERUZBVUxUX09QVElPTlNfU0VUKQorCUAke0VD
SE9fTVNHfSAiJHtPUFRJT05TX05BTUV9X1NFVD0JJHtOT05ERUZBVUxUX09QVElPTlNfU0VU
fSIKKy4gICBlbmRpZgorLiAgIGlmICFlbXB0eShOT05ERUZBVUxUX09QVElPTlNfVU5TRVQp
CisJQCR7RUNIT19NU0d9ICIke09QVElPTlNfTkFNRX1fVU5TRVQ9CSR7Tk9OREVGQVVMVF9P
UFRJT05TX1VOU0VUfSIKKy4gICBlbmRpZgorLmVuZGlmICMgbm9uZGVmYXVsdGNvbmZpZwor
CiAuaWYgIXRhcmdldChzaG93Y29uZmlnKQogLmluY2x1ZGUgIiR7UE9SVFNESVJ9L01rL2Jz
ZC5vcHRpb25zLmRlc2MubWsiCiBNVUxUSV9FT0w9CTogeW91IGhhdmUgdG8gY2hvb3NlIGF0
IGxlYXN0IG9uZSBvZiB0aGVtCg==
--------------020709060304000201070301--
--Qq8wlt8r93sV1uGiMjOlUN47d0aooSCeq
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQEcBAEBCgAGBQJTOIjwAAoJEORay8JGGICYkdkH/3t6m9pS6EJoGB3PAdN3gNWg
pFG+nA5Q2NKEK9U0a9grT9BndHN1wJQhD42R+e9w4qbPprT8zBRhUGjqvUFkxfTN
UKAifDScS8VXmWpFvkuWUoKNydD+1gS0qn4VZV5e+2tEDO1eseknBWcvIPEmfu2V
BD4ZJSWzbUYko1uzLrANq38o3b351D3VWMwzFk3FxAQ6ovZI6nRQAs4Buy3gCsbA
7BYSfkom1zzoNLxJ1JKwO2DdGcHh+yEWH37WBLtG17PzbG7vRrRkGezhXA0sWpu1
TYpJCPoYyCuPENjRy/IicFNHNgU4APGSlMcUnykPiFxSBtE0nkAE3qy7T5tLfIs=
=Q0A5
-----END PGP SIGNATURE-----
--Qq8wlt8r93sV1uGiMjOlUN47d0aooSCeq--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?533888EB.2060503>