# Last Update:
As little as I like the mess of links, I dislike the over head and complexity of unions even more.
I came up with a setup that only requires 4 links for each app.
So for 20 apps. that would be 80 links, not bad all in all.
Especially when you consider, it`s the links or the real files.
However... Only 4 Multi. Links would be needed to do the same job!
It shows in this one aspect only, how capable the idea is...
.
HowTo use chroot for setting current shell`s "/" ?
Your concept of a multi-link is still flawed. There simply is no such thing. How can you have an arrow that points to four places -how should an application know which direction you really want? The union mount comcept is the only thing which resembles what you describe.
It's true that you really only have LD_PRELOAD, LD_LIBRARY_PATH and PATH to setup paths to libs and bins. They do not help you for config files and shared files. The way to resolve it for AppDirs is to simply compile them using --prefix=$APP_DIR, where APP_DIR is the specific directory where the application is located. This will usually insure that applications can find their config files, shared files and bins/libs all under one directory.
It's true that you really only have LD_PRELOAD, LD_LIBRARY_PATH and PATH to setup paths to libs and bins. They do not help you for config files and shared files. The way to resolve it for AppDirs is to simply compile them using --prefix=$APP_DIR, where APP_DIR is the specific directory where the application is located. This will usually insure that applications can find their config files, shared files and bins/libs all under one directory.
Hi amigo; The multi. link is just not as capable as a union, and that`s all.
But then... That`s the idea also, that it be lighter and simplier. Just a link.
There was no sym link for a while also, and no union, and how about X?
All new ideas start somewhere, right? Einstein`s 1 part inspiration, etc.
A link currently will hold any text you put in it, but the kernel can`t use it.
Try this: ln -s /1/2/3:/4/5/6:/7/8/9 testLink
Hover over in ROX and it shows the path`s there, but it`s dead of course.
A hard link is for files, a sym link for both, and a multi. link for dirs. only.
The kernel needs code to thread it`s path parsing with the link handler.
It would see the link as one space of all 3 paths, for reading that is.
For writing it would only write to the first path, no distributing like mhddfs.
Like $PATH it will only see and act upon the first of duplicates in it`s path.
But understand... For what needs to be done here, only reading is needed.
You don`t need to write or delete anything, no changes in general.
So to say it`s flawed would be to say much of the rest of Linux is flawed.
Yes I know about --prefix (Path), but it does not work all the time.
The program has to be written that way for it to work, most are fortunately.
And writing to elf binaries to fix the path didn`t work all the time either.
The chroot idea just got too complex, need a simple silver bullet that works.
The idea to use the many links is messy, but it should work all the time.
Any other places deps. are? Besides /local/share/, /root, and /opt.
Oh... And in my example of 20 apps. the 4 multi. links point to 20 places.
But then... That`s the idea also, that it be lighter and simplier. Just a link.
There was no sym link for a while also, and no union, and how about X?
All new ideas start somewhere, right? Einstein`s 1 part inspiration, etc.
A link currently will hold any text you put in it, but the kernel can`t use it.
Try this: ln -s /1/2/3:/4/5/6:/7/8/9 testLink
Hover over in ROX and it shows the path`s there, but it`s dead of course.
A hard link is for files, a sym link for both, and a multi. link for dirs. only.
The kernel needs code to thread it`s path parsing with the link handler.
It would see the link as one space of all 3 paths, for reading that is.
For writing it would only write to the first path, no distributing like mhddfs.
Like $PATH it will only see and act upon the first of duplicates in it`s path.
But understand... For what needs to be done here, only reading is needed.
You don`t need to write or delete anything, no changes in general.
So to say it`s flawed would be to say much of the rest of Linux is flawed.
Yes I know about --prefix (Path), but it does not work all the time.
The program has to be written that way for it to work, most are fortunately.
And writing to elf binaries to fix the path didn`t work all the time either.
The chroot idea just got too complex, need a simple silver bullet that works.
The idea to use the many links is messy, but it should work all the time.
Any other places deps. are? Besides /local/share/, /root, and /opt.
Oh... And in my example of 20 apps. the 4 multi. links point to 20 places.