i am currently working on a project that involves cohabitation of binaries from multiple origins on the same ( linux ) system.
for the sake of this question, one can assume each binary is located in a working chroot
i use various hacks to get this to work without actually chrooting :
- modify the binary itself to change the linker and add adequate RPATHs ( easy but tedious )
- modify the kernel exec family of functions ( not really an option )
- replace binaries with shebangs of the form : env LD_LIBRARY_PATH=... /path/to/linker /path/to/actual/executable
- same as above but the replacement is performed on the fly by a custom fusefs
- i lack the C skills and knowledge to hack elf binary headers on the fly in fuse ( but that would be a nice trick )
stuff like appimage and the equivalents i know of do not fit the bill since i want multiple executables in a single "pack" available by calling their regular names and rather find a way to use existing stuff without repacking everything. appimage will be used where applicable, though.
QUESTIONS REGARDING THE POSSIBILITY TO MERGE CONTAINERS
when executables are linked to a linker or lib named whatever.so.1 but multiple versions of that file exist with the same name, should i expect them to be compatible ? does it actually work IRL ?
same question if i manage to include the latest version of each lib ?
i would assume libwhatever.so.3 to break even when the exact same version was compiled against different libc but i am wondering a naming convention might help overcome this issue ?
DISCUSSION AND SIDE QUESTIONS
most of the containers are read only and this can actually be enforced should that be needed. currently, i experiment with directories and tiny squashfs balls which i build using alpine packages but without sticking apk, shells, and other unneeded stuff in the containers. i am expecting other self contained images such as docker containers to work.
the kernel is currently linux but i am exepecting this mess to be portable to BSD using either BSD binaries or linux compat. if the BSD kernel has features i am not aware of that can help with this goal, switching to BSD is an option.
is there something obvious i am missing with any of the above solutions ? maybe issues with executables that might exec themselves ?
other ways to achieve the same goal i have not thought of ? preferrably without requiring dedicated packages.
any ideas and thoughts you might think is relevant to binaries execution and packaging is very welcome. i had rather not discuss issues relevant to init system, logging, location of config files and the likes : i am already aware of those.
side/different question : does anybody know of a "reverse syslog" fuse that would allow to mount /var/log in such a way whatever is written to log files is not actually written but sent to syslog using facilities and priorities based on the files names ? would you see some use for such a tool if i end up writing it ?
thanks for your time
What you've described is solved by container systems.
You'll use Docker with ephemeral data (date dies across container restarts).
You'll use LXD with persistent data (data lives/persists across container restarts), for example any time you have complex config setups or SQL data.
Since all projects I manage have complex configs or SQL databases I use LXD, which means.
1) Each container runs it's own Linux Distro... so package management (library/executable matching) is simply handled.
I've never thought about this, because I only run Ubuntu at machine level + inside containers, so package management... simply works...
With RedHat/CentOS/Fedora + friends, you'll have much more excitement... adventure... as package management always requires... hours of attention from time to time to manually resolve dependency problems.
So if you like futzing with packaging problems, use RedHat. If not, use Ubuntu.
2) To manage library updates.
Create a new container with whatever Distro you like.
Backup files + databases in old container.
Restore into new container.
Rebuild your whatever.so.* version library against container version of all libraries + include files.