Re: How to determine ports affected by ABI change

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