Warum "Versionsnummer" im Paketnamen?

[MoonKid]

Warum sind bei einigen Paketen die "Versionsnummern" im Paketnamen drin?
Beispiel libssl: Da gibt es z.B. libssl1.0.0 und libssl1.1.
Beide lassen sich nicht gleichzeitig installieren.

Das viel mir schon bei mehreren Paketen auf. Aber sicher haben sich die Debianer etwas dabei gedacht. Würde nur gerne mal dahinter kommen.

Konkrete Fall ist Skype. Das deb-file verlang libssl1.0 (ohne Angabe einer echten Versionsnummer).
In meinem Debian unstable ist derzeit aber libssl1.1 installiert.
Selbst wenn Skype jetzt sagen würde libssl (>= 1.0) sagen würde, ginge das nicht, weil libssl ja gar nicht existiert.

Versteht man, was ich meine?

[DeletedUserReAsG]

Wenn dein Programm gegen libssl 1.0 gebaut wurde, wird es mit 1.1 nicht funktionieren. Wenn, dann müsste es gegen 1.1 gelinkt werden – und wird dann mit 1.0 nicht mehr funktionieren. Nicht immer sind verschiedene Versionen von Libs untereinander kompatibel.

[MoonKid]

Das ist mir schon klar.

Aber warum heißt das Paket nicht "libssl" und hat seine Versionsnummer eben als echte Versionsnummer. Verstehst du was ich meine?

Wenn es Inkompatibilitäten zwischen Version 1.0 und 1.1 gibt, kann ja die jeweilige Anwendung in seinen Abhängigkeiten darauf eingehen. Beispielsweise könnte Skype dann sagen libssl (= 1.0).

Andererseits versteh ich nicht, warum mir nicht erlaubt wird libssl1.0 und libssl1.1 gleichzeitig zu installieren.

[DeletedUserReAsG]

Wenn es libssl1.0 >=1.0.0 haben will, sind alle 1.0.x abgedeckt; wenn libssl =1.0 angegeben würde, müsste das Paket bei jedem Patch der Lib auch neu gebaut werden.

Andererseits versteh ich nicht, warum mir nicht erlaubt wird libssl1.0 und libssl1.1 gleichzeitig zu installieren.

Ein Abgleich der Dateilisten mag Erleuchtung bringen (habe selbst nicht reingeschaut).

[MoonKid]

Wenn es libssl1.0 >=1.0.0 haben will, sind alle 1.0.x abgedeckt

Logisch! Aber libssl1.0 kann ich nicht installieren, weil es mit libssl1.1 konfliktet. 1.1 müsste ich also vorher deinstallieren.

EDIT: Habs grad nochmal geprüft. Hab mich geirrt. Skype sagt libssl1.0.0 - was unter unstable gar nicht mehr existent ist.

Bleibt weiterhin die Grundsatzfrage, warum man eine Versionsnummer in den Paketnamen packt und nicht in das dafür vorgesehene "Feld" des Paketes.

[DeletedUserReAsG]

Wie (später noch) im Beitrag geschrieben: einfach mal gucken, was für Dateien da drin sind. Wenn welche mit gleichem Namen, ist’s nachvollziehbar, dass nicht beide gleichzeitig da sein können.

[KBDCALLS]

Das geht schon . Nur das eine ist von Jessie und das neuere von Testing/Unstable. Das war mal einer der seltenen Fälle wo es funktioniert , verschiedene Debianversionen zu mischen. Verlassen sollte man sich darauf nicht das das gut geht. Meistens geht bei den Devel Paketen schief , da muß man sich dann entscheiden welches man nutzt. Es gibt durchaus andere Fälle wo es von der gleichen Lib unterschiediche Versionen innerhalb einer Disti gibt.

39673

[DeletedUserReAsG]

Bleibt weiterhin die Grundsatzfrage, warum man eine Versionsnummer in den Paketnamen packt und nicht in das dafür vorgesehene "Feld" des Paketes.

Genau das hatte ich versucht, zu erklären. Andersrum: dein Programm kann nur mit 1.0.x – wie möchtest du die Abhängigkeit für 1.0.x, aber nicht 1.1.x vorgeben, wenn du die Version nicht in den Paketnamen schreibst? >=1.0.0 schließt 1.1.x mit ein → funktioniert nicht. =1.0.0 schließt 1.0.1…1.0.99 aus → funktioniert auch nicht. <1.1.0 schließt 0.9.6 ein → funktioniert ebenfalls nicht. Intervalle können, soweit ich weiß, nicht angegeben werden.

[MrScoville]

Genau das hatte ich versucht, zu erklären.

Genau das hast du auch erklärt. Wenn es anders wäre, würde uns die hässliche, alte "DLL Hell" wie bei Windows blühen.

Letztlich sollten sich Bibliotheken-Entwickler eingehend Gedanken darüber machen, wann "breaking changes" wirklich nötig sind und inwieweit sich Inkompatibilitäten mit Fassaden und Co. vermeiden lassen. Ist halt eine Frage der Abwägung von Rückwärts-Kompatibilität und Abwerfen von altem Ballast. Andersherum geht es ja auch: Die Entwickler einer Anwendung könnten auch eine entsprechende Bibliothek mitliefern, die die alte Funktionalität mit der neuen Standard-Bibliothek gewährleistet.

[Tintom]

Genau das hatte ich versucht, zu erklären.

Die Entwickler einer Anwendung könnten auch eine entsprechende Bibliothek mitliefern, die die alte Funktionalität mit der neuen Standard-Bibliothek gewährleistet.

Genau dann hast du deine "DLL-Hell". Bitte nicht!

[DeletedUserReAsG]

Der Entwickler kann auch statisch linken. Ist dann zwar ungheurer Bloat, wenn man mit vielen Libs arbeitet, aber die meisten stört das heute ja nicht mal mehr.

[MrScoville]

Genau das hatte ich versucht, zu erklären.

Die Entwickler einer Anwendung könnten auch eine entsprechende Bibliothek mitliefern, die die alte Funktionalität mit der neuen Standard-Bibliothek gewährleistet.

Genau dann hast du deine "DLL-Hell". Bitte nicht!

Ich glaube, da hast du mich falsch verstanden. Wenn eine Anwendung zunächst gegen eine Lib 1.2 gebaut wurde, die Entwickler von Lib 1.2 nun aber nach reiflicher Überlegung festlegen, dass Lib 1.3 kommen muss, dann soll die Anwendung natürlich keine eigene Lib 1.2 mitbringen, sondern eine eigene Fassaden-Lib, die die Lib 1.3 nutzt, intern zur Anwendung hin aber erscheint wie die alte Lib 1.2 -- soweit das halt möglich ist. Dann linkt die Anwendung eben nicht mehr gegen die Lib 1.2, sondern gegen die eigene Fassaden-Lib, die dann NUR für die Anwendung benutzt wird, und diese wiederum linkt gegen die Lib 1.3. In der eigenen Lib benutzt man Switches, Hatches (Migrations-Patterns), Adapter, Fassaden (Standard-(sogar GoF)-Patterns) und was sonst noch passt und baut dann nach und nach die Fassaden-Lib ab, indem man die eigene Anwendung zuerst so umbaut, dass die Hatches nicht mehr nötig sind, und sich dann um die Switches kümmert.

Solche Migrations-Strategien sind ja kein Hexenwerk, sondern gehören zum Standard-Repertoire der Software-Architektur.