Best Practice: update-alternatives vs. PATH

[mattelacchiato]

Ahoi,

ich habe auf mehreren Servern die Aufgabe, Ruby Installationen (genauer: JRuby) zu warten. Die Binaries liegen alle unter /usr/local/jruby/bin. Nun habe ich zwei Möglichkeiten, wie Benutzer und Skripte jruby aufrufen können
a) über update-alternatives wird jedes executable nach /usr/bin verlinkt.
-Vorteil: Es funktioniert in jedem Environment, da /usr/bin immer im PATH enthalten ist.
-Nachteil: Für jedes neue Executable, was hinzukommt (z.B. bundler, rake, gem,...) müssen neue Links gesetzt werden.
b) die PATH-Variable wird um /usr/local/jruby/bin erweitert.
-Vorteil: Neue Executables sind automatisch über PATH erreichbar
-Nachteil: Es muss sichergestellt sein, dass in jeder Umgebung/Shell PATH richtig gesetzt ist (z.B. interactive bash, non-interactive Bash, Cron)

Was ist aus eurer Sicht Best Practice?

(RVM kommt für uns derzeit noch nicht in Frage.)

Vielen Dank,
Matthias

[feltel]

Ich würds über PATH machen und den dann in /etc/environment erweitern.

[mattelacchiato]

Danke für den Hinweis!

Hmm, zwar übernimmt Cron normale Variablen aus /etc/environment, allerdings überschreibt es selbst die PATH-Variable. Die einzige Möglichkeit, die ich bisher gefunden habe, ist in jeder einzelnen Crontab PATH explizit neu zu setzen. Was auch nicht gerade die tollste Lösung ist

Lg,
Matthias

[Meillo]

update-alternatives ist doch eher für die Distribution selbst da, um zum Beispiel verschiedene vi-Clones zu verwalten. update-alternatives löst das Problem, dass man mehrere Implementierungen einer Programmnamens in der Distribution hat.

Das Problem der Priorität zwischen offiziellen Paketen und selbst kompilierter Software (also /usr/bin vs. /usr/local/bin) ist eher eine Sache von $PATH.