On Apr 26, 2018, at 10:12, Perry E. Metzger wrote: > On Thu, 26 Apr 2018 10:03:59 -0500 Ryan Schmidt wrote: >> On Apr 26, 2018, at 10:00, Perry E. Metzger wrote: >> >>> On Thu, 26 Apr 2018 23:54:49 +1000 Joshua Root wrote: >>>>> So rather than just guessing based on things like major version >>>>> of a library whether dependents need to be bumped, I would >>>>> suggest we add an "abiversion" keyword. Changing it in any way >>>>> would imply that ports depending on that port would be >>>>> rebuilt. >>>> >>>> So this would have to be set manually for every library port? If >>>> looking at the library version information is "guessing", how >>>> would the correct value be determined? >>> >>> Looking at the library version isn't guessing for a human but >>> might be guessing for a machine. If the version is something like >>> 4.7.3 and it's using semantic versioning, it's probably >>> reasonable to pay attention. If it's not using semantic >>> versioning, like if it's something like 20170815 or some such >>> because it's a weird "built off a github rev" thing, it probably >>> needs a way for a human to convey it. >> >> You're talking about the package version, i.e. the version number >> the developer puts in the tarball name, readme, git tag name, etc. >> We're talking about the library version, i.e. the version number in >> the dylib name. > > Not quite. I'm noting that the package version isn't a reliable > indication of the ABI version, and neither (sadly, see the current > protobuf issues and the issues with LibreSSL) is the library dylib > name. Thus I'm proposing to have an internal ABI revision number that > we can use for deciding whether dependents need a rebuild.
I haven't followed the protobuf issue closely enough to be able to comment on it here. If they use the same install_name for incompatible versions of their library, their development process is erroneous. The libressl situation seems perfectly normal to me. libressl provides a different install_name (different major version) of libssl.dylib so if you switch from openssl to libressl you must recompile. This is expected. The way in which we offer libressl in MacPorts is erroneous. We should not pretend they are drop-in replacements for one another, because their install_names are different. There is a ticket. > And again, note that this might be a profoundly stupid idea. I'm just > trying to motivate a discussion on how to automate things so that it > isn't necessary to revbump dependents. And again, it might be vastly > more work than is worthwhile. I'd just like to figure out what might > be a practical way to do it so one can then decide it isn't worth it > or that it is... I know you want to automate everything about MacPorts. I continue to claim that it is not possible to automate every software development task. Some tasks must be interpreted and guided by a human.
