Binary packages not rebuilding against updated libraries

[Ryan Schmidt]

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.


>> The library version info is recorded in the binaries. Rev-upgrade
>> works very well in most cases. I'm having a hard time understanding
>> how this would help.
> 
> Well, right now we're manually bumping "revision" in dependent ports
> when we upgrade a port that is depended on, right? This seems to
> indicate that the current way isn't automatic. Or maybe I'm
> misunderstanding?

You're correct.