Normalerweise bin ich eher zurückhaltend und verwende nicht Wörter wie „Desaster“.
Aber hier blieb mir nach meiner Meinung keine andere Wahl.
Für einen Kunden sollte ich einen privaten lokalen Kalender einrichten, der eben nicht über die Cloud läuft und der über das „iPhone“ zu verwalten ist.
Nach einer sehr langen Installationsphase lief es schließlich zufriedenstellend. Es gab immer wieder Probleme wegen des xfs-Dateisystems, z.B. bei Upgrades des Debian-Systems, aber es lief.
Dann, schon vor einiger Zeit, wurde „calendarserver“ datenbankbasiert und nicht mehr dateisystembasiert umprogrammiert.
Das Paket ist, wenn das stimmt, was ich in Erfahrung bringen konnte, von Apple.
Fakt ist, daß diese Routine, die alten Daten hochzuhieven auf die Datenbank, nie funktioniert hat. Und ich habe sie auch nicht zum Laufen bekommen. Ich bin in einem riesigen komplexen Abhängigkeitskonstrukt von Python-Paketen gelandet, verschiedenen Python-„deprecated“-Problematiken (2.7) und habe es nicht zum Laufen bekommen und zum Kunden gesagt: Ich weiß nicht, ob der Code überhaupt funktioniert, es wird einfach zu teuer.
Jetzt sollte ich einen neuen Anlauf wagen und stelle fest: Das Paket „calendarserver“ gibt es nicht mehr.
Es ist eine Bestätigung für den Kurs, den ich seit langem fahre: Als Programmierer sollte man davon ausgehen, daß die eigenen Programme viel länger laufen, als man denkt. Größere Umarbeiten sollten dann nicht notwendig sein. Wenn dann die zugrundeliegende Programmiersprache wie „Python“ auf einmal in entscheidenden Bereichen „deprecated“ ist oder ganze Bibliotheken abgekündigt werden oder es Funktionen nicht mehr gibt (wie in „php“), sollte man sich vorher gut überlegen – mit dem Kunden gemeinsam – in welcher Programmiersprache man ein Projekt angeht und auf welche externe Bibliotheken man sich verläßt.
Das „objektorientierte“ Perl habe ich vor dem Hintergrund auch nicht verstanden. Es gibt Perl-Programme von mir, die laufen jetzt seit über 20 Jahren.