[Nix-dev] Discussion: env vars as glue

[phreedom at yandex.ru]

On Понедельник 15 апреля 2013 18:59:52 Lluís Batlle i Rossell wrote:
> 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

This is used for LADSPA plugins(various sound processing apps) and for 
input/output plugins(eg by pulseaudio).

> GST_PLUGIN_PATH

Gstreamer plugins which do all the work. Apparently these are loaded 
dynamically. Typical case: kde app plays media via phonon, which uses 
phonon_backend_gstreamer to do the actual processing.

> MOZ_PLUGIN_PATH
no idea.

> QTWEBKIT_PLUGIN_PATH
Apparently, this helps webkit steal mozilla's extensions.  Likely any kde app 
which is a browser or can use KParts(such as akregator) would want this set.

> QT_PLUGIN_PATH

I'm not at all sure, but the dirs it links to aren't empty and they link to 
things like phonon...

> STRIGI_PLUGIN_PATH
The idea was that every kde app would ship with analyzers for their specific 
data formats and possibly common specialized data formats to enable proper 
metadata extraction. Plugins can be direcly loaded by an app linking to 
libstreamanalyzer or by a nepomuk service. While strigi seems to be on its way 
out of kde 4.11, it's only because there's another replacement plugin 
framework coming.

You managed to overlook the innocently-looking KDEDIRS. On a typical KDE 
install this place contains 1k+ libs. Among these are KIPI plugins shared by 
at least gwenview, krita and digikam, Kparts plugins which are at least shared 
by konqueror and akregator and are always installed by the app supplying the 
part.... While KDE usually requires ABI compatibility in such cases, it 
doesn't help client apps  compiled against newer version.