Binary packages not rebuilding against updated libraries

[Rainer Müller]

On 2018-04-26 07:48, Jan Stary wrote:
> On Apr 26 03:16:37, raimue at macports.org 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.

A regular update to port B does not require anything to be changed in
port A. Only incompatible changes in port B require action on port A.

If you meant something else, MacPorts does not record linkage
information in the registry at the moment.

> Say a port produces a package containing 'bin/prog'
> that depends (as in otool -L) on libz.1.2.11.dylib.

'bin/prog' would be supposed to link against libz.1.dylib, not to a
filename with the full version number.

This is an essential concept of shared libraries. You can update them
without having to rebuild dependents.

> 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.

If this exists, the port providing 'bin/prog' is to blame for linking
the wrong library filename.

'bin/prog' should only break when the update changes from libz.1.dylib
to something like libz.2.dylib. As said before, this should be seldom.

> 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.
This should not be the responsibility of the maintainer, upstream
controls the library versioning and decides when to increase it.

OpenBSD seems to need this because they want to be able to bump all
libraries for changes in their base OS. MacPorts produces separate
archives per OS version and on migration to a new version of macOS, a
full rebuild is necessary. Therefore the situation to bump all library
versions will not arise and MacPorts can use the version information
provided by upstream.

> 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.

I highly doubt that changes to SHARED_LIBS do not involve changes to
dependents.

As far as I understand it, OpenBSD also does not produce a new binary
package of dependents unless their REVISION is increased. Therefore a
change in the dependent is required when SHARED_LIBS in a dependency is
changed. This is the exact same process we use in MacPorts right now.

>> To produce new packages, the revision of port A has to be increased.
> 
> That's what I don't get: new packages of what?
> 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?

'port rev-upgrade' can only fix your local system. The archives provided
on packages.macports.org would still contain binaries that link with the
old version.

Users would download the binary archive and install it, after which
'port rev-upgrade' detects is as broken and rebuilds it locally.
Therefore, the revision needs to be increased to rebuild a new archive
from source with the correct linking to be published at
packages.macports.org.

Rainer