old ports/packages

[Konstantin Belousov]

On Sat, Jun 04, 2016 at 06:20:24PM +0100, Matthew Seaman wrote:
> On 2016/06/04 16:14, William A. Mahaffey III wrote:
> > One point of order if I may: It was stated earlier in the thread that
> > binary compatibility throughout a major release cycle (X.n-R, as 'n'
> > varies) is a specification. That is not explicitly addressed in the
> > above URL's, as far as I can see. Is that indeed considered a
> > specification ? If so, it would seem to satisfy the LTS desire
> > implicitly. TIA & have a good one.
> 
> At the moment we have a guarantee of binary compatibility for any
> software compiled on release X.n to be able to run on any release X.m
> where m >= n.  This is not going to change with the new support model.
> 
> ie. Something compiled for 11.0 will run on any subsequent 11.x release,
> but something compiled on 11.3 (say) would not necessarily run on 11.2.
>  Now, in fact, that sort of backwards compatibility usually does work,
> but it isn't guaranteed.  Putting in this sort of backwards incompatible
> change is something that is avoided unless there is some very good
> reason to introduce it.
> 
> Also recognize that libc.so in 11.x will support ABI multi-versions --
> so you can run anything that needs an earlier ABI version without any
> special configuration[*].  This does not apply to all of the shlibs
> provided by the system, so you may get mixed results depending on what
> your applications link against.
We ship libc.so+libpthread.so+libm.so+rtld which support backward
compatibility up to FreeBSD 7.0.  This means that the 'core' C runtime
is ABI-stable.

It is not true for the less 'core' FreeBSD shlibs indeed, but that other
libraries are typically OS-depended and are used for system management
or configuration.

More severe cause of ABI breakage are the third-party shlibs, which ABI
is not maintained by the project and which updates cause at least incompatible
shlib version bumps.  Examples are openssl and ncurses.

This explains the reason why the packages are still have to be build per
major branch.

> 
> This is why the FreeBSD packages are always built on the earliest still
> supported release from the same major branch.  The difference implied by
> the new support model is that the package building machines would be
> updated more frequently as they track the earliest still-supported
> release.  Practically speaking, as a pkg user you're unlikely to
> experience any difficulties even if you aren't up to date with your OS
> patching, but there may be some rare occasions where you will need to
> update your OS before you can update your ports.
> 
> 	Cheers,
> 
> 	Matthew
> 
> [*] IIRC the available version history goes back to 10.0-RELEASE; you'll
> definitely need compat libs for anything compiled earlier than that, but
> you may well be able to run 10.x applications on an 11.x system with no
> compatibility shims required.
>