Bug#1006836: transition: python3.10 as default

[Markus Blatt <markus@dr-blatt.de>]

Hi,

Am Wed, Mar 30, 2022 at 09:45:30AM +0200 schrieb Markus Blatt:
> Am Tue, Mar 29, 2022 at 09:28:22PM +0200 schrieb Graham Inggs:
> > It seems opm-simulators FTBFS in much the same way now after
> > opm-common has been rebuilt.
>
> I will take a look and try to fix it. It seems there is a reference to libpython3.9.so.

I think I figured out what the issue is. The cmake configuration files of all opm modules
have an explicit list of libraries that need to be linked with the library of the module and
this is always used for linking. This list is only updated if the module/package is rebuilt.
All modules built before the transition have a reference to 
/usr/lib/x86_64-linux-gnu/libpython3.9.so which was in the Cmake configuration file of opm-common
when they where built. The only way to get rid of them seems to be rebuilding all. Hence one
would need to change the dependencies along the following lines

dependency level 3: opm-grid, opm-material, 
dependency level 4: opm-models, opm-uscaling
dependency level 5: opm-simulators (currently level 3)

Note that opm-upscaling is only needed because: if a user searches for it in its project,
then compilation will fail in the same manner as opm-simulators is failing currently.

Explanation why it is the way it is:
It is the way OPM uses CMake, these scripts date back to an old Cmake version (without support
for targets). At that time this approach was (or seemed to be) needed for static libraries. Otherwise
there would have been linker errors, because we use embedded python in opm-common. Updating to modern
CMake targets would have prevented this issue.

Sorry for the trouble and HTH.

Cheers,

Markus