Binary packages not rebuilding against updated libraries

[Mojca Miklavec]

On 26 April 2018 at 00:34, Ryan Schmidt wrote:
> On Apr 25, 2018, at 17:14, Jan Stary wrote:
>>
>> Keep a record of what depends on what (as packaging managers do).
>> If A depends on B, and B has been rebuilt, reduild A too.
>> No "revision bump"; port A as such has not changed.
>
> MacPorts does not do that, because that would be extremely wasteful, because most updates of B do not require a rebuild of A. Only those updates of B that cause it to have a new library version require a rebuild of A. We currently require the developer who updated B to have a new library version to manually revbump A to rebuild it.

Without "revision bump" our CI infrastructure doesn't know that it
needs to rebuild A and upload the new binaries. If it doesn't rebuild
A, each and every user needs to rebuild A locally which is wasting a
lot of CPU cycles for no good reason.

I agree that we should have a better way to automatically determine
which packages need to be updated as a result of a new version of some
port. But then you have some port with non-default variants. Say,
gnuplot, which can optionally build against Qt, but does not do so by
default. When Qt version changes, it likely needs to be rebuilt, but
unless we have a detailed analysis of all possible dependency graphs
of all packages we provide, with additional information about whether
or not a dependency requires rebuild ... this problem is a bit
non-trivial to solve in general.

When libpng changes in an ABI-incompatible way, we usually manually
revbump all dependent ports, so that users don't need to rebuild the
ports on their own machines, but can instead get new binaries from the
server.

Mojca