[Nix-dev] Discussion: env vars as glue

[phreedom at yandex.ru]

On Вторник 16 апреля 2013 00:09:23 Marc Weber wrote:
> Excerpts from Lluís Batlle i Rossell's message of Mon Apr 15 23:04:34 +0200 
2013:
> > I think that very often people hit those broken ABI issues, the DLL
> > hell,
> > thinking that nix-env does more things that joining files in a path with
> > symlinks. And I feel that we can't blame the user (as for now). :)
> 
> That's what I've been proposing for a long time, eg by writing this
> guide:
> https://nixos.org/wiki/Howto_keep_multiple_packages_up_to_date_at_once
> 
> or by using hack-nix or nixpkgs-ruby-env rather then installing
> individual plugins.
> 
> Gimp is another special case. I've implemented quite a lot of plugins:
> https://github.com/MarcWeber/nixpkgs/commit/585b42c8e7c74392bf2825b8d47d46f7
> db542f1a

But in this case, there's a single application which uses the plugins and this 
is a good approach for such a case. A KDE equivalent would be to provide 
kdeapps derivation and pass all kde apps/libs/plugins you want installed to 
it. Kind of nasty.

> and I'm declaring my config.nix installation this way:
> 
> packageOverides = p: {
>   graphicCollection = misc.collection "my-graphic-tools" [ inkscape
> (gimp.withPlugins [ "plugin-name-1" "plugin-name2"]) ] }
> 
> Then I update all graphic tools at the same time to make sure they still
> build and work.

Which doesn't really solve the case where a working app stops working because 
something incompatible sneaks in via env vars.

> Gimp is even more awkward: If you edit the global settings (which have
> to do at the moment in order to tell it about additional
> ~/.nix-profile/gimp-VERSION-plugin directories it'll hardcode the plugin
> paths in store/hash-gimp-VERSION/ gimp store path, thus after installing
> a new gimp, trouble will happen.
> 
> So this is another thing which could be fixed in a much better way. The
> comments in the commit listed should tell about these details.

QT also loves resolving symlinks :/ This sometimes can be patched, sometimes 
not :(

> Somehow this also reminds me of the "principle of least priviledge".
> Assuming you can't trust any application you should sandbox each
> application (eg use a virtual machine for firefox, a different one for
> you chat client, a different one for your email client, ...)
> 
> You'll get a lot of "safety" - but you'll loose productivity.
> 
> Given the problems which will occur such as
> - old kde/gnome app will not run in new kde/gnome environmernt
> - ...
> 
> Eg about X there might be 3 features you're interested in:
> - suspend to disk
> - 3d acceleration (opengl)
> - use external monitors
> 
> Now it may happen (for whatever reason) that not all of those features
> are provided by all implementations (radeon, ati_unfree)
> 
> We will always run into this kind of trouble.
> 
> In fact having a system profile and a user profile which "get merged"
> already might be causing problems.
> nixos-rebuild could guarantee that all kde like apps are build using the
> same kde libraries. But you loose this property if you start using a
> user profile.
> 
> In fact making nixpkgs check some properties, such that two libraries
> making up an application are built using the same glib library do make
> sense.
> 
> I somehow feel that the overall issue is too complex to be solved
> easily using the one true way. I personally feel the most efficient way is
> to think about what must be done to make something work - and in my case
> its just waiting for current libreoffice to be build - or use binaries
> using master branch..

Introducing a number of wrappers for common cases like gst and alsa with 
centralized(and overridable) config would make troubles for these frameworks go 
away but at a cost. While nixos users are quite used to the fact that some 
packages need to be added to systempackages list, some need to be activated 
via services.* etc, nix-env users don't usually encounter cases where you can 
install gst ffmpeg plugin via nix-env and it is installed and doesn't work, but 
it you add some string to some config, it starts working.

As to KDE & co, it's either framework isolation which requires work and still 
causes old apps to slowly lose functionality, or resurrecting kdePackages and 
somehow strongly encouraging users to update all kde apps at once which kind 
of defeats the use case of semi-permanently freezing an app in a specific (and 
working) state :(