From owner-freebsd-ports@freebsd.org Thu Sep 28 08:33:39 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 D228EE2C99D for ; Thu, 28 Sep 2017 08:33:39 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [81.2.117.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 88339754EF for ; Thu, 28 Sep 2017 08:33:39 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from leaf.local (unknown [88.202.132.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: m.seaman@infracaninophile.co.uk) by smtp.infracaninophile.co.uk (Postfix) with ESMTPSA id C41A312A2C for ; Thu, 28 Sep 2017 08:33:29 +0000 (UTC) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=FreeBSD.org Subject: Re: [HEADUP] FLAVORS landing. To: freebsd-ports@freebsd.org References: <201709272057.v8RKvTem010871@gw.catspoiler.org> From: Matthew Seaman Message-ID: Date: Thu, 28 Sep 2017 09:33:28 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit 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, 28 Sep 2017 08:33:39 -0000 On 28/09/2017 07:55, Stefan Esser wrote: > The matching of versions of base package and sub-packages must be > more strict than by version number, since trivial changes might be > applied to a port without incrementing the PORTREVISION, but with > impact on the binary, e.g. if the port is to built with some gcc > version from ports and that gcc port has been updated, leading to > different object files and debug symbols than a previous version > of the port with identical version number. You have a good point here, but I wonder if this scenario would happen sufficiently frequently to justify making special provision for it in the package builders. The vast majority of the ports are compiled with the system C-compiler -- clang -- and that will not be modified during the lifetime of a release branch unless directly affected by a Security problem or Erratum-level bug. Similarly with the quarterly package branches: ports versions of compilers will remain stable for 3 months unless directly affected by a security problem. Plus a great deal of work has gone into making reproducible builds, so simply recompiling a port should not introduce any noticeable differences. If this does prove to be a problem, then presumably the simplest response would be to bump the PORTREVISION in any port that defaulted to compiling with the updated compiler, in much the same way that shlib ABI version bumps are handled. Failing that, we could do something like introducing a random string labelled as 'build-id' as a piece of meta-data that gets inserted into all of the (sub-)packages created out of any one $WRKDIR, and use that with the existing Provides/Requires mechanism. Cheers, Matthew