Diese Frage wurde mir in letzter Zeit häufiger gestellt, weshalb ich sie hier (zusammen mit der nach dem fortkommen des Listaller als XDG-Projekt) mal beantworten möchte.
Wie einige vielleicht wissen, lief einige Zeit der Versuch, den Listaller und dessen Setup-Format IPK als Freedesktop-Projekt zu erstellen. Die Anfrage wurde vom XDG-Team abgelehnt, mit der Begründung, dass es viele Anstrengungen in diese Richtung gibt und der Listaller als XDG-Projekt im Grunde das Ausrufen eines neuen Standards wäre. Man wolle daher lieber zunächst abwarten, bis eine oder zwei größere Linux-Distributionen das Projekt unterstützen. Davon abgesehen wurde ich gefragt, warum ich nicht die LSB und das RPM-Format unterstütze, und lieber noch ein neues Format entwickelt habe.
Eigentlich eine berechtigte Frage. Die LSB (=LinuxStandardsBase) der Linux-Foundation gibt in unregelmäßigen Abständen eine Liste von Komponenten heraus, die auf einem LSB-zertifizierten Linux-System enthalten sein müssen. Dazu gehören wichtige Dinge wie z.B. ein teilweise erweiterter POSIX- und SUS-Standard oder die Festlegung der Dateisystemstruktur. In der LSB sind aber auch Versionen von GUI-Widgetsets wie Qt und GTK+ und anderer Libs festgelegt, welche jedes LSB-Linux-System haben muss. Dummerweise ist die LSB selbst in der aktuellen Version 4.0 stark veraltet, da sie auf Unternehmensdistributionen abziehlt, die generell ältere Bibliotheken verwendet, die länger getestet sind. Ich würde aber auch gerne besonders die neuen Technologien unterstützen. Daher möchte ich mich nicht auf LSB-Komponenten als einzige Abhängigkeiten festlegen. IMO ist die LSB in ihrer Extremform wirklich nur für Distributionen mit komerziellem Unternehmenssupport über mehrere Jahre geeignet, für welche andere Hersteller dann Software entwickeln wollen. (Da ist eine gemeinsame Basis dann wirklich wichtig)
Die LSB hat zudem RPM als Standard für Linux-Pakete festgelegt. Daran (können und wollen) sich Systeme wie Debian und Ubuntu natürlich logischerweise nicht halten. Ich bin bestimmt nicht der Einzige, der sich daher schon überlegt hat, ein PlugIn für Debians APT-Paketmanager zu schreiben, welches RPM-Pakete wie DEB-Pakete installieren kann. (Also beides gleichzeitig auf einem System verwaltet) Leider ist das aktuell unmöglich.
Ein RPM-Paket enthält, wie DEB-Pakete auch, die zu installierenden Dateien plus Paketbeschreibung, Checksummen und eine Liste der Abhängigkeiten zu anderen Paketen sowie weitere Daten. Und da beginnt das Problem: Das RPM-Paket enthält z.B. eine Abhängigkeit zu “PackageKit” oder “Oxygen-Iconset”. Wollte man jetzt dieses Paket mittels APT installieren, würde schon die einfachsten Abhängigkeiten nicht gefunden. Das RPM-Paket “PackageKit” heist in Ubuntu/Debian nämlich “packagekit”, die Oxygen-Icons des KDE-Projektes sind unter Debian nicht im Paket “Oxygen-iconset”, sondern in “kde-icons-oxygen”. Woher soll APT wissen, wo sich die Abhängigkeiten des RPM-Paketes befinden? Und damit nicht genug: Selbst zwischen verschiedenen RPM-Basierten Distributionen wie openSUSE oder Fedora gibt es diese Unterschiede, weshalb man RPM-Pakete meistens nicht unter diesen Distributionen austauschen kann. Zudem hat RPM ein paar weitere Inkonsistenzen, da lange Zeit jeder Distributor seinen eigenen Fork davon entwickelt hat. Erst in letzter Zeit beginnt man, RPM wieder auf eine einheitliche Basis zu stellen.
Alleine schon wegen der Benennung der Abhängigkeiten ist es also quasi unmöglich, ein PlugIn für APT zu programmieren, welches RPM-Pakete verarbeiten kann. Umgekehrt kann man natürlich auch kein PlugIn für den RPM-Paketverwalter “yum” erstellen, welches mit DEB-Paketen arbeiten kann. Manche RPMs enthalten zwar auch direkte Referenzen auf die benötigten Bibliotheken, solche Pakete sind aber extrem selten.
Programme wie alien können zwar RPM-Pakete in DEB-Pakete umwandeln (und umgekehrt), dabei gehen jedoch alle Abhängigkeiten verloren. Unter Anderem deshalb kann man die installierten Anwendungen oft nicht nutzen.
Der einzige Ausweg aus diesem Problem ist z.B. das parallele installieren der Abhängigkeiten, wie es Autopackage macht. Oder aber ein Paketformat, welches keine Abhängigkeiten zu Paketen hat, sondern nur zu Bibliotheken und Dateien. So ist z.B. das Listaller-Format aufgebaut, welches nur ein “Rezept” für Abhängigkeiten enthält. Ähnlich macht es auch das Projekt Klik-Install.
Diese Probleme mit den verschiedenen Paketformaten sind ein wichtiger Grund, warum es keinen Standard für Linux-Setups gibt. Das hat also nicht – wie viele oft meinen – mit der Arroganz der Entwicklergemeinden zu tun, sondern hat schlicht technische Gründe. (Auch wenn meiner Meinung nach natürlich das DEB-Format RPM haushoch überlegen ist 😛 :-D)
Zumindest in der Handhabung der Paketmanagementsysteme sind sich die Distributionen allerdings seit PackageKit näher gekommen. (Obwohl es in der Debian-Community noch immer Vorbehalte gegen das Projekt gibt)
> Diese Probleme mit den verschiedenen Paketformaten sind der einzige Grund, warum es keinen Standard für Linux-Setups gibt.
Auch wenn ich nicht genau weiß, was du damit meinst: So einfach ist die Sache nicht. Selbst wenn es nur deb (oder nur rpm) gäbe, wären trotzdem verschiedene Archive für die einzelnen Distributionen notwendig, da die Kompatibilität von Programmen auch noch an anderen Dingen wie verwendeter glibc usw. hängt.
Umgekehrt, auch mit verschiedenen Archiv-Typen wäre eine einheitliche Handhabung möglich, smart wäre so ein Projekt:
http://wiki.hackerboard.de/index.php/Smart_FAQ_Uebersetzung#Was_ist_Smart.3F
Kann mit deb und rpm umgehen.
Irgend etwas als EINZIGEN Grund hinzustellen, warum es keinen Standard für Linux-Setups gibt, halte ich für sehr gewagt. Da kommen halt viele Faktoren zusammen.
> die Kompatibilität von Programmen auch noch an anderen Dingen wie verwendeter glibc usw. hängt.
Die glibc und weitere Abhängigkeiten wechseln aber nicht so schnell das API, daher könnte man solche Pakete wohl sehr lange nutzen, bevor ein rebuild nötig wäre.
Ich kenne mich mit Smart nicht so gut aus, aber soweit ich das bis jetzt verstanden habe, rann Smart nur mit DEB _oder_ RPM umgehen und nicht mit beidem gleichzeitig.
> Irgend etwas als EINZIGEN Grund hinzustellen, warum es keinen Standard für Linux-Setups gibt, halte ich für sehr gewagt. Da kommen halt viele Faktoren zusammen.
Stimmt, ich ändere die Passage mal, das ist wirklich missverständlich.
PackageKit Löst das Problem mit der einheitlichen Handhabung übrigens ganz hervorragend!
Ich verstehe nicht, was das ganze mit deb vs rpm zu tun hat. Es gibt sogar apt4rmp, das verwendet dann anstatt .deb eben .rpm.
Das rpm Format hat auch nichts damit zu schaffen, was Pakete nun alles beinhalten und was nicht.
Xandros verwendet auch .deb, aber da hast du auch Probleme eine Debian Paket dort zu installieren, weil libs etc evtl. anders heißen.
Wäre aber doch schön, wenn APT DEB _und_ RPM gleichzeitig verwalten könnte. (Darum geht es, ist das missverständlich?)
Verwendet Xandros Debian-Quellen? In der Regel kann man Pakete innerhalb einer Debian-Serie problemlos tauschen.
Außerdem muss man auch mal an Firmen wie z.B. Google denken, die, wenn APT mit DEB und RPM gleichzeitig umgehen könnte nur noch ein Paket bereitstellen müssten.
Nein Xandros ist soviel ich weiß mittlerweile unabhängig von Debian, sie verwenden das .deb format, aber keien debian Quellen.
Deine Aussage war ja: “Alle die deb verwenden haben gleiche Paketnamen”. “Alle die rpm verwenden haben inkonsistente Paketnamen”.
Was schlichtweg falsch ist.
Das Problem ist wie schon gesagt nicht deb vs rpm.
Sondern dass es so viele verschiedene Distributionen gibt, die unterschiedlich inkompatibel sind.
Schaffe 90% der Distributionen ab und man täte sich bei der Standardisierung leichter.
Allgemein hat RPM einen schlechteren Ruf als APT, aber warum eigentlich? Die verkürzte Antwort lautet: Weil es LSB zertifiziert ist. Nein, die LSB ist nicht Schuld, aber die Gründe warum RPM einen schlechten Ruf hat, sind die selben weshalb es in der LSB ist. Der wesentliche Unterschied zwischen einem .deb und einem .rpm ist, dass letzteres theoretisch distributionsunabhängig ist. Debs sind überspitzt gesagt dumm bzw. KISS. Wenn ein .deb in einem System funktioniert für das es nicht gedacht war ist es Glück und man freut sich, .rpms hatten mal den umgekehrten Anspruch.
Zu glauben die Intelligenz müsste in dem Paket oder dessen Format liegen ist ein Irrweg. Die Logik muss im Paketmanager liegen, der das richtige Paket auswählt. Ein “gem install rake” funktioniert bei allen Linuxdistris, allen neueren MacOSX Versionen, den meisten Windowsen und den BSDs. Und gem ist eher ein trivialer Vertreter seiner Zunft, aber das Prinzip schlägt “one package fits all” eben um Längen.
Ich habe da noch eine andere Theorie zum schlechten Ruf:
Debian hat recht früh apt eingeführt und so etwas hatten lange Zeit rpm Distributionen nicht. Da kam dann auch immer der Begriff “Abhängigkeitshorror” auf, weil man manuell alle Pakete, die ein anders Paket als Abhängigkeit benötigte, herunterladen musste.
Bei Debian langte ein apt-get install foo.
Dass das aber nichts mit rpm ansich zu tun hat, ist klar, trotzdem wurde es immer als Vorteil von .deb angesehen und letztlich verglich man eher apt mit rpm.