[HEADUP] FLAVORS landing.

[Matthew Seaman]

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