Le 5/13/23 16:03, Matthew Seaman a écrit :
On 13/05/2023 13:43, Xavier Humbert wrote:
I'm planning in a few days, as soon as it beeen branched, to upgrade
base from 13-STABLE to 14-STABLE
I'm trying to avoid to rebuild my > 1600 ports.
Is there a wayto determine ports affected by the ABI change, which
must be recompiled ? Obviously Pure Perl or Pure Pyhton don't need to.
Since libc and other shared libraries in the FreeBSD base system use
API versioning, almost all of your ports will continue to function on
14-STABLE. There will also be a misc/compat13x port to provide
compatibility for any non-versioned system shared libraries, which you
should install as part of upgrading your base system.
So, no need to rebuild everything immediately. With the obvious
exception of any loadable kernel modules which will definitely need to
be updated to operate with the new 14-STABLE kernel.
However, as soon as you start updating ports on your new 14-STABLE
system, this can change and simultaneous re-installation of several
pkgs be required. That's generally a consequence of something being
linked against a different API version somewhere in a dependency
chain, which may require the whole dependency chain involved to be
updated at the same time.
Obviously, as you correctly observe, that only applies to software
compiled down into machine code and linked by the system loader, ld.so
-- statically linked binaries, interpreted languages (shell) or pure
byte-compiled language modules (python, perl, lua, java) won't be
affected. Although the interpreters for any of those languages could
well be, as would any modules built around loadable shared objects.
In terms of packages, the things to look for are:
(1) architecture independence: `pkg query -a '%n-%v %q' | grep -F '*'`
Although the ABI string built into the package will say eg.
`FreeBSD:13:*` indicating a specific major version of the OS, such
packages probably _don't_ need to be recompiled for an OS major verson
change.
(2) Of the architecture dependent packages, check for those requiring
or providing shared libraries: `pkg info -bB pkgname`
Typically this will not include any shared library dependencies on the
base system (so not entirely foolproof) but any package only linking
against the base system shlibs and not providing shlibs for anything
else to link against is effectively a leaf package in this respect,
and can be updated independent of anything else.
Look out for compiled dynamically loaded modules too -- things like
apache or nginx modules, wrappers for shared libraries to make them
available in other languages and so forth. (eg. Python modules that
are not architecture independent.)
Anything remaining after applying those filters is going to require
more care to update smoothly. It's going to be quite a laborious task
to classify all of your 1600 ports and map out what depends on what
and what groups of packages would need to be reinstalled in synchrony.
Whether it's worth it compared to just throwing CPU-cycles at the
problem and rebuilding everything straight off is not obvious to me.
Running a mixed set of packages from different major OS versions will
run the risk of software packages arbitrarily crashing with consequent
loss of functionality and potential system downtime. Good luck.
Note that if you're using poudriere to build packages, updating a
poudriere-jail to 14-STABLE will automatically trigger a full rebuild
of all packages, precisely what you want to avoid.
Cheers,
Matthew
Many thanks for this very detailed answer !
Cheers,
Xavier
--
Xavier HUMBERT - Unix/Win/MacOSX Sysadmin/Network Engineer
https://www.amdh.fr
