SSEC forums

Hi,

VIIRS-AF Version 2.1 - Package contains symlinks to absolute paths!

The VIIRS-AF Version 2.1 package contains symlinks to absolute paths, like this one for example:

cspp-active-fire-noaa_2.1/vendor/ShellB3/bin/bzcmp -> /opt/shellb3-cspp-py38/ShellB3/bin/bzdiff

How is that expected to work?

I thought package should be self-contained?

I am on RHEL9 and in order to put things in production here we need to build an RPM package out of it. So I make one from the tar-ball. While doing that I get a number of warnings - that's how I noticed it:

warning: absolute symlink: /local_disk/opt/CSPP-AF/2_1_0/vendor/ShellB3/bin/bzcmp -> /opt/shellb3-cspp-py38/ShellB3/bin/bzdiff
warning: absolute symlink: /local_disk/opt/CSPP-AF/2_1_0/vendor/ShellB3/bin/bzegrep -> /opt/shellb3-cspp-py38/ShellB3/bin/bzgrep
warning: absolute symlink: /local_disk/opt/CSPP-AF/2_1_0/vendor/ShellB3/bin/bzfgrep -> /opt/shellb3-cspp-py38/ShellB3/bin/bzgrep
warning: absolute symlink: /local_disk/opt/CSPP-AF/2_1_0/vendor/ShellB3/bin/bzless -> /opt/shellb3-cspp-py38/ShellB3/bin/bzmore
warning: absolute symlink: /local_disk/opt/CSPP-AF/2_1_0/vendor/ShellB3/lib64/libcrypto.so.1.0.0 -> /usr/lib64/libcrypto.so.10
warning: absolute symlink: /local_disk/opt/CSPP-AF/2_1_0/vendor/ShellB3/lib64/libssl.so.1.0.0 -> /usr/lib64/libssl.so.10

In addition I also get a lot of warnings like this one (stripped the first part of the path for integrety:

warning: Missing build-id in .../BUILDROOT/SMHI-SAF-cspp-active-fires-20240626-4.x86_64/local_disk/opt/CSPP-AF/2_1_0/vendor/ShellB3/lib64/libmpxwrappers.so.2.0.1

I will ignore those for now. But I believe it could be fixed on your side when compiling?

-Adam

Adam, we are investigating now.

Kathy

Hi Adam,
Geoff here, I'm the maintainer of the CSPP Active Fires package. With regards to the absolute path symlinks, the links related to the bzip package (bzdiff, bzgrep, bzmore etc...) were supposed to be converted to local binaries as part of the creation of the ShellB3 python distribution (which is a dependency of the CSPP AF package). Unfortunately it looks like a few links were missed in the ShellB3 build script. The bzip binaries are not used within the AF package, so the absolute links should not impact the running of the package.

The libcrypto and libssl links are to force ShellB3 to use the system SSL libraries, rather than bundling our own: some users consider external SSL libs a security risk, so we don't include them.

The "build-id" warning isn't something we can help with unfortunately. In future releases we will not be using ShellB3, directly packaging conda envs is more feasible now. But I would doubt the debug info implied by the use of build-ids would be present in that case either.

The ShellB3 implementation included in the CSPP AF package is a little old, I can provide a newer version which does not have the bzip absolute links if you like. You would just untar a tarball (giving a ShellB3 dir) into the existing cspp-active-fire-noaa_2.1/vendor directory. Let me know if you would like to try that option.

Geoff

Hi Geoff,

Thanks for your comprehensive answer! And sorry for my slow reply. I went on holiday for a week, and then got sick so only really back at work today again. I am perfectly fine with your answer, and does not need any further assistance I believe. As I can see the package is running fine in our operational test environment, so I think we are ready to go operational.

Thanks again
-Adam