Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Software>Wie 10.12.6 mit aktuellerem php als 5.6.30 ausrüsten?

Wie 10.12.6 mit aktuellerem php als 5.6.30 ausrüsten?

virk
virk03.08.2109:32
Kann ich 10.12.6 (server) mit aktuellerem php als 5.6.30 ausrüsten? Wenn ja, interessiere ich mich für eine Möglichkeit, die möglichst fehlerunanfällig ist. Wer hat da einen Tipp?
„Gaststättenbetrieb sucht für Restaurant und Biergarten Servierer:innen und außen.“
0

Kommentare

Peter Eckel03.08.2109:43
1. Homebrew installieren:

2. PHP in der aktuellsten Version (8.0.x derzeit) installieren:
brew install php

3. Alternativ ältere Version installieren:
brew install php@7.3

Über kurz oder lang wird an Homebrew (oder meinetwegen MacPorts) kein Weg vorbeigehen, weil Apple mittelfristig auch wesentliche Scriptsprachen wie Python nicht mehr mitzuliefern gedenkt.
„Ceterum censeo librum facierum esse delendum.“
+4
Weia
Weia03.08.2110:01
Peter Eckel
Über kurz oder lang wird an Homebrew (oder meinetwegen MacPorts) kein Weg vorbeigehen, weil Apple mittelfristig auch wesentliche Scriptsprachen wie Python nicht mehr mitzuliefern gedenkt.
Aber warum Python oder was auch immer dann nicht einfach direkt installieren? Ich habe nie verstanden, wozu Homebrew oder MacPorts mit ihren Non-Standard-Modifikationen und -Pfaden gut sein sollen.

Ich meine, was ist an make install ein Problem?
„🦖The dinosaurs invented Jesus to test our confidence in science“
0
sunni03.08.2110:20
Fehlerunanfällig und etwas unter einem nicht mehr unterstützen macOS nachrüsten passt nicht zusammen.
Und gerade unter einem macOS mit Server App ist das eine nicht zu unterschätzende Herausforderung.

Hier gäbe es aber eine PHP Version bis macOS 10.13: https://php-osx.liip.ch


Alternative: VM mit einem Linux, z.b. Ubuntu und darin den WebServer mit PHP einrichten.


Oder wie Peter Eckel schrieb, mit HomeBrew.
+1
logo03.08.2110:31
Homebrew hat aber auch eine Limitierung bzgl. unterstütztem OS (Mojave). Insbes. wenn die Command Line Tools benötigt werden, dann wird Homebrew mäkelig.
+1
milk
milk03.08.2111:09
Weia
Ich habe nie verstanden, wozu Homebrew oder MacPorts mit ihren Non-Standard-Modifikationen und -Pfaden gut sein sollen.
Brew und Co. kümmern sich wunderbar um die Abhängigkeiten zwischen verschiedenen Paketen und machen das Aktualisieren installierter Pakete sehr einfach. Ich verwende das seit vielen Jahren zu großer Zufriedenheit, weil ich mittlerweile mehr Wert auf einfach zu verwaltende Software lege als auf das tiefe Verständnis, was durch manuelle Installationen gefördert wird.

Dass solche Tools in manchen Fällen (wie brandneuen macOS-Versionen etwa...) auch mal Ärger machen können darf aber natürlich nicht verschwiegen werden.
+2
logo03.08.2111:11
Weia
Ich habe nie verstanden, wozu Homebrew oder MacPorts mit ihren Non-Standard-Modifikationen und -Pfaden gut sein sollen.

Ich meine, was ist an make install ein Problem?

Z.B. braucht man keine Root-Rechte zur Installation und es wird auch keine Basis-Konfiguration zerschossen.
0
Weia
Weia03.08.2111:45
logo
Z.B. braucht man keine Root-Rechte zur Installation
Homebrew & Co installieren mit Nutzerrechten? Na dann gute Nacht, Sicherheit.

Wem ein sudo bash schon zu hoch ist, der sollte sich von der Unix-Ebene vielleicht einfach fernhalten.
und es wird auch keine Basis-Konfiguration zerschossen.
In den 30 Jahren, in denen ich Unix-Programme installiere, bin ich noch nie in einer derartigen Gefahr gewesen. Wie sollte das auch gehen? Mit macOS mitgelieferte Programme befinden sich in /bin/ und /usr/bin/, mit make install erstellte in /usr/local/. Gut, vor 30 Jahren konnte man sich darauf nicht unbedingt verlassen, aber heutzutage kann man.
„🦖The dinosaurs invented Jesus to test our confidence in science“
-1
Peter Eckel03.08.2112:00
Weia
Aber warum Python oder was auch immer dann nicht einfach direkt installieren? Ich habe nie verstanden, wozu Homebrew oder MacPorts mit ihren Non-Standard-Modifikationen und -Pfaden gut sein sollen.

Ich meine, was ist an make install ein Problem?
Für Dich und mich vielleicht nichts (ich habe das jahrelang unter diversen Unices auch so gehandhabt, teils weil es auf den kommerziellen Systemen auch ohne erheblichen finanziellen Aufwand gar nicht anders ging).

Aber erstens ist es deutlich aufwendiger. Zweitens ist es schwieriger, die Pakete up to date zu halten, gerade wenn man viele davon hat. Ein einfaches "brew upgrade" ist schon fixer als alle Pakete nach Updates durchzugehen, Aktualisierungen und Abhänigkeiten zu finden, die dann jeweils durch den configure/make/make install-Zyklus durchlaufen zu lassen, gegebenenfalls noch systemspezifische Anpassungen zu machen und so weiter.

Ich glaube nicht, daß (außer Dir ) irgendjemand die Sinnhaftigkeit von Paketmanagern anzweifelt, der mehr als einen Rechner betreut und nicht unendlich viel Zeit hat.
„Ceterum censeo librum facierum esse delendum.“
+1
Peter Eckel03.08.2112:01
logo
Homebrew hat aber auch eine Limitierung bzgl. unterstütztem OS (Mojave). Insbes. wenn die Command Line Tools benötigt werden, dann wird Homebrew mäkelig.
Wo genau ist das Problem? Die XCode Command Line Tools (bzw. gleich das ganze XCode-Paket) mußt Du auch in der passenden Version installieren, wenn Du die Pakete selbst kompilieren willst.
„Ceterum censeo librum facierum esse delendum.“
+1
Weia
Weia03.08.2112:10
Peter Eckel
Ich glaube nicht, daß (außer Dir ) irgendjemand die Sinnhaftigkeit von Paketmanagern anzweifelt,
Die Sinnhaftigkeit von Paketmanagern will ich gar nicht anzweifeln, wenn sie sich an die Konventionen halten. Aber genau das tun Hombrew & Co eben nicht. Sie erzeugen Parallelwelten mit Nicht-Standard-Pfaden und hast Du Dir schon mal eine der Source-Code-Modifikationen näher angesehen, die Homebrew & Co – teils ohne jede Not – vornehmen? Mir sträuben sich da die Nackenhaare.

Gegen eine hübsche Cocoa-App, wo man ganz einfach per Häkchen festlegt, was man in /usr/local/ haben will, hätte ich gar nichts einzuwenden. (Ich habe hier sogar eine , aber die ist leider zu speziell auf mich zugeschnitten, als dass ich sie veröffentlichen könnte ohne → unendlich viel Zeit.)
„🦖The dinosaurs invented Jesus to test our confidence in science“
+1
Peter Eckel03.08.2112:11
Weia
Homebrew & Co installieren mit Nutzerrechten? Na dann gute Nacht, Sicherheit.
Du hast offenkundig keine Erfahrung mit Homebrew.

Erstens installiert Homebrew seinen Kram in der Tat mit Nutzerrechten und erfordert keine Root-Berechtigung. Wo genau siehst Du da das Sicherheitsproblem? Systemdateien werden nicht überschrieben (geht auch nicht). Es existiert lediglich ein Verzeichnisbaum, der vom Benutzer beschreibbar ist und in dem die von Homebrew installierten Pakete liegen. Das ist erstmal nichts anderes als das, was Du auch bekommst, wenn Du die Pakete selbst kompilierst und sie dann irgendwo ablegst, wo Du das darfst.

Ein Sicherheitsproblem bekommst Du, wenn Du diese Pakete dann mit Systemrechten laufen läßt. Auch das ist nichts anderes als das, was passiert, wenn Du Deinen Kram selbst übersetzt.
Weia
Wem ein sudo bash schon zu hoch ist, der sollte sich von der Unix-Ebene vielleicht einfach fernhalten.
Wer ein sudo bash einsetzt und das für eine Kleinigkeit hält, die man so aus der Tasche zaubert, sollte die Finger vom Betriebssystem lassen. Das ist das größtmögliche Kaliber an Umgehung der Systemsicherheits-Mechanismen, wenn man mal vom Abschalten von SIP bzw. SELinux und Co. absieht.
Weia
In den 30 Jahren, in denen ich Unix-Programme installiere, bin ich noch nie in einer derartigen Gefahr gewesen. Wie sollte das auch gehen? Mit macOS mitgelieferte Programme befinden sich in /bin/ und /usr/bin/, mit make install erstellte in /usr/local/. Gut, vor 30 Jahren konnte man sich darauf nicht unbedingt verlassen, aber heutzutage kann man.
Genau wie bei Homebrew.

Und nein, kann man nicht im allgemeinen. Da kann Dir jeder Paketautor in die Suppe spucken, und manche tun es auch. Was dann besonders beim Installieren unter Root-Rechten Spaß bereitet.
„Ceterum censeo librum facierum esse delendum.“
+1
Peter Eckel03.08.2112:17
Weia
Die Sinnhaftigkeit von Paketmanagern will ich gar nicht anzweifeln, wenn sie sich an die Konventionen halten. Aber genau das tun Hombrew & Co eben nicht. Sie erzeugen Parallelwelten mit Nicht-Standard-Pfaden und hast Du Dir schon mal eine der Source-Code-Modifikationen näher angesehen, die Homebrew & Co – teils ohne jede Not – vornehmen? Mir sträuben sich da die Nackenhaare.
Homebrew installiert seine Pakete unter /usr/local/Cellar/<Paket> und erzeugt für Pakete, die dann ohne weitere Spezifikation erreichbar sein sollen (die meisten) Symlinks unter /usr/local. Das ist soweit erstmal ziemlich nah am Standard, schafft aber auch noch die Möglichkeit, unterschiedliche Versionen zu installieren und die dann per brew link bedarfsweise zu aktivieren. Ich muß z.B. regelmäßig Pakete in verschiedenen Versionen benutzen, und die Umschaltung ist so ziemlich komfortabel.

Will ich das mit selbstkompilierten Paketen machen, muß ich den Mechanismus per configure-Option und alternativen PATH-Einstellungen nachbauen. Das ist jetzt nicht wirklich näher am Standard.
Weia
Gegen eine hübsche Cocoa-App, wo man ganz einfach per Häkchen festlegt, was man in /usr/local/ haben will, hätte ich gar nichts einzuwenden. (Ich habe hier sogar eine, aber die ist leider zu speziell auf mich zugeschnitten, als dass ich sie veröffentlichen könnte ohne → unendlich viel Zeit.)
Gegen eine "hübsche Cocoa-App" mit Häkchen hätte ich ziemlich viel einzuwenden. Standard ist in der Unix-Welt CLI, nicht irgendwelcher Klickibunti-Kram, der mich nur sinnlos Zeit kostet.
„Ceterum censeo librum facierum esse delendum.“
0
Weia
Weia03.08.2112:49
Peter Eckel
Weia
Homebrew & Co installieren mit Nutzerrechten? Na dann gute Nacht, Sicherheit.
Du hast offenkundig keine Erfahrung mit Homebrew.
Das stimmt. Einmal vor grob einem Jahrzehnt testweise auf einem Test-Mac installiert und mit Schaudern ganz schnell wieder gelöscht. 😱
Erstens installiert Homebrew seinen Kram in der Tat mit Nutzerrechten und erfordert keine Root-Berechtigung. Wo genau siehst Du da das Sicherheitsproblem?
Dass jeder beliebige Bösling, den ich mir als Nutzer einfange (nicht, dass mir persönlich das mal passiert wäre, aber prinzipiell), ohne weiteres unbemerkt ein Unix-Utility gegen ein modifiziertes austauschen kann?
Es existiert lediglich ein Verzeichnisbaum, der vom Benutzer beschreibbar ist und in dem die von Homebrew installierten Pakete liegen.
Yep, genau das ist doch das Sicherheitsloch.
Das ist erstmal nichts anderes als das, was Du auch bekommst, wenn Du die Pakete selbst kompilierst und sie dann irgendwo ablegst, wo Du das darfst.
Wie das? Wenn ich die in /usr/local/ ablege, können nur Prozesse mit root-Rechten Änderungen daran vornehmen. Das ist der Unterschied ums Ganze.
Ein Sicherheitsproblem bekommst Du, wenn Du diese Pakete dann mit Systemrechten laufen läßt.
Nö. Warum ist das nur schlimm, wenn ich das mit Systemrechten laufen lasse? Es reicht doch völlig, wenn ich ein ohne mein Wissen modifiziertes Unix-Programm aus irgendeinem Grund tagein, tagaus mit Nutzerrechten laufen lasse und das dann fröhlich nach Hause telefoniert und alles Mögliche aus meinem Nutzerkonto hinüberfunkt.
Auch das ist nichts anderes als das, was passiert, wenn Du Deinen Kram selbst übersetzt.
Das ist völlig anders, weil ich es mit Schreibzugriff ausschließlich durch root installiere. Davon, dass der originale Source Code nicht von Leuten modifiziert wurde, die teils offenkundig keinen Plan haben, mal ganz abgesehen.
Wer ein sudo bash einsetzt und das für eine Kleinigkeit hält, die man so aus der Tasche zaubert, sollte die Finger vom Betriebssystem lassen.
Naja, ich tue das gar nicht – ich aktiviere auf einem neuen System als allererstes den root-User und brauche daher nur su. Da sehe ich nun wiederum keinerlei Sicherheitsproblem und bei sudo bash erst recht nicht. Der Herr über meinen Computer bin immer noch ich und sobald ich root aktiviert habe, machen meine Finger gaaanz viel im Betriebssystem.
Das ist das größtmögliche Kaliber an Umgehung der Systemsicherheits-Mechanismen, wenn man mal vom Abschalten von SIP bzw. SELinux und Co. absieht.
So wie ich standardmäßig sofort root aktiviere auf einem neuen Mac, so schalte ich ebenfalls sofort standardmäßig SIP aus. Eine Form von Sicherheitsdenken, wo Apple mehr darf als ich, geht mir persönlich komplett gegen den Strich. Für mich ist ein Computer zuvorderst ein Werkzeug zur Autonomie und gerade nicht zur Fremdbestimmtheit. Außerdem kann ich diesbezüglich partout kein Sicherheitsproblem erkennen. Sicherheit vor dem Wesen an der Tastatur vielleicht, aber die will ich nicht.
„🦖The dinosaurs invented Jesus to test our confidence in science“
-1
Weia
Weia03.08.2112:59
Peter Eckel
Homebrew installiert seine Pakete unter /usr/local/Cellar/<Paket> und erzeugt für Pakete, die dann ohne weitere Spezifikation erreichbar sein sollen (die meisten) Symlinks unter /usr/local.
Allein schon diese Symlink-Orgie triebe mich in den Wahnsinn. So ein sinnloser und unästhetischer Overhead.
Ich muß z.B. regelmäßig Pakete in verschiedenen Versionen benutzen, und die Umschaltung ist so ziemlich komfortabel.
OK, das kann ich nachvollziehen. Diese Anforderung ist mir allerdings nie begegnet.
Gegen eine "hübsche Cocoa-App" mit Häkchen hätte ich ziemlich viel einzuwenden. Standard ist in der Unix-Welt CLI,
Standard sind der Unix-Welt aber auch /usr/local/ und der root-Nutzer. Und jeden Standard kann man ändern.

In meinem Verständnis richtet sich Homebrew in erster Linie an Dummies und denen ist mit einer GUI noch mehr geholfen.
nicht irgendwelcher Klickibunti-Kram, der mich nur sinnlos Zeit kostet.
Nun musst Du mir nur noch verraten, wieso ein Klick auf den Button Installiere Homebrew länger dauern soll als
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

ins Terminal zu kopieren und Return zu drücken.
„🦖The dinosaurs invented Jesus to test our confidence in science“
+1
Peter Eckel03.08.2113:13
Weia
Nun musst Du mir nur noch verraten, wieso ein Klick auf den Button Installiere Homebrew länger dauern soll als
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

ins Terminal zu kopieren und Return zu drücken.

Es geht nicht um eine Erstinstallation. Es geht um jede einzelne Installation jedes einzelnen Pakets. Es geht darum, zwischen Paketen hin- und herzuschalten. Es geht darum, Pakete zu installieren oder eben nicht.

Jeder Aufruf eines GUI-Tools mit irgendwelchen mehr oder weniger sinnvollen grafischen Benutzerelementen, die es anzuklicken gilt, ist eine Unterbrechung meines Arbeitsprozesses, der zu geschätzt 70-80% auf der Kommandozeile stattfindet.

Zu Deiner Anmerkung, Homebrew sei "für Dummies" ... dann bin ich halt ein Dummy, damit kann ich leben. Dann sind aber natürlich auch alle Nutzer von Paketmanagern wie yum und apt Dummies, also befinde ich mich in recht guter Gesellschaft.

Von "sinnlosem und unästhetischen Overhead" zu sprechen und die Installation von Paketen aus den Sourcen als Alternative darzustellen kann eigentlich bestenfalls als Satire aufgefaßt werden - und wie gesagt, ich habe das viele Jahre lang gemacht und bin sehr froh, daß ich mir bis auf Ausnahmefälle diese vollkommen mühselige und sinnlose Tätigkeit vom Hals schaffen kann.
„Ceterum censeo librum facierum esse delendum.“
+1
Weia
Weia03.08.2113:24
Peter Eckel
Zu Deiner Anmerkung, Homebrew sei "für Dummies" ... dann bin ich halt ein Dummy, damit kann ich leben. Dann sind aber natürlich auch alle Nutzer von Paketmanagern wie yum und apt Dummies
Wie das? Ich kenne nur apt, aber das installiert als root in die Originalpfade und mir wäre zumindest nicht bekannt, dass es Source Code modifiziert.

Mit apt habe ich gar kein Problem.
also befinde ich mich in recht guter Gesellschaft.
Das tust Du als Mitglied des MacTechNews-Forums doch ohnehin!
Von "sinnlosem und unästhetischen Overhead" zu sprechen und die Installation von Paketen aus den Sourcen als Alternative darzustellen kann eigentlich bestenfalls als Satire aufgefaßt werden
Gibt halt solche und solche auf der Welt.
„🦖The dinosaurs invented Jesus to test our confidence in science“
0
Peter Eckel03.08.2113:48
Weia
Wie das? Ich kenne nur apt, aber das installiert als root in die Originalpfade und mir wäre zumindest nicht bekannt, dass es Source Code modifiziert.
Darum geht es mir an dieser Stelle gar nicht. Deinem "Dummy"-Statement habe ich entnommen, daß Du es für die "Non-Dummy"-Vorgehensweise hältst, handgeschmiedete Pakete via configure/make/make install ins System zu dengeln, anstatt die Variante für Weichlinge zu wählen und das einen Paketmanager machen zu lassen. Möglicherweise habe ich das mißverstanden.

Ansonsten könnte man natürlich auch argumentieren, daß es eher Zeichen des Dummytums ist, stundenlang Abhängigkeiten manuell aufzulösen und Code durch Compiler zu quetschen, als mit Hilfe eines Paketmanagers (welches auch immer) den Computer das machen zu lassen, was er besser kann, und seinerseits ernsthafte Arbeit mit dem installierten Zeug zu vollbringen.

Übrigens: Wenn Du das unbedingt willst, kannst Du Homebrew auch unter root installieren - dann gehört der /usr/local/Cellar-Baum auch root und die Zugriffsrechte sind dann eher nach Deinem Geschmack.

Ich persönlich lasse übrigens nicht so gern fremde Makefiles unter root-Rechten laufen. Das bringt auch ganz erhebliche Sicherheitsprobleme mit sich, wenn man die Dinger vorher nicht genau inspiziert hat. Auch das ist schon ein guter Grund, der Handinstallation nicht so hinterherzutrauern, zumal ich, wenn mich die Sehnsucht packen sollte, ja schnell eine VM hochfahren und einen gcc darauf bootstrappen kann ... das war damals unter AIX und Slowlaris immer eine Riesenfreude und der Rechner war einen halben Tag beschäftigt
„Ceterum censeo librum facierum esse delendum.“
+2
Weia
Weia03.08.2114:16
Peter Eckel
Darum geht es mir an dieser Stelle gar nicht. Deinem "Dummy"-Statement habe ich entnommen, daß Du es für die "Non-Dummy"-Vorgehensweise hältst, handgeschmiedete Pakete via configure/make/make install ins System zu dengeln, anstatt die Variante für Weichlinge zu wählen und das einen Paketmanager machen zu lassen. Möglicherweise habe ich das mißverstanden.
So halb. Ich finde configure/make/make install jetzt nicht so schlimm wie offenbar Du und ich habe unter Linux auch schon viel Zeit mit apt verloren, das beim Installieren irgendwas zerschossen hatte, bis ich das Problem am Ende eben doch mit configure/make/make install löste. Das halte ich tatsächlich immer noch für die solideste Lösung, auch, weil ich mir configure nach Herzenslust anpassen kann. Aber ich weiß die Bequemlichkeit von apt, dort, wo sie existiert, schon auch zu schätzen.

Homebrew & Co sind für mich aber nichts Halbes und nichts Ganzes, weil sie nicht wirklich in macOS integriert sind. Sie trauen sich nicht, die Programme als root in die eigentlich dafür vorgesehenen Pfade zu installieren und lavieren stattdessen für meinen Geschmack zu viel herum; ich finde das halbgar und dagegen habe ich einfach einen tiefsitzenden Widerwillen.
Ansonsten könnte man natürlich auch argumentieren, daß es eher Zeichen des Dummytums ist, stundenlang Abhängigkeiten manuell aufzulösen und Code durch Compiler zu quetschen
Vielleicht machst Du da ja viel mehr als ich. Auf Stunden der Installation habe ich es noch nie gebracht und dem Compiler bei seinen Terminal-Ausgaben zuzugucken hat, finde ich, manchmal auch etwas Meditatives an sich, so, wie der Wachmaschine beim Waschen zuzugucken.

Etwa ein Drittel meiner zusätzlich installierten Unix-Programme habe ich eh selbst geschrieben oder zumindest modifiziert, da erübrigt sich die Frage sowieso.
Ich persönlich lasse übrigens nicht so gern fremde Makefiles unter root-Rechten laufen.
Das betrifft ja nur Make Install und da reicht doch meist ein kurzer Blick, dass alles OK ist. Den Rest mache ich selbstverständlich nicht unter root.
„🦖The dinosaurs invented Jesus to test our confidence in science“
0
Peter Eckel03.08.2114:47
Weia
und ich habe unter Linux auch schon viel Zeit mit apt verloren, das beim Installieren irgendwas zerschossen hatte, bis ich das Problem am Ende eben doch mit configure/make/make install löste.
Da ist die "Lösung" gern mal Teil des Problems. Handinstallation und Paketmanager-Installation geraten sich gern ins Gehege, besonders im Fall komplexer Abhängigkeiten. Bei Python-Modulen läßt sich sowas halbwegs elegant mit virtualenv umschiffen, bei Paketen in /usr/local, wenn der PATH bzw. LD_LIBRARY_PATH entsprechend gesetzt sind, explodiert einem das ganze gern mal ins Gesicht.
Weia
Homebrew & Co sind für mich aber nichts Halbes und nichts Ganzes, weil sie nicht wirklich in macOS integriert sind. Sie trauen sich nicht, die Programme als root in die eigentlich dafür vorgesehenen Pfade zu installieren und lavieren stattdessen für meinen Geschmack zu viel herum; ich finde das halbgar und dagegen habe ich einfach einen tiefsitzenden Widerwillen.
Das hat gar nichts mit "trauen" zu tun, sondern ist einfach ein anderer Ansatz. Ein einfaches Beispiel: Ich arbeite viel mit Ansible, für meine eigenen und für Kundenzwecke. Die meisten meiner Kunden setzen Red Hat- bzw. Red Hat-kompatible Systeme ein, und beim derzeit größten Teil heißt das: Ansible 2.9. Aktuell ist Core 2.11 und das Gesamtpaket hat eine andere Versionierung bekommen.

Als Resultat muß ich zwischen der aktuellen Version (überall da, wo es geht) und der Version, die ich für Kundenprojekte einsetze, hin- und herschalten. Keine Version ist im eigentlichen Sinne "die richtige", ich brauche beide. Und bei Tests kann das noch ganz andere Bandbreiten geben.

Das ganze Zeug parallel installiert zu haben und bei Bedarf umzuschalten ist da die eleganteste Lösung, und genau das ist der Ansatz, dem Homebrew folgt.
Weia
Vielleicht machst Du da ja viel mehr als ich. Auf Stunden der Installation habe ich es noch nie gebracht und dem Compiler bei seinen Terminal-Ausgaben zuzugucken hat, finde ich, manchmal auch etwas Meditatives an sich, so, wie der Wachmaschine beim Waschen zuzugucken.
Da schaue ich lieber einem guten Whisky zu, wie er an den Wänden eines Glases herunterläuft ... suum cuique

Es kann schon gut sein, daß ich da mehr mache als Du. Ich komme pro System auf ein paar hundert installierte Pakete, und da ist dann der meditative Reiz der Compilermeldungen auch bald erschöpft, zumal wenn man schnell etwas testen muß und dafür mal eben die neueste Version des Pakets x mit den Abhängigkeiten a...q und deren Abhängigkeiten a1...a6, b1...b3 ... ich nehme an, Du verstehst, was ich meine.
Weia
Etwa ein Drittel meiner zusätzlich installierten Unix-Programme habe ich eh selbst geschrieben oder zumindest modifiziert, da erübrigt sich die Frage sowieso.
Genau. Aber da geht es dann auch nicht anders.
Weia
Das betrifft ja nur Make Install und da reicht doch meist ein kurzer Blick, dass alles OK ist. Den Rest mache ich selbstverständlich nicht unter root.
Naja, bei ein paar hundert Paketen summieren sich die "kurzen Blicke" dann auch zu einem langen Blickwechsel.
„Ceterum censeo librum facierum esse delendum.“
0
Weia
Weia03.08.2115:04
Peter Eckel
Da ist die "Lösung" gern mal Teil des Problems.
Bei mir war’s glücklicherweise bislang immer die Lösung.
Das hat gar nichts mit "trauen" zu tun, sondern ist einfach ein anderer Ansatz.
[…]
Keine Version ist im eigentlichen Sinne "die richtige", ich brauche beide.
[…]
Das ganze Zeug parallel installiert zu haben und bei Bedarf umzuschalten ist da die eleganteste Lösung, und genau das ist der Ansatz, dem Homebrew folgt.
Ja, da habe ich Dir ja schon zugestimmt, dass das dafür eine gute Lösung ist.

Meine Situation ist eben eine ganz andere als Deine. Meine Auftraggeber bekommen die Ergebnisse meiner Arbeit präsentiert, aber nicht die IT, die ich zu ihrer Gewinnung verwendet habe; intern muss ich zu nichts und niemandem kompatibel sein.

Wie so oft hängt das beste Werkzeug und Vorgehen halt von der je spezifischen Situation ab. Und dann gibt es da ja auch noch die emotionalen Unterschiede:
Da schaue ich lieber einem guten Whisky zu, wie er an den Wänden eines Glases herunterläuft ...
Bei mir wäre das Cola, aber das finde ich weit weniger spannend als Waschmaschinen und Compiler.
Es kann schon gut sein, daß ich da mehr mache als Du.
Ganz sicher.

Frieden.
„🦖The dinosaurs invented Jesus to test our confidence in science“
0
Peter Eckel03.08.2117:45
Weia
Frieden.
Und Freude und Eierkuchen. Amen.
„Ceterum censeo librum facierum esse delendum.“
0

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.