Date: Thu, 28 Sep 2017 09:33:28 +0100 From: Matthew Seaman <matthew@FreeBSD.org> To: freebsd-ports@freebsd.org Subject: Re: [HEADUP] FLAVORS landing. Message-ID: <a6789def-cd96-3fe6-0b16-061f3ecc9ac2@FreeBSD.org> In-Reply-To: <a5b2394e-3de7-e758-f059-121e187c824b@freebsd.org> References: <201709272057.v8RKvTem010871@gw.catspoiler.org> <a5b2394e-3de7-e758-f059-121e187c824b@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a6789def-cd96-3fe6-0b16-061f3ecc9ac2>