From owner-freebsd-ports@freebsd.org Thu Feb 16 08:44:52 2017 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 20D32CE19C7 for ; Thu, 16 Feb 2017 08:44:52 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F00E01C9E for ; Thu, 16 Feb 2017 08:44:51 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id v1G8iiRP000405; Thu, 16 Feb 2017 00:44:48 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201702160844.v1G8iiRP000405@gw.catspoiler.org> Date: Thu, 16 Feb 2017 00:44:44 -0800 (PST) From: Don Lewis Subject: Re: Status of synth following expulsion of John Marino? To: mueller6722@twc.com cc: freebsd-ports@freebsd.org In-Reply-To: <43.4F.02660.68125A85@dnvrco-omsmta01> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 08:44:52 -0000 On 16 Feb, Thomas Mueller wrote: > >> For every build - >> /usr/local/etc/poudriere.d/make.conf > >> OPTIONS_SET= OPTIMIZED_CFLAGS SIMD PGSQL IPV6 >> 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/-make.conf >> /usr/local/etc/poudriere.d/-make.conf >> /usr/local/etc/poudriere.d/-make.conf >> /usr/local/etc/poudriere.d/--make.conf >> /usr/local/etc/poudriere.d/--make.conf >> /usr/local/etc/poudriere.d/---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