Kopano lässt sich nicht auf Debian 8 installieren - Differenz im Paketnamen

[altmetaller]

Hallo,

Kopano besteht aus einer "losen Sammlung" von diversen .deb Paketen. Zwecks Installation wird folgende Vorgehensweise vorgeschlagen:

• dpkg -i *.deb
• apt-get -f install

Die Schleife wiederholt man, bis "das Ding" vollständig, d.h. inklusive aller Abhängigkeiten, "auf der Platte" ist.

"Irgendwann" stolpert man darüber, dass sich die Abhängigkeiten von kopano-search nicht auflösen lassen. Das Paket besteht auf python-xapian, auf meinem Debian heißt das Paket aber python3-xapian

Ein beherztes "dpkg -i --force-depend kopano-search_[...].deb" ging insofern in die Hose, dass sich der Dienst danach nicht starten ließ.

Wie geht man mit derartigen Problemen um? Geht das "stumpf" an den Entwickler? Oder kann man da irgendwo eine Art Alias definieren?

Vielleicht kann mir ja auch jemand etwas über die Hintergründe bei der Namensdifferenz bei diesem einen speziellen Paket schreiben?

Gruß,
Jörg

[hikaru]

Das Problem solltest du an den Entwickler melden, denn sonst bessert sich die Situation nicht. "Stumpf" würde ich das allerdings nicht nennen.

In der Zwischenzeit kannst du dir damit behelfen, entweder die Abhängigkeit in den Paketen manuell anzupassen (auspacken, debian/control editieren, wieder einpacken, installieren), oder selbst ein Paket zu erstellen, das python-xapian bereitstellt und dabei idealerweise von python3-xapian abhängt. Das soll wohl komfortabel mit equivs gehen, Erfahrung habe ich mit dem Werkzeug aber nicht.

Der Hintergrund für die Namensänderung dürfte historisch sein. Eine Zeit lang existierten Python 2.7 und 3.0 in Debian parallel. Da musste man halt unterscheiden. Das ging am einfachsten, indem man den Python-3-Paketen einfach die Versionsnummer in den Namen steckte. Hinterher hat man sich wiederum die Mühe gespart, die Versionsnummern wieder wegzuputzen.

[smutbert]

Wenn es nur darum geht, dass die Abhängigkeiten formal nicht erfüllt sind, obwohl sie es in Wirklich sehr wohl sind, dann böte es sich an mit equivs ein Dummy-Paket zu bauen, das die Abhängigkeit formal erfüllt (und mit den eigenen Abhängigkeiten optimalerweise auch dafür sorgt, dass das richtige Paket installiert ist und bleibt).


Allerdings klingt es nach deiner Beschreibung etwas komplizierter, denn an Formalitäten sollte das Starten eines Dienstes nach der Installation mit Ignorieren der Abhängigkeiten nicht scheitern und es passt auch nicht alles zu dem was du gesagt hast:
So existiert das Paket python-xapian sehr wohl und zwar mindestens von wheezy bis inklusive sid und die Version für python3 gibt es ab stretch.
Dafür existiert kopano (kopanocore) erst in buster/testing in debian.

Welche Debianversion hast du denn installiert und woher nimmst du kopano, dass du es per dpkg und nicht per apt installierst?

[inne]

"Irgendwann" stolpert man darüber, dass sich die Abhängigkeiten von kopano-search nicht auflösen lassen. Das Paket besteht auf python-xapian, auf meinem Debian heißt das Paket aber python3-xapian

Debian hat python-xapian und auch python3-xapian in allen Distributionen paketiert. Besteht vielleicht ein Versionskonflikt d.h. kopano-search benötigt eine andere Version?

[hikaru]

Dafür existiert kopano (kopanocore) erst in buster/testing in debian.

Hatte ich völlig übersehen. Danke für den Hinweis!

Umso fragwürdiger wird diese Aussage:

Kopano besteht aus einer "losen Sammlung" von diversen .deb Paketen. Zwecks Installation wird folgende Vorgehensweise vorgeschlagen:

• dpkg -i *.deb
• apt-get -f install

Die Schleife wiederholt man, bis "das Ding" vollständig, d.h. inklusive aller Abhängigkeiten, "auf der Platte" ist.

Da stellen sich dann zwei Fragen:
1. Von wem stammt dieser "Vorschlag"?
2. Ist der schon geteert und gefedert oder muss das noch erledigt werden?

[altmetaller]

Hallo,

"Stumpf" würde ich das allerdings nicht nennen.

Das Problem ist, dass die nur englisch können und ich mich da mit der Übersetzung schwer tue.

In der Zwischenzeit kannst du dir damit behelfen, entweder die Abhängigkeit in den Paketen manuell anzupassen (auspacken, debian/control editieren, wieder einpacken, installieren),

Hätte in dem Fall dann nicht auch der dpkg-Befehl mit der Force-Option zum Erfolg führen müssen?

Der Hintergrund für die Namensänderung dürfte historisch sein. Eine Zeit lang existierten Python 2.7 und 3.0 in Debian parallel.

Danke für die Einschätzung - so etwas in der Richtung habe ich mir schon gedacht.

Da ich bei weiteren Kopano-Paketen diverse Syntaxfehler von irgendwelchen Perlscripten bekomme, habe ich mich entschieden, den (Test-)Server erst einmal auf Debian 9 zu hiefen. Vielleicht hebe ich den dann noch auf buster/testing hoch.

Letztendlich handelt es sich hierbei um eine Teststellung, bei der wir bewerten wollen, ob wir das Ding verkaufen können. Da wir im Zweifelsfall aber immer noch Exchange im Portfolio haben und ich gerade "eher etwas herumdaddel", ist das jetzt nicht ganz so kritisch.

Debian hat python-xapian und auch python3-xapian in allen Distributionen paketiert.

Bei mir definitiv nicht -python3-xapian findet ich weder mit apt, noch mit aptitude.

Gruß,
Jörg

Edit:

Von wem stammt dieser "Vorschlag"?

https://blog.cadena-it.com/linux-tips-h ... -debian-8/

An die offiziellen Repositories kommt man nur mit Wartungsvertrag - ich vermute mal, dass Sie den potentiellen Kunden damit die Nutzung der Community-Edition verleiden wollen.

[inne]

Debian hat python-xapian und auch python3-xapian in allen Distributionen paketiert.

Bei mir definitiv nicht -python3-xapian findet ich weder mit apt, noch mit aptitude.

Welches Debian nutzt Du und was benötigst Du, ich denke python-xapian wird benötigt und das ist laut Website in allen Distributionen enthalten.

Das Paket besteht auf python-xapian, auf meinem Debian heißt das Paket aber python3-xapian

[KP97]

Hier zu finden:
https://packages.debian.org/search?keyw ... hon-xapian

[altmetaller]

Hallo,

erwischt - kannste mal sehen, wie wuschig mich das schon macht. Ernsthaft - ich habe mich hier im Forum vertippt - mea maxima culpa.

Zusammengefasst: python-xapian gab es bei mir, python3-xapian gab es nicht und das Kopano-Paket wollte definitiv python3-xapian haben.

Wie gesagt - ich aktualisiere die Mühle jetzt eh' komplett durch, insofern kann ich nur von der Vergangenheit reden: Es war ein Debian 8 (amd64) ohne jegliche Spielereien wie Fremdrepositories, apt-pinning, zurückgehaltenen Paketen usf. usf.

Gruß,
Jörg

[hikaru]

Ich habe mir in der Zwischenzeit mal die Kopano-Pakete in Buster angeschaut und meine, dass ein Backport auf Stretch machbar sein sollte.

[altmetaller]

Hallo,

Ich habe mir in der Zwischenzeit mal die Kopano-Pakete in Buster angeschaut und meine, dass ein Backport auf Stretch machbar sein sollte.

ich würde sogar noch weiter gehen und die These aufstellen, dass das Teil unter Strech mindestens genau so gut tut. Für das Ding gibt es ja wie gesagt sogar offizielle Pakete (https://download.kopano.io/community/).

Im Grunde genommen ist der ganze Unterbau im Moment noch "Latte". Bis ich das Ding am Laufen habe, eine präsentierfähige Lösung parat und das Teil verkauft hat, gehen eh' noch ein paar Jahre ins Land Letztendlich will ich das mal irgendwann bei den Kunden platzieren, bei denen z.B. der Exchange 2010 auf einem SBS2011 das Supportende erreicht. Und das IMO im Jänne 2022.

Gruß,
Jörg

[eggy]

Das Problem ist, dass die nur englisch können und ich mich da mit der Übersetzung schwer tue.

Auch nen Bugreport in der "falschen" Sprache ist besser als keiner.
Schreib ihn erstmal auf Deutsch, fang mit der englischen Fassung an soweit Du kommst und dann setz ihn in das Forum Deines Vertrauens und bitte um Feinschliff. Falls wider Erwarten keiner beim Übersetzen hilft, sende ihn einfach zweisprachig ab. Ausführlich in deutsch und ein kurzer Text eingeleitet mit etwas wie "apologies for horrible grammar, bugreport follows in German, non-native English best-guess-summary below" hilft schon weiter, dann ist klar. Die Fehlermeldungen sind eh alle auf englisch (falls Dein System ne andere locale eingestellt hat: einfach prefixen "LC_ALL=C dpkg ... " ) und reichen oft schon aus um nachzuvollziehen was nicht klappt.

[tijuca]

Felix Bartels aus der QS Abteilung von Kopano ist deutscher Staatsbürger und man kann notfalls ihn auch direkt kontaktieren.

Wer die Upstream Pakete von Kopano installiert sollte tunlichst keine Paket mit dem Debian Repo mixen. Kopano hat aus Sicht von Debian etwas zu viele verschiedene Binärpakte erstellt die sich nicht ohne großem Aufwand auf die Debianversionen aktualisiert lassen. Es gibt momentan keine aktuellen Fehlerberichte zum kopanocore Paket, was jedoch nicht heißt das alles fehlerfrei ist. Der Autopkgtest schlägt seit einigen Versionen fehl und das ist ein eher schlechtes Zeichen, "müsste sich mal jemand anschauen ..." Hilfe wird gerne angenommen.

[altmetaller]

Hallo,

ich habe inzwischen auf Debian 9 geschwenkt und konnte alle Pakete über die empfohlene Methode installieren:

1. dpkg -i *.pkg
2. apt-get install -f
3. ...weiter mit Schritt 1

Dass ich das, vorsichtig ausgedrückt - etwas "grenzwertig" finde, brauche ich wohl nicht explizit erwähnen.

Ich kann jetzt nur noch von den TGZ-Dateien für Debian 9 reden, da wird das python3-mapi Paket von Kopano geliefert:

Code: Alles auswählen

python3-mapi_8.6.81.24-0+4.1_amd64.deb
mapi_8.6.81.24-0+4.1_amd64.deb

Bin mal gespannt, wie sich das mit Buster entwickelt. Wobei man natürlich fairerweise sagen muss, dass ich mir auch bei anderen Paketen eine "etwas abgestimmtere" Paketierung wünschen würde (z.B. debmon & owncloud).

Wer die Upstream Pakete von Kopano installiert sollte tunlichst keine Paket mit dem Debian Repo mixen.

Wie stelle ich das denn sicher? In den offiziellen Repositories habe ich ja auch ein python-mapi; und auf die Debian-Repositories möchte ich eigentlich nicht verzichten?!?

Aktuell verlasse ich mich darauf, dass die Pakete parallel zueinander existieren können.

Gruß,
Jörg

[DeletedUserReAsG]

Dass ich das, vorsichtig ausgedrückt - etwas "grenzwertig" finde, brauche ich wohl nicht explizit erwähnen.

Du könntest auch gdebi nutzen, auch apt soll Abhängigkeiten eigenständig auflösen können.

[tijuca]

Wer die Upstream Pakete von Kopano installiert sollte tunlichst keine Paket mit dem Debian Repo mixen.

Wie stelle ich das denn sicher? In den offiziellen Repositories habe ich ja auch ein python-mapi; und auf die Debian-Repositories möchte ich eigentlich nicht verzichten?!?

Nun ja, wie schon festgestellt gibt es eben leichte Unterschiede zwischen der Art wie Kopano die Binärprogramme in die Pakete verteilt und wie es eben in der Debian Paketierung erfolgt. Z.B. sind diverse Tools bei Debian im Paket kopano-utils, bei Kopano werden diese über verschiedene Binärpakete verteilt, das sagt Dir dann dpkg wenn es gleiche Binärnamen in verschiedenen Paketen findet.

Das ist leider ein allgemeines Problem, dass bei einigen Upstream Paketierungen auftritt, da Debian Paketierung dann doch etwas komplexer ist wenn man es "richtig" machen will.

Das ganze kannst Du nur lösen indem Du entweder nur Debian Pakete einsetzt und dann eventuell damit leben musst, dass eventuell auch mal was fehlt, oder Du setzt komplett auf Upstream Pakete. Für kopanocore fehlt es aktuell etwas an Zeit und Manpower um mit den Änderungen von Upstream mitzuhalten. Wir stehen zwar in Kontakt mit Upstream und das Verhältnis zu Upstream ist auch ausgezeichnet, Kopano ist dann aber doch deutlich mehr wie kopanocore und kopano-webapp. Es fehlen noch ein paar weitere Pakete und Tools aus dem Kopano Webbapp Bereich. Aber bisher hat auch noch niemand irgendwelche Wünsche geäussert.

Da Webentwickler gerne Ant benutzen um auch einfache PHP Installationen zu erschlagen gibt es hier immer einen ziemlichen Java Overhead bis hinten ein Paket herausfällt. Kann man alles auch mit Make machen, muss nur jemand einbauen.

Wenn jemand hier einsteigen will um fehlende Pakete zu bauen oder auch um nur einfach etwas beizutragen dann gerne auf der ML melden.
https://alioth-lists.debian.net/cgi-bin ... fe-discuss