Binary packages not rebuilding against updated libraries

[Ryan Schmidt]

On Apr 26, 2018, at 00:48, Jan Stary wrote:

> On Apr 26 03:16:37, Rainer Mueller wrote:
>> On 2018-04-26 00:11, Jan Stary wrote:
>>> On Apr 24 09:31:04, ken.cunningham.webuse at gmail.com wrote:
>>>> Portfile authors need to manually "revbump"
>>>> the library's dependent ports when
>>>> supporting libraries change significantly.
>>>> It's not automatically figured out by MacPorts.
>>> 
>>> Wait, what? I'm still relatively new to MP
>>> and this seems a bit weird.
>>> 
>>> "Port A depends on library B. The port of library B has
>>> just been rebuilt/upgraded. So port A needs to be rebuilt
>>> as well now, if only to record the new dependency."
>> 
>> An update to port B cannot cause a new dependency in port A.
> 
> I mean dependency on the new lib.
> Say a port produces a package containing 'bin/prog'
> that depends (as in otool -L) on libz.1.2.11.dylib.
> If zlib is updated, and provides libz.1.2.12.dylib now,
> bin/prog ca no longer depend on libz.1.2.11.dylib
> (which no longer exists), but on libz.1.2.12.dylib.
> That's what I meant by "new dependency", in the
> installed package of the port.
> 
>>> MP does not have that?
>> Port A only has to be rebuilt if the compatibility version of port B
>> changes in a way that makes it incompatible with the previous version
>> (basically increasing soname on other systems). This is quite seldom.
> 
> Aren't most library port updates like that?

Definitely not. Take glib2 for example. The main library's install_name has been libglib-2.0.0.dylib forever. As long as that continues to be true, when glib2 is updated to a new version, nothing using glib2 needs to be rebuilt.


> For comparison, the OpenBSD port system has resigned on upstreams'
> library versioning, and versions the libraries itself. For example,
> in audio/libsndfile (1.0.28):
> 
> 	SHARED_LIBS +=  sndfile   6.0   # .1.28
> 
> and it installs /usr/local/lib/libsndfile.so.6.0.
> Is that incompatible with the previous? That was libsndfile.so.5.0,
> so yes, it's incompatible; that's why the maintainer named it so.
> Hence, rebuild everything that depends on libsndfile
> (without bumping _their_ revision).
> 
> In an ideal world, the decision could be based on the libfoo.X.Y.Z,
> but often it cannot.

Note that in MacPorts it is not uncommon for a single port to contain multiple libraries.


>> If port B was updated and the compatibility version changed, the
>> automatic run of 'port rev-upgrade' after the installation will detect
>> that a binary/library of port A has broken linkage. It will then rebuild
>> port A from source, ensuring you have a working installation locally.
> 
> Yes.
> 
>> To produce new packages, the revision of port A has to be increased.
> 
> That's what I don't get: new packages of what?

New pre-compiled binary archives of the ports.

> The packages that were installed before get rebuilt
> with port rev-upgrade, automatically,
> without anyone touching their Portfile.
> Which ports need to get a new revision in the Portfile, and why?

The ports which should be rebuilt (anywhere: on user systems or on our buildbot for creating the pre-compiled binary archives).

Rev-upgrade is meant to catch errors (situations where we have forgotten to increase a port's revision to rebuild it), not be a real solution to the issue.