From owner-freebsd-ports@freebsd.org Sun Nov 11 23:48:27 2018 Return-Path: Delivered-To: freebsd-ports@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 4F7391129ACA for ; Sun, 11 Nov 2018 23:48:27 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from msa1.earth.yoonka.com (yoonka.com [88.98.225.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "msa1.earth.yoonka.com", Issuer "msa1.earth.yoonka.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A3A4174820 for ; Sun, 11 Nov 2018 23:48:26 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from crayon2.yoonka.com (crayon2.yoonka.com [10.70.7.20]) (authenticated bits=0) by msa1.earth.yoonka.com (8.15.2/8.15.2) with ESMTPSA id wABNmOIW027619 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sun, 11 Nov 2018 23:48:25 GMT (envelope-from list1@gjunka.com) Subject: Re: Few how-it-works questions To: freebsd-ports@freebsd.org References: <73366a94-238a-ed9a-5dee-d5955525e851@gjunka.com> From: Grzegorz Junka Message-ID: Date: Sun, 11 Nov 2018 23:48:24 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB-large X-Rspamd-Queue-Id: A3A4174820 X-Spamd-Result: default: False [-3.07 / 200.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.981,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:88.98.225.149]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-ports@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.96)[-0.962,0]; DMARC_NA(0.00)[gjunka.com]; MX_GOOD(-0.01)[cached: gjunka.com]; NEURAL_HAM_SHORT(-0.80)[-0.801,0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; IP_SCORE(-0.02)[country: GB(-0.10)]; ASN(0.00)[asn:56478, ipnet:88.98.192.0/18, country:GB]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2018 23:48:27 -0000 On 11/11/2018 14:27, Matthew Seaman wrote: > On 11/11/2018 12:34, Grzegorz Junka wrote: >> Hi All, >> >> I would like to understand a bit better how the ports infrastructure works. >> >> 1. Recommended way of upgrading ports is "poudriere ports -p local -u", >> right? But this always gets me the latest version, in which some ports >> may not compile, depending on my luck. I know I can use SVN to checkout >> a specific version of ports instead, but is it possible to find out in >> which SVN version which ports are compiling and which are not? In other >> words, can I open the history of builds of FreeBSD ports on the build >> servers and check which ports are building in a specific SVN version, >> then checkout that version to build on my server? > Firstly ports rarely stay uncompilable for very long. There are > exceptions mostly due to situations like the problems with openssl-1.1.1 > support at the moment. So there are some additional strategies to apply: Matthew, thank you for your comprehensive response. Just to be clear, I wasn't complaining about the ports tree being broken from time to time. It's understandable as it's being constantly updated. I just got caught in between renaming ImageMagick to ImageMagick6 and updating some ports to use ImageMagick7. As a result some ports didn't built reporting strange build errors. But another update one day later and the strange errors are gone. Since it's hardly an exception (flavours or renaming kde to kde4 are other examples), I take there must be periods when the ports tree is more stable in between those bigger updates and was trying to find a strategy to determine those stable periods as a base for updating my ports tree. Waiting, changing versions or options are good suggestions but these are reactive approaches. I would prefer a more proactive approach, i.e. not have to spend time on building a broken tree and then trying to fix it myself (unless there is no other option) but rather update my port tree when I know it's stable, and so the idea of being able to check it out in between those bigger updates. I will check the URLs and poudriere options you suggested. As a side note, is it known in advance and announced anywhere that those bigger, potentially breaking changes are being applied to the port so that someone can plan to update beforehand or wait until the storm is over? Thanks GrzegorzJ