☰

Gibt es eine Möglichkeit, mehrere Versionen eines Programms unter Linux zu installieren?

tag-icon • tag-icon software-installation
Gibt es eine Möglichkeit, mehrere Versionen eines Programms unter Linux zu installieren?

Ich versuche, es php-5.3auf Arch Linux zu installieren, aber bisones ist zu neu, also habe ich eine ältere Version aus bisonden Quellen erstellt. Und es sieht so aus, als würde es sich /usr/localstandardmäßig selbst installieren. (Ist das eine Art Konvention?) Daher frage ich mich jetzt, ob ich mehr als eine Version von bisonIE installieren kann, nebeneinander mit der Standardsystemversion und der, die ich gerade installiert habe. Solche Dinge werden wahrscheinlich selten benötigt. Ich bin einfach neugierig. Ist das schwer zu machen? Wie soll ich vorgehen?

Antwort1

Einige spezielle Software kann mit konfiguriert werden --program-suffix=-my-version-suffix. Möglicherweise müssen Sie einige der anderen Verzeichnisse anpassen, aber wenn Sie --prefixdie Standardeinstellung ( /usr/local) beibehalten, kommt es nicht zu Konflikten mit der in der Distribution enthaltenen Version in /usr.

ImallgemeinIn diesem Fall ist die einzige Distribution, die versucht, die Koinstallation beliebiger Versionen zu ermöglichen,Nix, obwohlGentooversucht, mehr Pakete zu unterstützen, als die meisten Distributionen schaffen (bei Bison ist allerdings immer nur eine Version gleichzeitig zulässig – aber es bietet immerhin eine Auswahl).

Beachten Sie jedoch, dass, wenn Ihr Quellcode mit neueren Versionen von Bison nicht mehr funktioniert, dies normalerweise ein einfaches Problem mit Ihrem Quellcode bedeutet. Normalerweise gibt es jemanden %option(oder --argument), der das Problem beheben kann.

Antwort2

Eine Möglichkeit, dieses Problem konsequent zu behandeln, ist die Verwendung dermodulesPaket. Dies funktioniert durch Ändern der Umgebungsvariablen (z. B. der Pfade zu Ihren Binärdateien).

Das Paket Environment Modules ermöglicht die dynamische Änderung der Benutzerumgebung über Moduldateien. Module können dynamisch und atomar geladen und entladen werden, auf saubere Weise.

z.B

$ module load gcc/3.1.1 
$ which gcc 
/usr/local/gcc/3.1.1/linux/bin/gcc 

$ module switch gcc gcc/3.2.0 
$ which gcc 
/usr/local/gcc/3.2.0/linux/bin/gcc

In Ihrem Fall wird die bisonVersion PATHausgewählt, die in Ihrer Umgebungsvariable zuerst vorkommt. Um diese Variable für das aktuelle Terminal manuell zu überprüfen oder zu ändern, führen Sie aus

$ echo $PATH
 ....

Priorisieren Sie /opt/bin, indem Sie es dem PATH _voranstellen:

$ export PATH="/opt/bin:$PATH"

oder anhängen /opt/bin/an PATH(wird nur ausgewählt, wenn an anderer Stelle in keine gleichnamige Binärdatei gefunden wird PATH)

$ export PATH="$PATH:/opt/bin"

Antwort3

Nur um eine aktuellere Antwort zu geben:

Ja, das ist heutzutage definitiv möglich.
Die Abhängigkeitshölle gehört der Vergangenheit an, es sei denn, die Distribution tut das auch. :)

Arch reicht jedoch nicht aus. Sie benötigen eine quellbasierte Distribution. Da die Abhängigkeiten sonst fest codiert wären (für bestimmte Definitionen von fest codiert) und beide Installationen auf dieselben Bibliotheken usw. verweisen würden.
Beim Erstellen aus dem Quellcode können Sie es jedoch jedes Mal mit unterschiedlichen Pfaden erstellen.

Gentoo hat hierfür schon lange eine Funktion namens „Slotting“, die das Ganze trivial macht. Die Abhängigkeiten einer Version eines Pakets können als ein bestimmter „Slot“ eines anderen Pakets angegeben werden. Ein Slot ist ein Bereich von Versionen, der nicht mit anderen Slots in Konflikt steht. (Bei den meisten Paketen, die ich gesehen habe, kann jede Version ihr eigener Slot sein. Besonders bei Bibliotheken. Aber manchmal kann ein Paket damit nicht umgehen, weil es selbst von Dingen abhängt, von denen es nur eines gibt. Oder weil es ein wenig Arbeit vom Paketmanager erfordert [z. B. um die installierten Konfigurationsdateien bei der Installation zu ändern])

Ich bin jedoch sicher, dass jede andere vollständige Quellcodeverteilung etwas Ähnliches haben wird.

Andernfalls besteht eine Problemumgehung immer darin, dasselbe Build-System einzurichten, mit dem die Pakete Ihrer Distribution von den Betreuern erstellt werden, die erforderlichen Pakete unter einem neuen Namen zu klonen und dort den Build-Prozess so zu ändern, dass er auf die verschiedenen Versionen der Abhängigkeiten verweist, und diese dann einfach in ein neues Nicht-Quellpaket zu integrieren, wie es die Paketbetreuer Ihrer Distribution tun würden. (Ehrlich gesagt fand ich Gentoo einfacher zu installieren. :)

verwandte Informationen