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
