[Nix-dev] Discussion: env vars as glue

[Lluís Batlle i Rossell]

Hello all,

these days, since the stdenv change, many people are hitting issues with their
old installed programs failing to start due to some shared object wanting
GLIBC_2.14 things.

Nowadays, quite enough of glue can happen with env vars, and that may end up in
situations like that. /etc/profile is full of *_PLUGIN_DIRS kind of variables,
and on some popular systems libGL may be set up by NixOS through
LD_LIBRARY_PATH, instead of being part of the program closure.

These variables have some advantages and drawbacks. As advantadges, people can
install "plugins" into their profiles, and programs will find them. As
drawbacks, that will break up when programs and plugins somehow don't match. Be
it a stdenv change, x-updates, or whatever.

The interoperability of 32-bit programs in 64-bit systems may also require
out-of-default configuration of that env vars glue, as Carles Pagès pointed out
in http://comments.gmane.org/gmane.linux.distributions.nixos/10375 .

Fixing details like that of GLIBC_2.14 seems to require a comprehension of the
situation a bit over average, to end up with a working situation. The solution
isn't always "rebuild the program", as we want to be able to run old programs
too. Nix advertisements about "avoid DLL hell" don't quite match, since the last
glibc update. :)

I'd personally prefer to use the least possible that env vars glue, and I'd
rather favour an approach like that of firefoxWrapper. Then, things like plugins
could be made not to be installed "easily" into profiles.

Maybe a first task to evaluate whether those variables help more than annoy or
not would be to list use cases for them.

For example, I think that I *only* use LD_LIBRARY_PATH for the nvidia libGL.

What uses do you have for:
ALSA_PLUGIN_DIRS
GST_PLUGIN_PATH
MOZ_PLUGIN_PATH
QTWEBKIT_PLUGIN_PATH
QT_PLUGIN_PATH
STRIGI_PLUGIN_PATH

Regards,
Lluís