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