On 15/05/2014 20:43, Jorge Almeida wrote:
If I understand correctly, it would be less efficient (I tend to use execve() rather than execvp() etc in my own little programs; searching through a path when we already know the location of the binaries is not appealing to me).
Sure, but honestly, the cost of a PATH search is negligible compared to the cost of a successful execve() in the first place. If you are experiencing a noticeable slowness, it's definitely not because of a PATH search.
Anyway, I have both /command and /package in the hard-drive based system, and only /command in the initramfs. So, unless I'm missing something, setting conf-home seems the best solution.
The fact that setting conf-home to "" works for you is an artefact, a hack that works by pure chance. It breaks slashpackage assumptions and is not guaranteed to work in the future. If you set your PATH to /command in your initramfs, and clear flag-slashpackage, you will have no PATH security issues, and no performance loss. This is the supported way of doing what you want.
Assuming that the symlinks in the hard-drive /command dir are up to date, is there any real inconvenient in hard-coding the paths in the binaries to /command rather than /package/* ? It seems the best of both worlds...
Some people want slashpackage but not slashcommand. /command is an extension to slashpackage, that provides some benefits but is not essential. Really, clearing flag-slashpackage for your initramfs doesn't hurt. And if you want a slashpackage structure in your initramfs, then do it ! Just copy the directory structure and the .../command subdirectories with the binaries inside, and have /command be a bunch of symlinks. The /package tree without the source/doc/randomcrap and the additional symlinks won't take much space in your initramfs, you have that little extra RAM, and you'll free it quite fast anyway. Or you could forego initramfs entirely, initramfs is useless. :P -- Laurent
