Support build with unbundled libraries

[marcindulak]

Is your feature request related to a problem? Please describe.

Fedora discourages including libraries as part of a process of building a package like nwchem. Instead nwchem should dynamically link to the already existing libraries on the system (like ga, blas, scalapack, etc.).

https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling

Fedora packages SHOULD make every effort to avoid having multiple, separate, upstream projects bundled together in a single package.

Describe the solution you'd like

An option to support for building nwchem with all libraries unbundled.

Describe alternatives you've considered

Currently I maintain a set of commands used to unbundle nwchem https://src.fedoraproject.org/rpms/nwchem/blob/af06fdbfeafd22894170fd879354f153d6ab0d2e/f/nwchem.spec#_188,
but the process of discovering how to unbundle takes time.

# remove the whole src/libext
rm -rf src/libext/{elpa,libext_utils,libxc,mpich,openblas,plumed,scalapack,tblite}/

# remove bundling of BLAS/LAPACK
rm -rf src/blas/ src/lapack/
sed -e 's|CORE_SUBDIRS_EXTRA +=.*|CORE_SUBDIRS_EXTRA +=|g' -i src/config/makefile.h
sed -e 's|CORE_SUBDIRS_EXTRA =.*|CORE_SUBDIRS_EXTRA =|g' -i src/config/makefile.h
sed -e 's|-llapack||g' -i src/config/makefile.h
sed -e 's|-lblas||g' -i src/config/makefile.h
sed -e 's|-lnwclapack||g' -i src/config/makefile.h
sed -e 's|-lnwcblas||g' -i src/config/makefile.h

Additional context

Here is an example of issue when discovering how to unbundle. 45f057e seems to not accept the current unbundling anymore, as it requires "blas" directory to be present. I don't know yet what the unbundling commands need to be.

+ /usr/bin/make BLAS_SIZE=4 USE_INTERNALBLAS=1 USE_MPI=y clean
***warning MPI_LIB ignored since FORCE_MPI_ENV not set***
***warning MPI_INCLUDE ignored since FORCE_MPI_ENV not set***
make[1]: Entering directory '/builddir/build/BUILD/nwchem-45f057eca7e3bbe85815efe2bbcbbcacc6b95471/src'
***warning MPI_LIB ignored since FORCE_MPI_ENV not set***
***warning MPI_INCLUDE ignored since FORCE_MPI_ENV not set***
test \! -f 64_to_32 -o \! -f 32_to_64 || rm -f 64_to_32 32_to_64
test -d /builddir/build/BUILD/nwchem-45f057eca7e3bbe85815efe2bbcbbcacc6b95471/lib/LINUX64 || mkdir -p /builddir/build/BUILD/nwchem-45f057eca7e3bbe85815efe2bbcbbcacc6b95471/lib/LINUX64
test -d /builddir/build/BUILD/nwchem-45f057eca7e3bbe85815efe2bbcbbcacc6b95471/bin/LINUX64 || mkdir -p /builddir/build/BUILD/nwchem-45f057eca7e3bbe85815efe2bbcbbcacc6b95471/bin/LINUX64
./util/util_nwchem_version.bash
which: no git in (/usr/lib64/openmpi/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/sbin)
make[1]: Leaving directory '/builddir/build/BUILD/nwchem-45f057eca7e3bbe85815efe2bbcbbcacc6b95471/src'
rm -f core *.o *.a *.trace
Making clean in blas
make[1]: Entering directory '/builddir/build/BUILD/nwchem-45f057eca7e3bbe85815efe2bbcbbcacc6b95471/src'
make[1]: *** blas: No such file or directory.  Stop.
make[1]: Leaving directory '/builddir/build/BUILD/nwchem-45f057eca7e3bbe85815efe2bbcbbcacc6b95471/src'
make: *** [GNUmakefile:116: clean] Error 1

[edoapra]

This is not a bug report.
It should have appeared in the discussion session

[marcindulak]

It's a feature request - nwchem repo allows one to submit it

Maybe the issue template should include with [Bug], [Feature], [Security] in the title to help identifying them?

I believe the problem with github discussions is that they don't automatically propagate links to issues.
Let me try it here. If I link for example to #903, I think the backlink to this discussion won't appear in the issue.

Therefore I don't recommend using discussions.

[marcindulak]

Please keep this in discussions for now, since I submitted a discussion about github discussions using the example of our discussion https://github.com/orgs/community/discussions/73401

[edoapra]

What is the point of removing all those NWChem files? It is for the fun of slowing down the build?
NWChem can link with BLAS and LaPack libraries using the environment variables BLASOPT and LAPACK_LIB plus setting BLAS_SIZE. No single change to the makefile structure is needed. This approach is used, for example, in the NWChem builds for Homebrew and Conda-forge.
I cannot follow 90% of what is posted in #905 (comment)

[marcindulak]

rm -rf src/blas/ src/lapack/ are removed to unbundle the source - and use the system provided libraries instead. The suggestion of debundling is described here https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling. Tracking of security vulnerabilities is provided as a reason for use of system libraries instead of their copies distributed by the program (nwchem) source.
It may be that nwchem builds unbundled by setting some variables, but fedora assumes that there is nothing safer than removing the bundled sources.

All packages whose upstreams allow them to be built against system libraries must be built against system libraries. In this case, bundled libraries (and/or their source code) MUST be explicitly deleted during %prep

I think there is still no definition of what a system library is https://pagure.io/fesco/issue/1491, but the presence of math libraries security vulnerabilities like https://nvd.nist.gov/vuln/detail/CVE-2021-4048, shows that unbundling helps in reducing their number in the software packaged for linux. Debian also follows this approach https://blog.liw.fi/posts/2023/debian-reasons/#no-bundled-libraries

rm -rf src/libext/{elpa,libext_utils,libxc,mpich,openblas,plumed,scalapack,tblite} are removed since they try to download from the internet, and internet access is blocked during fedora builds due to reproducibility, auditability, and security. I can't find a good reference to fedora decision about this, but there is an opinion from one of redhat packagers https://stackoverflow.com/questions/33787465/open-build-service-access-internet-during-built

My request is about having a contract, so nwchem has a single setting which makes sure no bundled library is used during the build, but I'll still need to remove the corresponding bundled sources from the spec file.

[edoapra]

Thanks for the explanation, but I am still not getting the point.
All these libraries that Fedora does not like are well localized in three top level directories (libext, lapack and blas). How bad is for the Fedora build to simply delete those directories if they are not allowed by Fedora?

[marcindulak]

The current (master 45f057e) needs a different unbundling from the one I was using until now. Removing fully src/{blas,lapack} results now in an error from make clean, since GNUmakefile files are required. The build fails after about 3 hours on koji. Having a promise from nwchem that it supports unbundling by removing the sources (ideally having such configuration tested in nwchem ci) would mean less work for me discovering how to unbundle.

Below is the new way of unbundling that seems to work. Some lines may be unnecessary, but I don't have time to test this.

# remove the whole src/libext
rm -rf src/libext/{elpa,libext_utils,libxc,mpich,openblas,plumed,scalapack,tblite}

# remove bundling of BLAS/LAPACK
mv src/blas/GNUmakefile /tmp/GNUmakefile.blas
mv src/lapack/GNUmakefile /tmp/GNUmakefile.lapack
rm -rf src/blas/* src/lapack/*
mv /tmp/GNUmakefile.blas src/blas/GNUmakefile
mv /tmp/GNUmakefile.lapack src/lapack/GNUmakefile
sed -e 's|CORE_SUBDIRS_EXTRA +=.*|CORE_SUBDIRS_EXTRA +=|g' -i src/config/makefile.h
sed -e 's|CORE_SUBDIRS_EXTRA =.*|CORE_SUBDIRS_EXTRA =|g' -i src/config/makefile.h
sed -e 's|-llapack||g' -i src/config/makefile.h
sed -e 's|-lblas||g' -i src/config/makefile.h
sed -e 's|-lnwclapack||g' -i src/config/makefile.h
sed -e 's|-lnwcblas||g' -i src/config/makefile.h

[edoapra]

One solution would be to have a script in $NWCHEM_TOP/contrib that takes care of this issues.
However, I don't have the cycles to write and maintain myself.
The only bit that makes sense do from my side is to remove lapack and blas from CORE_SUBDIRS_EXTRA (those two directories should be only used when USE_INTERNALBLAS is set).