I want to report an annoying problem I had some months ago with glusterfs, and tonight again with linux-PAM.
This happens anytime a program needs to load a shared library from a preconfigured place, instead of using the OS's standard search mechanism (i.e. LD_LIBRARY_PATH) for some reason or another. Usually it's the case of plugins that are loaded using a preconfigured path. The problem I have with Linux-PAM is that the directory where it's configured to install its pam_*.so modules is also hardcoded into the PAM binary itself, to later know where to find those modules. Compile correctly symlinks $target/lib/security/* to /lib/security/*, but PAM never looks in /lib/security, it uses the hardcoded path instead. No problem, but next, I compile Samba which includes pam_samba.so, correctly put in $target/lib/security, and again, correctly symlinked to /lib/security, which PAM never looks into. Now if only PAM would have two configure options, one for where to put its compiled modules, and one for where to search for them, but that wouldn't make any sense, from its point of view at least.
For now, all I can think of is putting the modules into some unmanaged path (not /lib, maybe something in /Files, because I want /S/L/L to be just symlinks) and change both PAM and Samba recipes to do that. Any other suggestions? Thanks.
I took a look at the recipe and fond that there exists both '--enable-securedir=<some dir>' and '--enable-sconfigdir=<other dir>' as options to ./configure. By setting them to $goboLibraries/security and $goboSettings/security respectively the libraries and settings installed by other applications should be found.
I've commited a recipe with these changes and the recipe should be available soon. You can look at it to see how I have solved it.
I think what I was trying to do here was to identify a more general problem with Gobolinux than a fix for PAM. I have other programs that don't have such configure options, and frankly, I don't know why they would.
Besides, you don't want to put binaries in /lib/security nor settings in /etc/security, or you'll defeat the whole idea of package management by symlinks in Gobolinux. You'll loose the trace of what package those libs and settings came from.
What I would like instead would be for PAM to look for its plugins in /lib/security, where only symlinks were to be found, and both PAM and Samba and whatever program put its PAM plugins in its own /Programs directory and have them symlinked to /lib/security.
You must have misunderstood me as your request is exactly what I did with PAM. I configured PAM to look for binaries in $goboLibraries/security and setting files in $goboSettings/security. This doesn't mean that binaries ans/or settings are installed in these paths. Instead they are installed into $target/lib/security and $settings_target/security respectively, but symlinked into the global directories, just as you want.
In more general terms applications have different approaches to accomplish the same effect. For example the Firefox recipe has "export MOZ_PLUGIN_PATH=${goboLibraries}/browser-plugins" in its environment file and all plugins should be installed in their own directory. Apache webserver has a symlink /Programs/HTTPD/2.2.8/modules -> /System/Links/Libraries/httpd/modules, and all apache httpd modules are installed into their own $target, or more specifically $target/lib/httpd/modules. A third alternative is applications that use the "share" directory. This is handled automatically by GoboLinux. Other applications are not as flexiable and has to be patched to work correctly, see my OpenSync recipe and its modules.
So we're handling most cases, but how we do it is up to what alternatives we have to work with. We try to be as unintrusive as possible, as with the PAM, Firefox and share cases, but sometimes that's not enough.