Policy on binary installations with dependencies

[Micket]

We already have plenty of easyconfigs for binary software with undocumented OS deps, typically on X11 etc.

Examples

1. https://github.com/easybuilders/easybuild-easyconfigs/blob/develop/easybuild/easyconfigs/b/Blender/Blender-3.4.1-linux-x86_64-CUDA-11.7.0.eb
2. https://github.com/easybuilders/easybuild-easyconfigs/blob/develop/easybuild/easyconfigs/m/Mathematica/Mathematica-13.1.0.eb
3. https://github.com/easybuilders/easybuild-easyconfigs/blob/develop/easybuild/easyconfigs/p/PyCharm/PyCharm-2022.3.2.eb
4. https://github.com/easybuilders/easybuild-easyconfigs/blob/develop/easybuild/easyconfigs/m/MATLAB/MATLAB-2022a.eb
   and others, currently held back in PRs, at the time of writing this, e.g. {bio}[system/system] SeaView v5.0.5 #17385

Some of these only have optional dependency on a GUI, others, e.g. PyCharm is of course useless outside an X11 desktop, so, wherever you would actually try to use them you would have most or all the required system libraries installed anyway.

I know we are inconsistent here, accepting some as is and requiring others to make adaptions. E.g. Blender is accepted, Schrödinger was not: #16619

The major options I see are:

1. treat these as implied OS dependencies (the software in question might even only support some OS'es). It's often infeasible to try to list all the things it technically requires from the OS to get all the features from Mathematica, Schrödinger, MATLAB, PyCharm, Blender etc. up and running.
2. move it under a toolchain and pick up our compiled-from-source X11 etc. This might also not at all work, as it would force a new libstdc++, zlib etc. into LD_LIBRARY_PATH which might very well break things. This also means I wouldn't be able to share the binary installs of these big software packages across my different clusters, as they would now lie under a architecture specific toolchain, which I consider a major downside.
3. avoid using binary installs and compile it from source (assuming the it's even open source). This might result in a tremendous amount of additional work for relatively small benefit (e.g. i actually provide OS X11 for all my nodes as part of the VNC desktop for my users, so the Blender package as is probably works just fine for my setup). It's still probably the best option for a bunch of software though and we already do this for the most part.

[branfosj]

2. As you say, this does not always work. We've had issues with some software where this has not been possible.

This suggests that we should have a warning message during install - something like:

We think you'll need to provide X11 and some other dependencies via OS installed packages. You should test the install of [software] to verify it works as intended on your system.

We should try to avoid using it, but there is definitely some GUI software that is just not worth the effort. Blender comes to mind for this - we have the above linked EasyConfig installed at my site and I am happy with that.

[Micket]

Based on discussion at zoom meeting, i think we basically decided that in most cases, option 2 is typically to painful, often won't work, will limit interoperability with software in other toolchains etc. So I really don't think we ought to be pushing for that.

So, postinstallmsgs could be used to print the warning that there is expected OS dependencis that the user should take care of themselves, and we should just continue to accept binary software as is.

When it's not to much hassle to build from source, we continue to encourage that. Where, for example SeaView falls on that scale i don't know, but i think that's one we would rather just build from source. Blender i am less sure.