From owner-freebsd-questions@freebsd.org Wed Mar 6 21:11:35 2019 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B004315277D3; Wed, 6 Mar 2019 21:11:35 +0000 (UTC) (envelope-from freebsd-lists@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.70]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CE51770948; Wed, 6 Mar 2019 21:11:34 +0000 (UTC) (envelope-from freebsd-lists@gromit.dlib.vt.edu) Received: from pmather-dld-1.lib.vt.edu (pmather-dld-1.lib.vt.edu [128.173.51.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 2E87ADA; Wed, 6 Mar 2019 16:11:28 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: poudriere(-devel) ports updating question From: Paul Mather In-Reply-To: <20190306205827.GA34798@rpi3.zyxst.net> Date: Wed, 6 Mar 2019 16:11:27 -0500 Cc: freebsd-questions@freebsd.org, freebsd-stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <85643302-A1F8-4EF2-B75D-3FAF3A138923@gromit.dlib.vt.edu> References: <20190305140939.GA18890@rpi3.zyxst.net> <30D9DC41-0FE6-4B2F-846B-E7E1BDEF485D@lassitu.de> <20190306205827.GA34798@rpi3.zyxst.net> To: tech-lists X-Mailer: Apple Mail (2.3445.9.1) X-Rspamd-Queue-Id: CE51770948 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dmarc=fail reason="" header.from=vt.edu (policy=none) X-Spamd-Result: default: False [-3.87 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[vt.edu : No valid SPF, No valid DKIM,none]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-1.75)[ip: (-4.92), ipnet: 128.173.0.0/16(-2.46), asn: 1312(-1.30), country: US(-0.07)]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[chumby.dlib.vt.edu,gromit.dlib.vt.edu]; NEURAL_HAM_SHORT(-0.61)[-0.607,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1312, ipnet:128.173.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 21:11:35 -0000 On Mar 6, 2019, at 3:58 PM, tech-lists wrote: > On Wed, Mar 06, 2019 at 06:23:49PM +0100, Stefan Bethke wrote: >>> Am 05.03.2019 um 15:09 schrieb tech-lists : >=20 >>> Basically I'm looking for exclude mask functionality when updating a >>> ports tree with poudriere ports. >>>=20 >>> Do I need to do this manually or have I missed something? >>=20 >> I don=E2=80=99t think it=E2=80=99s easy to do that. How would you = handle dependencies? (For example, some ports require X11 libs and = stuff, even though they=E2=80=99re in a different category.) >=20 > You're right of course. My logic was wrong, and wrong premise[1] = because I > was stuck on thinking a bulk -a build. But I found how to do it (to = remove categories) in case anyone is interested. The key is in the > method used to update the tree, which is svn+https. >=20 > so, from the top of the ports tree, svn update --set-depth=3Dexclude = biology would exclude the biology category permanently. svn update = --set-depth=3Dinfinity biology would re-add it. > svn update --set-depth=3Dinfinity would make it be like nothing was > excluded in the first place. >=20 > but on reflection, it breaks a little of the ports infrastructure and = I > don't want to do that. That's correct: omitting parts of the ports hierarchy might break a = particular ports build catastrophically. If you're looking to exclude certain functionality when building ports = you should investigate using ports options to achieve that. For example, I have a poudriere jail called "trurl" that is a headless = system on which I don't want to use X11. I also don't want to use CUPS = for that matter. So, in its "trurl-make.conf" file I include this line: OPTIONS_UNSET_FORCE=3D X11 CUPS That will force those options off for all ports. The result is I don't = get any ports built supporting those options. I guess it's not foolproof, but it seems to work well enough for me. I hope this helps. Cheers, Paul.=