SFS collections are not good

Over the last six months, a couple of people commented that their SFS files did not work in EasyOS. The same will hold for EasyPup.

These people have a collection of SFSs, that they can use in different puppies. However, I need to point out that such collections are a very bad idea. Not entirely, they should only be used in the same Puppy derivative for which they were created.

There is of course the problem of library mis-match. An SFS designed to run in "archpup", is then tried to be used in "bionicpup", or whatever, there is a very real likelihood of the libraries in the underlying 'puppy.sfs' being inappropriate versions. Like, for example libjpeg, or libssl -- typical libraries that may have API changes with different versions.

But there is another very fundamental problem. Many of the puppies have /lib64 and /usr/lib64 as symlinks to /lib and /usr/lib, or to /lib/x86_64-linux-gnu and /usr/lib/x86_64-linux-gnu. Also, the Debian and Ubuntu-based pups may have /lib/x86_64-linux-gnu and /usr/lib/x86_64-linux-gnu as symlinks to "./".

EasyOS is currently Debian-based, and follows the library paths exactly. /lib/x86_64-linux-gnu and /usr/lib/x86_64-linux-gnu are actual folders, not symlinks. /lib64 and /usr/lib64 are symlinks to /lib/x86_64-linux-gnu and /usr/lib/x86_64-linux-gnu.

If you try to use a SFS that has, for example, /lib/x86_64-linux-gnu a symlink to "./", typical of the Debian and Ubuntu-based pups (but not all, it is settable in woof-CE when building the pup), or another example, an Slackware-based SFS that has /lib64 and /usr/lib64 as either symlinks to "./" or are actual folders, as a layer on top of 'easy.sfs' will totally break Easy.

You must use SFSs that are designed to run in EasyOS, Debian-based series (2.x). Ditto for EasyPup. 

Tags: easy