On 2018-04-26 07:48, Jan Stary wrote: > On Apr 26 03:16:37, rai...@macports.org wrote: >> On 2018-04-26 00:11, Jan Stary wrote: >>> On Apr 24 09:31:04, ken.cunningham.web...@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
