Status of synth following expulsion of John Marino?

Don Lewis truckman at
Thu Feb 16 08:44:52 UTC 2017

On 16 Feb, Thomas Mueller wrote:
>> For every build -
>> /usr/local/etc/poudriere.d/make.conf
>> editors_vim_SET= CSCOPE X11 GTK3 PYTHON

Yeah, I really like this a lot more than going through all the config
screens.  Back when I used portupgrade, I found that it was too easy to
accidentally set some option for a port to a non-default value where it
would persist forever.  It was also hard to make sure that desired
non-default option values were set consistently for all ports.  For
instance if you want to enable CUPS, you'd have to do it individually
for all the ports that have a CUPS option.  It was also really tedious
going through a bunch of config screens for every portupgrade run
because typically there were a bunch of ports that had new options or
new default option values.  Multiply this by N because I had several
different FreeBSD branch and arch combos.  The downside is that you
won't find out about new and interesting option settings, but with 1000+
ports all the config screens just turned into noise for me.

>> You can also get more specific by using -
>> /usr/local/etc/poudriere.d/<setname>-make.conf
>> /usr/local/etc/poudriere.d/<tree>-make.conf
>> /usr/local/etc/poudriere.d/<jailname>-make.conf
>> /usr/local/etc/poudriere.d/<jailname>-<tree>-make.conf
>> /usr/local/etc/poudriere.d/<jailname>-<setname>-make.conf
>> /usr/local/etc/poudriere.d/<jailname>-<tree>-<setname>-make.conf
>> Shane Ambler
> Is there any way to do this options preconfiguring not using poudriere?
> One good thing about NetBSD pkgsrc, also Gentoo portage, is being able
> to set options by package or for all packages in /etc/make.conf or
> mk.conf .
> Is there a good way to do this in FreeBSD prior to running synth?
> I found it very disconcerting to do a massive portupgrade (using
> portupgrade), going to bed or otherwise away from the computer, and
> then finding it stopped at a dialog screen.

Yeah, been there and is sucked.  My workaround for this was to run
"portupgrade -aFc".  That gets through all the config screens fairly
quickly and also makes sure that all the distfiles are fetchable.  The
latter avoids the problem of a portupgrade run failing halfway through
due to a transient network problem.

My portupgrade runs eventually got to be two to three day marathons and
it sucked when things went sideways 15 minutes after going to bed due to
a build problem with a port or whatever.  Then a night's worth of CPU
time would be wasted until I could get back to the computer to see what
went wrong and start over from scratch.  It was especially frustrating
if a port failed to build, or the system crashed, or the power failed
and I was doing a "portupgrade -rf" run because there was no way to know
what ports got rebuilt, so I would have to restart the portupgrade run
from scratch.  In the meantime the system was stuck in some sort of
broken, half-upgraded state.  Not having a usable desktop for multiple
days was a real problem, which meant that I could only upgrade ports
infrequently, when I new in advance that there was nothing that would
require me to use the machine.

For me, poudriere (in combination with the practice of bumping the
PORTREVISION of dependent ports when appropriate) has been a vast
improvement.  Poudriere on a multicore machine can build multiple
ports in parallel, which is a good thing since it defaults to rebuilding
all dependencies of any port that is upgraded.  If there is a system
crash or power failure, it will pick up pretty much where it left off
and only the in-progress port builds need to start from scratch, not the
entire run.  I can also build packages for all of my machines on my
biggest and fastest machine instead of trying to compile everything on
some of my really old and slow hardware.  The pkg upgrade runs on the
individual machines only take a few minutes and it is very unlikely that
I'll get a machine into some sort of broken and half upgraded state.

> I ran make config-recursive many times, several times on the same port
> to get what was missed on the first or previous make config-recursive.
> I am not familiar with the details on planned upgrades to the ports
> framework and how they will affect usability of portmaster, but
> remember some users swore by portmanager during the pkg_* days, prior
> to pkgng.
> Portmanager could not be made compatible with pkgng and was
> subsequently dropped from ports/ports-mgmt.
> Tom

More information about the freebsd-ports mailing list