Some guidance if creating an SFS

[BarryK]

I posted some notes to my blog, on pitfalls to avoid when creating an SFS of an app.

These notes apply to any pup, or pup-derivative. In a nutshell, you have to make sure that paths to executables and libraries match the distro in which the SFS is intended to be run. Here is the blog post:

https://bkhome.org/news/202210/sfs-with ... ected.html

It is possible to create an SFS that will have valid paths for all distros, by only using /usr/bin, /usr/sbin and /usr/lib
Or, place all of the app under /opt, with maybe an executable script in /usr/bin to run it
-- that script could set LD_LIBRARY_PATH if required, so that the app will find its libraries.

The blog post was created after there were some problems with some apps from FatDog converted to SFSs to run in EasyOS. Yes, it can work, if attention is given to make sure the paths are valid.

[BarryK]

I should have mentioned also in the blog post, that ideally it shouldn't matter if an SFS places a folder /usr/lib64 on top of /usr/lib64 symlink.

Libraries should be found via /etc/ld.so.cache (and the compiled form /etc/ld.so.cache). In EasyOS, /etc/ld.so.conf is:

/lib
/usr/lib
/usr/local/lib
include /etc/ld.so.conf.d/*.conf

...folder /etc/ld.so.conf.d is empty.

Also, variable LD_LIBRARY_PATH is empty.

However, similar to some apps having hardwired paths to executables, some might have a hardcoded expectation that needed libraries are in /usr/lib64, which is why EasyOS provides that path as a symlink.

Or, if an SFS has /usr/lib64, with its libraries, if the app respects /etc/ld.so.conf, then the libraries won't be found and the app won't work.

Some apps have startup scripts, that find needed resources, for example might set LD_LIBRARY_PATH to /usr/lib64, so the app will work.