11-STABLE to 12-STABLE Migration Questions

[Matthew Seaman]

On 28/12/2020 14:01, LVM wrote:


> Did just that (with releng). Didn't have to do significant config 
> changes except manually merging files going through mergemaster -Fi.
> 
> But I'm using GENERIC for kernel.
> 
> I certainly didn't have to update my (installed) ports after a svn update.

Careful now.  There are some pitfalls here that you could run into some 
time down the line.

  * Most of the shared libraries (certainly all of the important ones) in
    the FreeBSD base system use symbol versioning.

    Meaning that a binary compiled on an older version of the OS with
    shlibs using an older ABI version can still dynamically link against
    the latest version of the shlib.  Effectively the shlib contains the
    entire sequence of ABI versions since they started doing the
    versioning thing, which was way back around 7.x-RELEASE IIRC.

    So all of your 11.x binaries will still run on a 12.x system, as you
    have observed.

  * For simple applications, which only rely on the shlibs from the
    FreeBSD base, and don't do any dynamic loading of modules you can
    upgrade them at will -- the 'compiled for 12.x' binaries may
    reference a more up-to-date ABI version than other ported
    applications compiled for 11.x, but there's no chance of conflict

  * Any other software with more complex dynamic linking requirements
    can be a problem.  You may, or may not, find things unexpectedly
    crashing when you later do a routine ports update.

    The trouble occurs when you end up trying to dynamically link two
    different ABI versions from the same shared library into the same
    executable.  This can happen in a number of ways.  For example:

       Port A links to a shared library from port B.  Both the
       application A and the library B need to link against the base
       system libc.so

    Now, if you install an update to A (links to libc ABI from 12.x) but
    not  B (still links to libc ABI from 11.x) then you're looking at
    this sort of potential version conflict.  Same applies if you update
    B but not A.  It's not a guarranteed failure -- the details of
    exactly what symbols A and B reference are important.

    The same sort of considerations apply to many perl, python, PHP
    etc. modules or to Apache loadable modules.

So, you don't need to reinstall all your ports immediately you upgrade, 
but you are at risk of problems when you later incrementally upgrade 
your installed ports.

For absolute peace of mind the simplest course is to force a re-install 
of all of your ports.  That's overkill really, as many ports don't even 
contain any compiled binaries, but it's probably quicker overall than 
sitting down and trying to work out what really has to be reinstalled.

This analysis doesn't apply to loadable kernel modules: those _will_ 
have to be upgraded to match the upgraded kernel.  Neither does it apply 
to certain applications that know "too much" about the internals of the 
kernel memory -- lsof(1) being the poster child here.

	Cheers,

	Matthew

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20201228/9ec0ec9c/attachment.sig>