[Nix-dev] Re: nix-env and meta

[Marc Weber]

Excerpts from Yury G. Kudryashov's message of Wed Oct 06 08:07:01 +0200 2010:
> Marc Weber wrote:
> 
> > Excerpts from Yury G. Kudryashov's message of Tue Oct 05 21:38:50 +0200
> > 2010:
> >> I'd like to have all the information about "what is propagated" handled
> >> by nix, not bash/perl. It is easy to achieve for normal
> >> propagatedBuildInputs (see, e.g., builderDefs) but I don't know how to
> >> make nix-env aware of such propagations. Any ideas?
> > 
> > Can you give some reasons why you dislike bash perl for that?
> >
> > propagatedBuildInputs is different from /propagated-user-env-packages
> My main point is that propagated user env packages should be handled by nix, 
> not perl. This is true because kdelibs should propagate kdebase-runtime to 
> user-env, and kdebase-runtime depends on kdelibs. I think that there are 
> many other cycles like this.

I got the point. I think you're right that using Nix only could be the
cleanest solution.

If both depend on each other anyway you could consider creating a meta
package:

  kdeLibsAndRuntime = stdens.mkDerivation = {
    propagatedBuildInputs = [ kdebase kdebaseRuntime ];

    postInstall = ''
    echo ${kdebase} ${kdebaseRuntime} >> $out/nix-support/propagated-user-env-packages
    '';
  };

And use that package instead of either kdebase/kderuntime.

But I don't know whether propagated-user-env-packages would propagate
enough.

How should a Nix solution look like? Any suggestions?

I coded up traversing the dependency tree once for an alsa* experiment.
The idea was to attach some info to executables that they may be wrapped
by a path to alsaPlugins. But maybe my design was too complicated for
that use case.

Marc Weber