Zum Beispiel wenn ich ghc (einen Haskell-Compiler) installieren will, aber der als erstes mal Perl 5.8 installieren will. Als ob ich unter Tiger nicht schon ein durchaus brauchbares Perl 5.8.6 auf der Platte hätte, nein, die DarwinPorts wollen eigene Versionen davon. Und dann hab ich je nach Pfadeinstellung mal das Apple-Perl oder eben das von DarwinPorts aktiv. Ziemlich dämlich - ich finde da müssten in die DarwinPorts Pseudopakete rein, die dann auf die vorinstallierten Versionen von Apple verweisen.
Das macht ganz besonders dann Probleme, wenn man selber auch Pakete so von Hand installiert. Denn dann wird teilweise das über den Pfad erreichbare Perl genommen - und mit aktiven DarwinPorts ist das halt das dort. Was aber absolut nicht der gewünschte Effekt ist - schliesslich ist das Perl in diesem Fall nur deshalb reingekommen, weil der Port für ghc eine build-dependency hat. Ich will aber garnicht das DarwinPorts Perl benutzen ...
Aus dem gleichen Grund sind die ganzen Python und Ruby Module in DarwinPorts IMHO unbrauchbar: sie ziehen automatisch eine neue Installation von Python und Ruby nach sich und nutzen nicht die vorinstallierte Version. Selten dämlich ...
Im Ergebnis kann man DarwinPorts auf einer OS X Kiste nur für gut isolierte Tools benutzen - was aber irgendwie schade ist, denn die Idee und die Umsetzung an sich ist ziemlich klasse. Nur wird halt zu wenig Rücksicht auf die schon installierten Sachen genommen.
ghc hab ich übrigens einfach über das Binary-Paket von haskell.org installiert. Da steht zwar das sei für 10.3, tuts aber auch mit 10.4 - jedenfalls das was ich damit mache. Und erspart mir das ganze Zeugs zu builden.
Peter July 9, 2005, 11:57 a.m.
Hm, wie wäre es denn mit Fink? Da gibt es derartige Pseudopackages. Fink hat auch den Vorteil, daß es sich nicht über das ganze Dateisystem verteilt, sondern unter einem zentralen Directory /sw steht. Mag man natürlich auch als Nachteil auslegen können. Ich kann mich nie so recht zwischen Fink und Darwinports entscheiden; Kriterium für Fink war bei mir ursprünglich, daß es auf dem Debian-Packagingsystem beruht und auch fertige Binärpakete gibt; mittlerweile ist aber bei mir auch alles selbst compiliert...
hugo July 9, 2005, 12:12 p.m.
DarwinPorts verteilt sich auch nicht über das ganze Filesystem sondern liegt in einem eigenen Tree - üblicherweise /opt/local/, lässt sich aber einstellen. Und Fink hat den generellen Nachteil das es viel zu wenig Pakete enthält und die verschiedenen Trees für die verschiedenen OS X Versionen nicht sonderlich synchron laufen - wärend DarwinPorts auf jedem Darwin gleich läuft. Das war ja auch der Grund warum ich auf DarwinPorts gewechselt bin, vorher hatte ich Fink - war aber noch viel weniger brauchbar.
Python, Perl, Ruby und PHP Pakete kann man ja auch mit dem jeweiligen Paketmechanismus der Sprache (setup.py, Makefile.PL, Ruby Gems und PEAR) installieren, da braucht man DarwinPorts nicht zwingend. Nervig sind halt nur die Dependencies die in manchen DarwinPorts drin sind. Das ist aber bei Fink auch nicht viel anders - sofern es da überhaupt das entsprechende Paket gibt ...
Markus Feb. 8, 2006, 3:04 p.m.
Es gibt gute Gruende fuer die "doppelten" Installationen:
1. Das Python von OS X ist Version 2.3, das der DarwinPorts 2.4
2. DarwinPorts muss auf 10.3 und 10.4 laufen - viele Apple Software hat unterschiedliche Versionen auf den beiden Systemen
3. Die Apple-Software laesst sich nicht patchen - z. B. der Suchpfad der Pyton-Module. Ansonsten muessten alle Module irgendwo nach /Library/.. installiert werden.
4. Exponentieller Testaufwand: Um Alle Kombinationen von 10.3/10.4, Apple's Python, DarwinPorts Python, ia32/ppc, etc., etc. zu testen erfordert einen immensen Aufwand.
5. Inkompatibilitaet durch Security-Fixes: Apple hast z. B. alte zlib-header (aus Kompatibilitaetsgruenden) aber eine Biltiothek mit den aktuellen Security Fixes. Z. B. openssl weigert sich mit offenbar veralteten zlib-Headern zu kompilieren...
Gruende gegen die doppelte Installation:
1. Platzverschwendung: Bestimmt ~10MB fuer Python!
Schade, dass Du offenbar nie die die Mailingliste gelesen hast - die fuenf genannten Punkte wurden da naemlich schon ausfuehrlich diskutiert.
hugo Feb. 8, 2006, 3:15 p.m.
Genau die Probleme liessen sich über Pseudo-Pakete, die einfach auf die vorinstallierten Versionen verweisen - lösen. Fink macht genau das mit einigen Paketen. Es gibt keinen Grund, warum DarwinPorts das nicht kann, zumal viele der Ports sich auch problemlos über Varianten dann z.B. für Python 2.3 installieren liessen.
Und es geht auch nicht um exponentiellen Testaufwand: die vorinstallierten Pythons sind relativ wenig verschiedene, gerade bei z.B. den reinen Python-Modulen ist die Installation ziemlich einfach mit verschiedenen Pyhtons machbar. Die Dual-Installation von den DarwinPorts-Paketen hingegen machen massive Probleme, denn z.B. für Framework-Builds _muss_ das ganze Geraffel eh in die entsprechenden Apple Systemordner wandern.
Und gerade Buildabhängigkeiten für Tools sind wirklich idiotisch - wie z.B. die Abhängigkeit vom ghc auf das Darwin-Perl. Perl wird beim ghc nur für ein paar Scripte gebraucht, die laufen genauso gut mit dem OS X mitgelieferten Perl - es gibt keinen Grund, da gleich eine ganze komplette neue Perlumgebung auf das System zu kippen.
Jedes Paketsystem mit binären Paketen hat natürlich das Problem, das es feste Abhängigkeiten hat und daher manchmal etwas unflexibel ist - kennt jeder, der mit Debian arbeitet. Aber die DarwinPorts haben gerade mit ihren Varianten und der Source-Basierung den Vorteil, das sie höhere Flexibilität bieten könnten. Nur wird genau das eben nicht genutzt.
Markus Feb. 8, 2006, 3:30 p.m.
Es braucht keine Pseudo-Pakete, DarwinPorts kann sehr wohl bei vorhandenem Perl-Interpreter auf die eigene Perl-Installation verzichten.
Das Problem bleibt: Python 2.3 und 2.4 sind nicht 100% kompatibel - d. h. falls beide unterstuetzt werden sollen, waechst der Testaufwand um Faktor 2. Noch einmal um denselben Faktor, falls auch das Python von 10.3 unterstuetzt werden soll.
Wg. ghc: Hast Du den Maintainer schon einmal deswegen kontaktiert? Vielleicht funktioniert das Perl von 10.3 nicht fuer den Build.
Und wg. den eigenen Installationen: Kein Deployment-System der Welt schafft es, manuell installierte Software zuverlaessig einzubinden. Vielleicht solltest Du besser helfen die Ports im DP-System zu verbessern, als Dein eigenes Sueppchen zu kochen und Dich ueber mangelnde Interoperabilitaet zu beschweren.
Btw. muessen Frameworks weder in /System/.. noch in /Library/.. liegen. Z. B. DPs python24 ist ein Framework und liegt brav innerhalb des DP-Verzeichnisses.
hugo Feb. 8, 2006, 3:59 p.m.
Hachja, wenn ich für jedes Mal wo irgendwelche Projekt-Advokaten mich auffordern ihr Projekt zu unterstützen einen Euro bekommen hätte, hätte ich jetzt, was weiß ich, 50 Euro oder so ;-)
Sorry, aber python 2.3 oder 2.4 oder der Testaufwand (der übrigens bei reinen Python-Modulen ziemlich gering ist, ich mach nun schon lange genug selber Python-Projekte für verschiedene Python-Versionen) hat nix damit zu tun, das ghc in DarwinPorts eine Dependency auf perl hat und es deshalb mit builded, obwohl für den verwendeten Zweck das vorhandene Perl völlig ausreicht (was glaubst du wohl, wie die ghc-Pakete auf haskell.org entstanden sind? Vom Himmel gefallen?).
Das man zur einfachen Nutzung eines Python-Moduls bei DarwinPorts erstmal das DarwinPorts-Python installieren muss (gleiches gilt für die Perl und Ruby Module), ist schlichtweg ein Ärgernis. Und aus Benutzersicht ein Designbug, denn man will ja gerade _nicht_ ein neues Python installieren, sondern das vorhandene nutzen (weil z.B. dort schon Module drin sind, die im DP nicht drin sind).
Und es geht nicht darum, das ein Deploy-System versuchen soll manuell installierte Sachen zu integrieren, es geht darum, das DP ein Deploysystem ist, welches die vorhandene Infrastruktur dupliziert.
Frameworks ausserhalb der /Library (and friends) Struktur abzulegen geht natürlich - klar. Aber das sind dan private Frameworks, die nur von Programmen benutzt werden können, die diese Ablageorte ebenfalls in den Builds berücksichtigen. Der Sinn von Frameworks ist aber gerade, das diese an zentraler Stelle liegend von mehreren Programmen geshared werden. Genau dafür unterstützen Frameworks ja auch Versionen ...
DarwinPorts verhält sich schlicht und einfach an vielen Stellen (die oben sind einfach nur welche die mir direkt eingefallen sind) als Fremdkörper im System. Und das ist manchmal ziemlich ärgerlich. Denn ganz besonders bei Source-basierten Deploy-Systemen ist es nervig, wenn ein Monster wie Python oder Perl (oder Gnome!) einfach als Abhängigkeit dazugezogen wird, nur weil jemand da eine Dependency gesetzt hat. Schliesslich muss man auf den Compile der unnützen Pakete ja auch warten ...
hugo Feb. 8, 2006, 4:13 p.m.
Achso, und natürlich generell macht es Sinn, auf das Datum zu gucken - der Beitrag ist vom Sommer letzten Jahres, von daher können natürlich schon einige der Punkte anders sein. Ich hab - da jetzt ghc ja läuft - natürlich danach nicht mehr geguckt, welche Dependencies dort jetzt gesetzt sind.