Wie können wir Fink, Port & Brew dazu bringen, parallel auf OSX Mavericks zu koexistieren?

867
Billy McCloskey

Wir verwenden es gerne brew, aber es gibt nicht viele gnomeToolset- Formeln, und wir können eine gnome-terminalsehr schnell mit installieren FinkCommander. Wir haben verschiedene Teile gnomevon Grund auf neu erstellt, aber eine brewFormel zu erstellen, nur um das zu bekommen, gnome-terminalscheint übertrieben, wenn sie bereits verfügbar ist.

Unabhängig davon hatten wir Probleme gnome-terminalbeim Erstellen FinkCommander, das heißt, bis wir alle brewinstallierten Komponentenreferenzen aus Umgebungsvariablen entfernt haben. Wir mussten auf jeden Fall hin /usr/local/binund wieder /usr/local/opt/gnu-tar/libexec/gnubinraus $PATHund nur für Tritte haben wir dafür gesorgt, dass wir $LD_LIBRARY_PATHnicht darauf hinwiesen /usr/local/libusw. Dies erlaubte erfolgreich gnome-terminalzu bauen und zu installieren FinkCommander.

Des Weiteren haben wir Software, die wir über installieren möchten brew, fink, und port - aber brewnicht gut mit anderen spielen . Dies hat zu der allgemeineren Frage geführt: Ist es genug, nur zu wechseln Pfad und Variablen Umgebung wechseln zwischen brew und fink/ port Build - Umgebungen und Installationen ? Wir wissen, wir brauchen verstecken brew von finküber Umgebungsvariablen beim Bau gnome-terminalmit FinkCommander, und die Annahme ist, dass für einige brewdefinierten Formel, das Gegenteil der Fall ist.

Was müssen wir im Allgemeinen tun, um die beste aller drei Welten zu haben? Das heißt, was zu tun ist alle drei, haben brew, finkund port, gebaut und parallel installiert? Da alle verwalteten Pakete von Grund auf erstellt wurden, sollte jedes Paket wissen, wo sich seine dynamisch verknüpften Bibliotheken befinden. Ist es genug, um zu durcheinander um den $PATH, $MANPATH, und $DYLD_LIBRARY_PATHUmgebungsvariablen on the fly eine Installation setzen vor einem anderen seine definierten Werkzeuge zu benutzen? Vermissen wir etwas?

2
Ein Gedanke wäre, 3 kleine VMs zu erstellen, deren Zweck im Leben darin besteht, "brew" -, "fink" - und "port" - "Releases" zu erstellen, die an den richtigen Ort auf dem Host exportiert und montiert oder sogar synchronisiert werden . Daher bauen die Builds auf Bibliotheken mit dem Umfang des Hosts auf, stören sich jedoch beim Erstellen nicht, und nur die erforderlichen Pfade für bin, lib, man usw. werden an die entsprechenden Speicherorte auf dem Host exportiert. Billy McCloskey vor 10 Jahren 2
rsyncing und mounten über das Brew-Paradigma würden nicht allzu gut funktionieren, da der Dereferenzierungsgrad für Brews bereits verwendet wird, dh die Tools sind in / usr / local / bin verlinkt, sodass wir die Installation nicht einfach kopieren können, aber wir würden es tun müssen Links zu den gebauten Tools verwalten. Billy McCloskey vor 10 Jahren 0
Ich hatte jedoch nie ein Problem damit. Fink, MacPorts und Brew sind ALLE auf meinem Computer installiert, und alle spielen gut. Brew löst eine * Warnung * aus, wenn es die anderen findet, funktioniert aber trotzdem einwandfrei. Caleb Xu vor 10 Jahren 0
Ja, ich habe jetzt alle zur gleichen Zeit installiert und wundere mich über die Warnung des "Braud Doctor". Das einzige, was ich als problematisch empfinden kann, ist, dass die gnu-Tools scheinbar nicht mit ACL ("gtar") umgehen, was ein Feature und kein Build-Konfigurationsproblem ist - natürlich, wenn ein anderes Tool verwendet wird hing von der Existenz dieser Features ab ... Billy McCloskey vor 10 Jahren 0
Es ist für "tar" nicht unmöglich, mit ACLs umzugehen. Für eine Implementierung, die ACLs (erklärt [hier] (http://cdrtools.sourceforge.net/private/star-acl.html) und erweiterte Attribute gut behandelt, werfen Sie einen Blick auf `star`, einen sehr ausgereiften (1982)` tar`-Implementierung, die vom ursprünglichen Autor noch aktiv verwaltet wird: Sie können sie entweder mit einem der oben genannten Port-Systeme kompilieren oder als Teil von [schilytools] (http://schilytools.sourceforge.net) installieren. Tatjana Heuser vor 8 Jahren 0

2 Antworten auf die Frage

3
raimue

Lassen Sie mich darauf antworten, dass ich aus der MacPorts-Perspektive komme, da diese Probleme der gleichzeitig vorhandenen Software-Management-Tools dort nicht unbekannt sind. Am wichtigsten ist jedoch, dass es einfach nicht möglich ist, /usr/localdie Standardpfade des Compilers zu entfernen . Dies kann bei einigen Builds zu Problemen führen, insbesondere bei der +universalKompilierung mehrerer Architekturen .

Zu Beginn des Projekts vor vielen Jahren wechselte MacPorts zu /opt/local, um Probleme mit anderer Software zu vermeiden. Eine /usr/localvollständige Isolierung von scheint allein durch Compiler-Konfigurationsflags nicht möglich zu sein. Leider haben Homebrew-Entwickler dies absichtlich ignoriert und / usr / local als Standard ausgewählt. Es klingt zwar nach einer guten Idee, da es bereits in PATH aufgeführt wäre, in der Standardkonfiguration jedoch /usr/local/binerst danach /usr/bin, wodurch das Überschreiben von Befehlszeilenprogrammen nicht möglich ist. Es gibt also keinen Vorteil der Verwendung /usr/local.

Die beste Lösung ist, Homebrew entweder auf einem anderen Pfad zu installieren (zum Beispiel /opt/homebrew) oder / usr / local vor dem Erstellen vorübergehend umzubenennen und anschließend wieder umzubenennen:

sudo mv /usr/local /usr/local.off ... # do your compilation work sudo mv /usr/local.off /usr/local

Als Randbemerkung für die Zukunft, während MacPorts in seiner aktuellen Version bereits eine Sandbox für alle Builds verwendet, gibt es Verbesserungen in diesem Bereich für Version 2.3.0 oder höher. Der neue Trace-Modus, der sich derzeit in der Entwicklung befindet, würde es ermöglichen, den gesamten Dateizugriff auf die Dateien zu beschränken, die nur für die jeweilige Erstellungsaufgabe erforderlich sind. Dadurch werden Speicherorte wie /usr/localund /swvollständig vor dem Erstellungsprozess ausgeblendet. Bei anderen Tools hilft das jedoch nicht, es sei denn, sie übernehmen auch diese Funktion.

1
Tatjana Heuser

Da jedes Port-System normalerweise mit verschiedenen Macken ausgestattet ist (und der gelegentliche Port wegen einiger Unheimlichkeit, die in seinem Abhängigkeitspfad versteckt sind), habe ich ein System, auf dem HomeBrew, MacPorts und FreePorts parallel installiert sind. Für die Build-Umgebung reicht es in der Regel aus, die anderen Portsysteminstallationen während der Erstellungs- und Kompilierungszeit nicht zu erkennen, um sie voneinander zu trennen, so dass sie keine Abhängigkeiten mehr voneinander weben oder aufgrund einer erkannten Abhängigkeit Schlimmeres versagen der falsche Hafenbaum

Bisher war es ausreichend, eine saubere Gebäudeumgebung zu initialisieren, die nur die Systemverzeichnisse enthält ( /usr/localunbedingt für MacPorts, Fink, FreePorts, siehe Raims-Antwort ) + eigene Zielverzeichnisse in ihren Suchpfaden, Linker-Pfad usw. Weise bereits in der obigen Frage beschrieben.

Für den Aufbau präventiere ich die Portsystem-Baumstruktur in der Reihenfolge der durchsuchten Verzeichnisse, um zu vermeiden, dass Konfigurationsprobleme wegen veralteter Versionen im Standard-MacOSX vom Port-Build-System erkannt werden. Für den Benutzer, der den Port ausführt, ist es sicherer, diese Bäume anzufügen, um den vom Betriebssystem bereitgestellten Binärdateien den Vorzug zu geben.

Wenn Sie die installierten Port Trees kopieren müssen, dittoist das Werkzeug der Wahl. Aus der Manpage:

dittoBewahrt Ressourcen-Gabeln und HFS-Metadaten-Informationen beim Kopieren auf, sofern nicht anders angegeben --norsrc. Ebenso dittowerden erweiterte Attribute und Zugriffssteuerungslisten (ACLs) beibehalten, sofern --noextattroder nicht übergeben --noaclwird.

Eine andere Option wäre /usr/bin/rsync -avSEH:

  • aArchivierungsmodus,
  • verbose ist optional,
  • E um erweiterte Attribute und ACLs zu erhalten,
  • S um Dateien mit geringer Dichte korrekt zu behandeln (ohne sie auf ihre volle Kapazität auszudehnen und mehr Platz als das Original zu beanspruchen), und
  • H um harte Links zu erhalten.

Wenn Sie tarmit ACLs ( hier erklärt ) und erweiterten Attributen gut umgehen möchten star, sehen Sie sich eine sehr ausgereifte (1982) tarImplementierung an, die vom ursprünglichen Autor immer noch aktiv verwaltet wird. Sie können es entweder mit einem der oben genannten Port-Systeme kompilieren oder als Teil von installieren schilytools.

Verwandte Probleme