SFS with invalid library path rejected

This problem has come up when an SFS from another Puppy-derivative is attempted to be used in EasyOS.

Linux distributions have differing paths to the shared libraries. For example, Slackware has /usr/lib64, Debian has /usr/lib/x86_64-linux-gnu.

EasyOS Dunfell-series has all libraries in /usr/lib, with /usr/lib64 and /usr/lib/x86_64-linux-gnu symlinks to /usr/lib

The EasyOS PKGget package manager (PPM) can handle installing packages from these other distros. For example, you install a DEB package, the package manager takes care of relocating the contents of /usr/lib/x86_64-linux-gnu to /usr/lib

However, SFSs are a problem. If one of those, say from FatDog, which has the Slackware folder layout, then a folder /usr/lib64 in the SFS will be on top of the symlink /usr/lib64 in easy.sfs.

This may have bad repercussions. The SFS may work; however other apps may be hardcoded to look into /usr/lib64, and they won't find their library files.

Anyone who is creating a SFS for EasyOS Dunfell-series will need to make sure that library paths are valid. For example, just rename /usr/lib64 to /usr/lib in the SFS; problem solved.

There is a need to detect and reject SFS files with invalid paths, so I have inserted code into the 'init' script in the initrd, like this:

    #20221016 check valid library path...
    BADextra=0
    if [ -h /easy_ro/easy_sfs/usr/lib64 ];then
     if [ -e /easy_ro/${ANAME}/usr/lib64 ];then
      BADextra=1
      echo -e "\\033[1;31mERROR: /usr/lib64 incorrect path in SFS: ${ANAME}.sfs\nTHIS SFS WILL NOT BE LOADED\\033[0;39m" #red
     fi
    fi
    if [ -h /easy_ro/easy_sfs/usr/lib/x86_64-linux-gnu ];then
     if [ -e /easy_ro/${ANAME}/usr/lib/x86_64-linux-gnu ];then
      BADextra=1
      echo -e "\\033[1;31mERROR: /usr/lib/x86_64-linux-gnu incorrect path in SFS: ${ANAME}.sfs\nTHIS SFS WILL NOT BE LOADED\\033[0;39m" #red
     fi
    fi
    if [ $BADextra -eq 1 ];then
     umount /easy_ro/${ANAME}
     if [ -f /easy_ro/${ANAME}.sfs ];then
      rm -f /easy_ro/${ANAME}.sfs
     fi
     continue
    fi

...just some simple checking. If a path is wrong, there will be a error message in red and the SFS won't be loaded. /lib64 and /lib/x86_64-linux-gnu are another case, haven't checked for those.

EDIT:
Note, the above description is only for the Dunfell-series. EasyOS Buster-series, or any series built with Debian or Ubuntu DEBs, may have the same library paths as Dunfell-series, or it may not. In woofQ, or in woof-CE for building pups, it is a build decision. One build decision may be to have exactly the same folder paths as in Debian and Ubuntu, and /usr/lib/x86_64-linux-gnu may be an actual folder, not a symlink -- and /usr/lib64 may exist as a symlink to /usr/lib/x86_64-linux-gnu

So the lesson is, if you create an SFS, whether for a pup or for Easy, you need to know the paths to the libraries, and build the SFS accordingly. The SFS that you create will be for those library paths, and may be incorrect for other pup-variants.

EDIT:
Why I'm at it, appending to this blog post, note also that the same problem may occur with paths to executables. Some major distributions, such as Arch and Ubuntu, have moved to "usr-merge" paths. For example, /bin has now become a symlink to /usr/bin.

If you create an SFS with /bin, not a symlink, then that SFS is going to be on top of the easy.sfs or pup SFS, hiding the /bin symlink, which may break some other app. In theory, apps should not hardcode paths to executables, but some do, and if /bin/<something> is required, it won't be found.

The simplest future-proof SFS is to not have anything in /bin, /sbin, /lib or /lib64, have everything under /usr Another strategy is to create the app in /opt 

EDIT 2022-10-17:
I have posted some further clarifications on this topic to the Puppy Forum:

https://forum.puppylinux.com/viewtopic.php?t=7083

...post there if you would like to discuss this topic.     

Tags: easy