apt-get remove Frage
- Thread starter gfxclub
- Start date
Das ist klar aber ohne Deinstallation von php4 auch keine php5 das ist mein Prob...
Weil wenn ich einfach ein upgrade mache (Quelle: home [Dotdeb] ) dann Upgradet er die PHP Version für die User auf 4.4.4 und ich denke die für Plesk auf 5.1.6. Aber ich möchte ja das er die für die User auf 5.1.6 Upgradet...
Weil wenn ich einfach ein upgrade mache (Quelle: home [Dotdeb] ) dann Upgradet er die PHP Version für die User auf 4.4.4 und ich denke die für Plesk auf 5.1.6. Aber ich möchte ja das er die für die User auf 5.1.6 Upgradet...
Last edited by a moderator:
S
server4downs
Guest
Um dir etwas Lesearbeit zu ersparen:
Kompilier PHP5 von Hand und "überschreib" das alte PHP4. Dann gibts keine Probleme und der Laden läuft. Alles andere bereitet Umstände.
Kompilier PHP5 von Hand und "überschreib" das alte PHP4. Dann gibts keine Probleme und der Laden läuft. Alles andere bereitet Umstände.
elias5000
Site Reliability Engineer
War das der Vorschlag zum Thema: Wie fahre ich meine Installation in einen inkonsistenten Zustand?
Software am Paketmanager vorbei zu installieren ist schon schlimm genug - aber jetzt auch noch ein installiertes Paket überschreiben...?
Und wenn das nächste Update für PHP4 kommt, dann geht der Spaß von vorne los? Bzw. was ist mit den Abhängigkeiten, wenn der Paketmanager davon ausgehen muss, dass PHP4 installiert ist aber in Wirklichkeit ist PHP5 drauf?
Gibt es denn bei dpkg keine Option, die soviel bedeutet wie: "Hau das Ding raus und scher dich nicht um die Deps?"
Bei RPM gibt es das und ich kann mir kaum vorstellen, dass dpkg das nicht hat.
Nach einem kurzen Blick in die ManPage: Wie schaut es denn mit der Option "depends" für dpkg? "Turn all dependency problems into warnings." Klingt mir danach, als könnte man damit das gesuchte erreichen. (Hab kein Debian zum Testen.)
Last edited by a moderator:
TheSandman
Registered User
Du suchst wahrscheinlich --force-depends . Jedoch ist das auch ein Weg zur inkonsistenten Paketverwaltung.
elias5000
Site Reliability Engineer
Soweit ich das verstanden habe, will er PHP4 raushauen, ohne Deps zu beachten und danach sofort PHP5 installieren. Das dürfte die Deps ja dann wieder begradigen.
Wenn es hinterher wieder stimmt, ist das *der* Weg es zu tun. Dagegen ist die Sache mit dem Überbraten ja schon fast ein "rm -rf /"...
MrMasterJPsy
Registered User
Naja, ich denke mal wenn server4dawns das so erklärt, wirds so auch funktionieren - wenn ich lese in seiner Sig das er das ja auch "professionell"
anbietet...
...vllt sagt er noch nen Satz zu seiner Vorgehensweise, und obs dabei mit den Deps keine Probs gibt (beim Update z.B.)
Cya JPsy
anbietet...
...vllt sagt er noch nen Satz zu seiner Vorgehensweise, und obs dabei mit den Deps keine Probs gibt (beim Update z.B.)
Cya JPsy
elias5000
Site Reliability Engineer
Funktionieren würde es wahrscheinlich. Aber es würde die Beziehungen zwischen des Dependencies deines Paketmanagements durcheinander bringen, da du in wirklichkeit was anderes installiert hast, das der Paketmanager annimmt.
Das führt früher oder später zu ganz massiven Probleme, die dich sogar zur Neuinstall zwingen können.
Die Benutzung des Pakenmanagements als zentrales System für die Aufrechterhaltung der Integrität der Paketbeziehungen ist *die* grundlegende Maßnahme zur vermeidung von Inkonsistenzen.
Leider ist nicht überall, wo professional drauf steht auch professional drin. Seine Empfehlung ist definitiv nicht professionell sondern das, was man landläufig als "Frickelei" bezeichnet.
Auch speziell angepasste Versionen sollte man immer über die Paketverwaltung der Distribution installieren.
S
server4downs
Guest
elias5000, dein Sarkasmus in Ehren... jedoch denke ich sollte man lieber versuchen dem Fragestellenden zu helfen, statt über andere Mithelfer (peinlichst) herzuziehen.
Ich will jetzt nicht jedes deiner Postings hier mit Quotes auseinander nehmen und widerlegen, dazu habe ich gerade keine Zeit und außerdem ist das hier ein wenig unpassend (über die Beleidigungen sehe ich jetzt mal hinweg und bleibe etwas sachlicher).
Stattdessen will ich lieber erklären, wieso es doch Sinn machen kann so vorzugehen.
Selbstverständlich ist es möglich, dass man die Abhängigkeiten umgeht, indem man ein "force" an die Anweisung klatscht. Das heißt dann aber noch lange nicht, dass die Abhängigkeit (z.B. zu Plesk) sich hiermit ergeben hat.
Nehmen wir einmal Yast*: umgehen wir die Abhängigkeit, indem wir einfach auf "Ignore All" gehen, wird uns Yast bei JEDEM Aufruf wieder mit dem gleichen nervenden Fenster begrüßen und uns nach PHP4 fragen.
Auch "apt" vergisst die Abhängigkeit nicht.
Wieso soll man den "dummen" Paketmanager also nicht einfach im Glauben lassen wir haben noch PHP4 drauf und man hat Ruhe?
Halt! Weiterlesen
Jetzt kommt das Gegenargument:
"Ja wenn ich dann aber z.B. ein apt-get upgrade macht, dann haut mir der Paketmanager einfach wieder eine ggf. neuere PHP4-Version auf den Server." Ja, richtig!
Aber: meiner Meinung nach ist ein nicht wirklich überdachtes "apt-get upgrade" meist eh mit vielen Fehlern verbunden und sollte daher nicht blind ausgeführt werden. Wenn man irgendwo up2date bleiben will, dann sollte man schon wissen, um welche Software es sich handelt.
Und außerdem wird beim "Drüberkopieren" (kompilieren) bei geschickter ./configure-Anweisung bei der Apache-Version ja nur eine einzige Datei überschrieben (das LoadModule-File *.so).
Um es nochmals zusammenzufassen:
solange man nicht automatische Updates blind einspielt, kann man das Überschreibung ohne vorherige Deinstallation der alten Software getroßt machen.
Der Vergleich mit dem oben angesprochenen "rm -rf /" hinkt vorne und hinten (auch wenn es nicht ernst gemeint war).
Im übrigen will ich noch auf die Forenregeln Punkt 10 hinweisen.
*um dummen Kommentaren vorzubeugen: ich setze auf meinen Servern nicht auf SuSe
P.S.:
Meinst du eigens erstellte RPMS (bzw. Debianpakete)?
Würde mich mal interessieren.
Ich will jetzt nicht jedes deiner Postings hier mit Quotes auseinander nehmen und widerlegen, dazu habe ich gerade keine Zeit und außerdem ist das hier ein wenig unpassend (über die Beleidigungen sehe ich jetzt mal hinweg und bleibe etwas sachlicher).
Stattdessen will ich lieber erklären, wieso es doch Sinn machen kann so vorzugehen.
Selbstverständlich ist es möglich, dass man die Abhängigkeiten umgeht, indem man ein "force" an die Anweisung klatscht. Das heißt dann aber noch lange nicht, dass die Abhängigkeit (z.B. zu Plesk) sich hiermit ergeben hat.
Nehmen wir einmal Yast*: umgehen wir die Abhängigkeit, indem wir einfach auf "Ignore All" gehen, wird uns Yast bei JEDEM Aufruf wieder mit dem gleichen nervenden Fenster begrüßen und uns nach PHP4 fragen.
Auch "apt" vergisst die Abhängigkeit nicht.
Wieso soll man den "dummen" Paketmanager also nicht einfach im Glauben lassen wir haben noch PHP4 drauf und man hat Ruhe?
Halt! Weiterlesen
Jetzt kommt das Gegenargument:
"Ja wenn ich dann aber z.B. ein apt-get upgrade macht, dann haut mir der Paketmanager einfach wieder eine ggf. neuere PHP4-Version auf den Server." Ja, richtig!
Aber: meiner Meinung nach ist ein nicht wirklich überdachtes "apt-get upgrade" meist eh mit vielen Fehlern verbunden und sollte daher nicht blind ausgeführt werden. Wenn man irgendwo up2date bleiben will, dann sollte man schon wissen, um welche Software es sich handelt.
Und außerdem wird beim "Drüberkopieren" (kompilieren) bei geschickter ./configure-Anweisung bei der Apache-Version ja nur eine einzige Datei überschrieben (das LoadModule-File *.so).
Um es nochmals zusammenzufassen:
solange man nicht automatische Updates blind einspielt, kann man das Überschreibung ohne vorherige Deinstallation der alten Software getroßt machen.
Der Vergleich mit dem oben angesprochenen "rm -rf /" hinkt vorne und hinten (auch wenn es nicht ernst gemeint war).
Im übrigen will ich noch auf die Forenregeln Punkt 10 hinweisen.
*um dummen Kommentaren vorzubeugen: ich setze auf meinen Servern nicht auf SuSe
P.S.:
Kannst du hier bitte dich ein wenig erklären? Wie meinst du das?
Meinst du eigens erstellte RPMS (bzw. Debianpakete)?
Würde mich mal interessieren.
Last edited by a moderator:
elias5000
Site Reliability Engineer
Jupp. Ich meine eigens angepasste Pakete.
Für .deb kann ich das nicht erklären. Das müsste ein Debian-User übernehmen. Aber für RPM funktioniert das in etwa so: ...
Weil es so viel geworden ist, habe ich dazu mal einen eigenen Thread auf gemacht:
[HowTo] Angepaste RPM-Pakete erstellen
Weil in einem anderen Thread die Frage dazu aufkam, poste ich an dieser Stelle mal ein kleines Kurz-HowTo zum Thema Erstellen eigener RPM-Pakete: 1. Build-Umgebung für nicht-privilegierten User vorbereiten: - Installation von cpan2rpm (brauchen wir eigentlich nicht, übernimmt aber super das...
serversupportforum.de
Diese Pakete existieren dann konsistent in System und Paket-Datenbank, so dass man den Mechanismus des Paketmanagement nicht aushebelt. IMHO die einzig wirklich richtige[tm] Weise, Software in das System zu installieren.
S
server4downs
Guest
Hallo.
Aber damit ist die Frage ja noch immer nicht gelöst.
Es ist ja egal ob es nun ein "öffentliches" Paket oder ein selbst erstelltes Paket ist. Es bleibt das Problem mit der zu lösenden Abhängigkeit.
Und da kommt dann der Salat mit Plesk bzw. teilweise auch mit Confixx.
Wie gesagt: ich bin kein Freund von "apt-get upgrade" und somit gefällt mir meine Lösung besser (bezogen auf diesen Thread). Ich bestehe aber nicht darauf sie als einzig richtige zu bezeichnen, da hierzu keiner von uns beiden Berechtigung hat.
Ich will hier keinen Streit und so langsam geht es ja wieder in Richtung sachliche Diskussion. Das betrachte ich als positiv, elias5000!
Aber damit ist die Frage ja noch immer nicht gelöst.
Es ist ja egal ob es nun ein "öffentliches" Paket oder ein selbst erstelltes Paket ist. Es bleibt das Problem mit der zu lösenden Abhängigkeit.
Darüber lässt sich streiten. Es müsste hierbei erstmal geklärt werden, was "in das System zu installieren" heißt. Bei Windows könnte ich es durchaus nachvollziehen, dass man keine manuellen Installationen macht (zumal das viel zu kompliziert wäre (Registery etc)). Bei apt handelt es sich IMHO um ein nettes "Tool" um mal flott ein paar devel-Pakete einzuspielen etc. Ansonsten sehe ich das nicht als DIE Lösung Software zu verwalten. APT schaut lediglich in einem File (was nur bedingt als Datenbank bezeichnet werden kann) nach, ob die gewisse Software schon installiert wurde und welche Abhängigkeiten bestehen.
Und da kommt dann der Salat mit Plesk bzw. teilweise auch mit Confixx.
Wie gesagt: ich bin kein Freund von "apt-get upgrade" und somit gefällt mir meine Lösung besser (bezogen auf diesen Thread). Ich bestehe aber nicht darauf sie als einzig richtige zu bezeichnen, da hierzu keiner von uns beiden Berechtigung hat.
Ich will hier keinen Streit und so langsam geht es ja wieder in Richtung sachliche Diskussion. Das betrachte ich als positiv, elias5000!
elias5000
Site Reliability Engineer
Bitte auch die unsichtbaren zwischen den Zeilen beachten...
Wieso ich das sage ist folgendes: Die Paketverwaltung funktioniert, wenn man sie konsequent einsetzt.
Wenn ein $admin_tool php4 benötigt, ich aber php5 haben will, dann muss ich das $admin_tool-Paket eben so neu erstellen, dass es als Abhängigkeit php5 hat.
(Wobei ich selbst kein $admin_tool verwende.)
Ist natürlich mit etwas Aufwand verbunden. Minimiert aber super das Risiko auf den Produktivsystemen. Weil das Paket, das auf einer Testmaschine läuft, sich auf dem richtigen Server genauso verhält.
Das hilt, Ausfallzeiten zu minimieren. Wenn es um hohe Verfügbarkeit geht IMHO the way to go.
liebe Grüße,
elias5000
zwischen den Zeilen beachten... Wieso ich das sage ist folgendes: Die Paketverwaltung funktioniert, wenn man sie konsequent einsetzt.
Wenn ein $admin_tool php4 benötigt, ich aber php5 haben will, dann muss ich das $admin_tool-Paket eben so neu erstellen, dass es als Abhängigkeit php5 hat.
(Wobei ich selbst kein $admin_tool verwende.)
Ist natürlich mit etwas Aufwand verbunden. Minimiert aber super das Risiko auf den Produktivsystemen. Weil das Paket, das auf einer Testmaschine läuft, sich auf dem richtigen Server genauso verhält.
Das hilt, Ausfallzeiten zu minimieren. Wenn es um hohe Verfügbarkeit geht IMHO the way to go.
liebe Grüße,
elias5000
S
server4downs
Guest
Das ist durchaus ein Lösungsweg.
Fraglich jedoch ist, ob es nicht gerade unsicherer wird, da es sicherlich nicht unbedingt so leicht sein wird Plesk, bzw. Confixx (Premium) RPMs auseinanderzunehmen. Hierzu müsste man doch IMHO die Geschichte (Plesk z.B.) erst deinstallieren und dann das RPM anpassen und dann die Geschichte wieder einspielen*.
Ich will nicht wissen, wieviel Risiko eine solche Aktion bürgen würde (gerade auf einem LiveSystem). Und testen lässt sich das ganze lokal gerade mit SwSoft-Produkten ohne entsprechende Lizenzen auch nicht so einfach.
* oder lässt sich ganz easy einfach so am RPM drehen ohne groß hin und her installieren zu müssen? Da bin ich mir gerade nicht sicher.
Fraglich jedoch ist, ob es nicht gerade unsicherer wird, da es sicherlich nicht unbedingt so leicht sein wird Plesk, bzw. Confixx (Premium) RPMs auseinanderzunehmen. Hierzu müsste man doch IMHO die Geschichte (Plesk z.B.) erst deinstallieren und dann das RPM anpassen und dann die Geschichte wieder einspielen*.
Ich will nicht wissen, wieviel Risiko eine solche Aktion bürgen würde (gerade auf einem LiveSystem). Und testen lässt sich das ganze lokal gerade mit SwSoft-Produkten ohne entsprechende Lizenzen auch nicht so einfach.
* oder lässt sich ganz easy einfach so am RPM drehen ohne groß hin und her installieren zu müssen? Da bin ich mir gerade nicht sicher.