Das wäre ein großer Schritt in Richtung Standardisierung und damit der Verfügbarkeit kommerzieller Software. Aber bevor Debian auf RPM umsteigt, friert die Hölle zu.
Warum? Die Vorteile von .rpm liegen klar in der Hand - es ist (wenn der Distributor es zu lässt) schneller als Deb, die Abhängigkeiten lassen sich bei korrekter Konfiguration (auch hier wieder wink an den Distributor) einfacher lösen und für Paketbauer ist rpm sowieso das non-plus-ultra (da spreche ich aus eigener Erfahrung).
Ich denke das spielt eher das Ego, als technische Gesichtspunkte eine Rolle. Meiner Meinung nach wird Debian das selbst entwickelte DEB Paketformat nicht aufgeben.
"(wenn der Distributor es zu lässt) schneller als Deb" Kann ich nicht bestätigen. Im großen und ganzen nehmen sie sich exakt nichts. Warum auch, beides sind eher einfache Prozesse. Lange Zeit aber war RPM langsamer, seine Datenbank zu verwalten kostetet einfach mehr Zeit.
"die Abhängigkeiten lassen sich bei korrekter Konfiguration" Debian hält es einfach, und effizient. Die Erfahrung der letzten Jahre zeigt: Das ist auch der richtige weg. Der Begriff "RPM Hell" ist noch nicht so alt.
"Paketbauer ist rpm sowieso das non-plus-ultra" Eher nein. Debian Pakete lassen sich wirklich extrem einfach bauen, einfacher geht es nicht mehr. RPM ist allerdings auch kein Krampf.
rpm ist nicht schlechter als deb - und 'rpm hell' entstand wegen den Tonnen von Abhängigkeiten und nicht, weil rpm so mies ist. Und da ist deb kein Stück besser. Ich behaupte mal, deb ist viel schlechter - vor allem wenn man bonsaikittens weblog ansieht drängt sich der Schluß geradezu auf.
RPM war vor allem auch mies darin, diese Abhängigkeiten aufzulösen. Das hat sich angeblich ja gebessert, aber meine Erfahrungen mit RPM waren bisher nie besonders positiv. Ist allerdings auch schon wieder über ein Jahr her, dass ich zuletzte viel mit RPM zu tun hatte. Ich glaube ja daran, dass Hoffnung besteht.
Von Anonymous Coward am Mo, 9. Februar 2009 um 16:25 #
rpm ist gar nicht in der Lage, Abhängigkeiten aufzulösen, genauso wenig wie das Debian-Pendant dpkg dazu in der Lage ist. Das ist nämlich gar nicht die Aufgabe dieser Programme. Dafür sind Programme wie aptitude, yum, zypper, urpmi usw. zuständig.
Man muss das immer im Zusammenhang sehen: DEB wurde speziell für DEBIAN entwickelt. Das erkennt man auch daran, dass keine andere Distribution, außer den Debian Forks (*buntu, Knoppix, usw usf) DEB einsetzt.
Es gibt doch keinen Grund sich zu streiten :-). Die Nicht-Debianer bleiben bei RPM und die Debianer wissen, was sie an DEB haben und warum sie nie eine RPM basierte Distri vorziehen würden.
Ja. Wobei man es auch sonst einsetzen könnte. Es ist nicht wirklich nur für Debian geeignet.
"Es gibt doch keinen Grund sich zu streiten"
Das sagst du, ich sehe das ganz anders! *zwinker*
"und die Debianer wissen, was sie an DEB haben und warum sie nie eine RPM basierte Distri vorziehen würden."
Jup. Wobei sich die RPM Distries das Leben selbst schwer machen. Da hatte Debian schon Jahrelang apt, und anstatt das sie etwas ähnliches nutzen, oder gar Apt selbst, bauen sie 10 alternativen. Das ist traurig, und für die User nur von Nachteil.
und anstatt das sie etwas ähnliches nutzen, oder gar Apt selbst, bauen sie 10 alternativen. Etwas ähnliches gibt es mit YUM. Wie hätte man APT selbst einsetzen sollen? APT braucht /var/lib/dpkg. Welche 10 Alternativen meinst du eigentlich?
Wie macht apt4rpm(?) das? APT-RPM ist nicht APT. Es ist ein an RPM angepasstes System, das aber einige Design-Schwächen hat. Man kann nicht einfach Debians APT einsetzen, da es auf DEB spezialisiert ist und damit am besten zurecht kommt. Es kennt keinerlei Besonderheiten von RPM. So war auch APT-RPM zumindest früher nicht in der Lage mit verschiedenen Architekturen umzugehen. In der Debian-Welt gibt es das ja auch heute noch nicht. Der Dependency-Resolver (das, was APT eigentlich ausmacht) musste also ohnehin neu geschrieben werden. Was letztendlich übrig bleibt, ist die Syntax.
Ach, man kann ein eigenes System entwickeln, ist aber zu blöd ein vorhandenes anzupassen? Spricht ja eher gegen APT, wenn es so unflexibel ist Du hast mich offensichtlich missverstanden. Natürlich kann man einen vorhandenen Paketmanager (APT) mit mehr oder weniger Aufwand an ein völlig anderes Paketformat (RPM) anpassen, dann ist es aber eben nicht mehr APT, sondern nur noch APT-ähnlich.
"rpm ist nicht schlechter als deb" wo schrieb ich das?
"und 'rpm hell' entstand wegen den Tonnen von Abhängigkeiten und nicht,"
ja, aber die art der Abhängigkeiten war eben durch RPM vorgegeben. Es hat nie eien Deb Hell gegeben, weil deb anders arbeitet. Die 'rpm hell' wurde durchaus durch das Format gefördert.
Ich bin mir zudem nicht sicher wen du mit bonsaikitten meinst.
nein, es hat nie eine 'deb hell' gegeben, weil nicht Leute versucht haben, debs von der einen mit einer völlig anderen Distri zu benutzen - denn dann fällt deb auch auseinder.
deb mußte sich nie den Problemen stellen, die man rpm zugemutet hat. http://www.gentooexperimental.org/~patrick/weblog/index.html (gerade down)
"nein, es hat nie eine 'deb hell' gegeben, weil nicht Leute versucht haben, debs von der einen mit einer völlig anderen Distri zu benutzen - denn dann fällt deb auch auseinder."
Nein, deb fällt aus dem Grund nicht auseinander weil man dort selten mit einzelnen Dateien arbeitet. Apt, das früh zur verfügung stand, hat das Problem von vornerein vermieden. Zudem nenntn dir deb immer das fehlende Paket, nicht die fehlende Datei, was bei rpm früher ein großes Problem war. Ich kann mich noch nur zu gut an die Suchorgien nach dem Paket mit der richtigen Datei erinnern.
"deb mußte sich nie den Problemen stellen, die man rpm zugemutet hat." rpm wurde das aber auch zugemutet weil nicht weit genug gedacht wurde. Während Debian früh und effizient auf organisierte Paketquellen gesetzt hat, hatte rpm wie du schon sagst, immer eher den pro-Datei charakter. Das ist chaos pur.
Grundsätzlich ist eben das Problem das deb immer mit apt kommt, aber rpm alleine dasteht. Das mag als vergleich unfair wirken, aber am Ende ist es der Fehler der rpm Distries das sie die Lücken lange nicht geschlossen haben. SuSE hatte es mit Yast2 versucht, aber der versuch war eher unschön. Yast2 ist zu fett und langsam (mehr oder weniger gewesen), die Handhabung externer quellen war unpraktisch, die Konsolentools galten als unfertig. Und heute gibts praktisch eine Lösung pro Distrie, das ist auch nicht schön.
Da hätten die Distries lieber apt4rpm nutzen sollen.
Da hätten die Distries lieber apt4rpm nutzen sollen. Warum sollte man einen dreckigen Hack nutzen, der "rpm -i --force --nodeps" ausführt, weil er keinen Zugriff auf die Paketdatenbank hat? Debians APT dagegen kann direkt auf die dpkg-Datenbank zugreifen und ist deshalb nicht darauf angewiesen, Pakete irgendwie ins System zu hämmern.
Ich meinte es mehr im Sinne von apt, gut den Namen apt4rpm zu nutzen war nicht so sinnvoll. Es hätte auch eine Neuimplementierung sein können. Zweifellos hätte man aber mit wenig Mühe eine angemessene Lösung bauen können. Stattdessen wurden gleich mehrere Alternativtools gebaut. Das war wenig hilfreich.
Stattdessen wurden gleich mehrere Alternativtools gebaut. Das war wenig hilfreich. Hat man das bei Debian nicht? apt, aptitude, dselect, ... Natürlich auch mit jeweils unterschiedlichen Features.
Nicht wirklich, den yum und co. existierend gleichzeitig, und haben auch miteinander nichts zu tun.
dselect, apt und aptitute aber stehen eher in einer evolutionären Reihe. apt hat dselect den rang abgelaufen, und apt soll durch aptitute ersetzt werden, nicht das gleiche für eine andere Zielgruppe nochmal bieten.
Das ist schlicht eine organische Weiterentwicklung, kein Konkurrenzkampf unter verschiedenen Distries.
und apt soll durch aptitute ersetzt werden Bitte? Woher hast du denn die Information? Wenn dem so wäre, hätte man die Funktionalität, dass der Paketmanager sich merkt, welche Pakete manuell und welche als Abhängigkeit installiert wurden, nicht nachträglich in apt eingebaut. Im Übrigen wird aptitude apt niemals ersetzen können.
Das ist schlicht eine organische Weiterentwicklung, kein Konkurrenzkampf unter verschiedenen Distries. Wozu auch, wenn es nur eine einzige Distribution, nämlich Debian, gibt? Aber welchen Konkurrenzkampf siehst du? Sowohl Fedora als auch openSUSE kommen mit yum.
Nein, aptitude benötigt libapt-pkg, was Teil von apt ist. Außerdem ist aptitude nicht darauf ausgelegt, mit kaputten Dependencies, wie sie bei sid immer wieder auftreten, klar zu kommen. Es schlägt einem vor, das halbe System zu deinstallieren, was natürlich ein ganz schlechte Lösung ist. So etwas kann man nur gebrauchen, wenn die Abhängigkeiten sauber sind, wie in stable.
im gegenteil, ich fand aptitude bei kaputten deps immer erste sahne. es halt, vlt nicht gleich als erste loesung, immer etwas sinniges angeboten,wo apt einfach aussteigt...dank aptitude war bei mir sid nutzen wesentlich stressfreier als frueher mit apt.
Von Daniel Baumann am Mo, 9. Februar 2009 um 17:58 #
"und apt soll durch aptitute ersetzt werden, nicht das gleiche für eine andere Zielgruppe nochmal bieten."
nope; aptitude war fuer sarge->etch upgrade empfohle weils damals einen besseren resolver als apt hatte; heute ist das aber wieder umgekehrt, aptitude hat ein paar sehr nervige bugs. seit lenny, und beim upgrade etch->lenny sollte man daher apt nehmen, nicht aptitude.
Von Anonymer Feigling am Di, 10. Februar 2009 um 11:46 #
Nein, in wahrheit ist es so, dass sowohl apt-get als auch aptitudeebenso wie Synaptic auf APT aufsetzen. Aptitude hat einige Vorteile gegenüber apt-get gehabt, wie das tracken der mitinstallierten Dependencies, die aber afair in inzwischen auch in apt-get aufgenommen wurden.
Natürlich hatte das damit zu tun, dass niemand .deb-Dateien anderer Distributionen versuchte auf seinem Debian zu installieren. Eben weil es keine anderen Distributionen gab. Außerdem find ich es um weiten sauberer mit Symbolen und Dateien als Abhängigkeiten zu arbeiten, als mit vollständigen Paketen. Denn hat man einfach die Pakete seiner Distribution benutzt, gab es praktisch keine Probleme. Desweiteren ist .deb in vielen "Enterprise"-Bereichen durchgefallen, weil es einfach Ewigkeiten keine signierten Pakete gab. Wohl verschlafen, eben wie Deltra-RPMs.
"Natürlich hatte das damit zu tun, dass niemand .deb-Dateien anderer Distributionen versuchte auf seinem Debian zu installieren."
Nicht nur. Debian konnte, dadurch das es Paketweise arbeitet, statt eher Dateiorientiert, von anfang an sauberer die Abhängigkeiten aufbauen, und auch für die User transparenter.
Heute haben wir verschiedene Deb Distries, die sich alle auf Namenschemen geeinigt haben, auf Pakete der Urdistrie aufbauen können, andere austauschen und immernoch eine hohe Kompatibilität bewahren. (auch wenn es natürlich Grenzen hat. Wenn sie völlig austauschbar wären, wären es garnicht erst verschiedene Distries) Aber eben das haben die RPM Distries garnicht erst versucht.
"Außerdem find ich es um weiten sauberer mit Symbolen und Dateien als Abhängigkeiten zu arbeiten, als mit vollständigen Paketen."
Die Realität hat aber die enormen Nachteile gezeigt.
"Desweiteren ist .deb in vielen "Enterprise"-Bereichen durchgefallen, weil es einfach Ewigkeiten keine signierten Pakete gab. Wohl verschlafen, eben wie Delta-RPMs."
Debian hatte andere Prioritäten gesetzt. Niemand hätte aber die Distrie gehindert diese Funktionen zu integrieren. Bei RPM haben sie ja auch getan.
"Denn hat man einfach die Pakete seiner Distribution benutzt, gab es praktisch keine Probleme. "
Hierzu nochmal: Das ist in der Realität eben sehr schwer. Wer will schon nur nutzen was die Distrie bietet? Spätestens bei 3. Quellen wird es dann schwer. Während man dann meist 4-5 RPMs findet, gibts nur eine Debian Datei. Die ist dann gleich für alle Deb Distries geeignet. Es geht also, wenn man will. Die RPM Distries haben sich an LSB festgehalten, und damit versucht ans Ziel zu kommen. Andere haben schlicht auf eine freie Distrie aufgenbaut. Ich persönlich empfinde aktuell den letzten Ansatz als aktuell erfolgreicher bei der Kompatibilität, und Vermeidung der Pakethölle.
Heute haben wir verschiedene Deb Distries, die sich alle auf Namenschemen geeinigt haben Nein, haben sie nicht. Jedenfalls hat keine formale Einigung stattgefunden. Dass die Paketnamen von Debian beibehalten werden, liegt einfach daran, dass man Debians Vorarbeit nutzen will, und das könnte man nicht, wenn man sich zu sehr entfernt. Red Hat und SUSE haben aber in der Historie nichts miteinander zu tun.
Aber eben das haben die RPM Distries garnicht erst versucht. Es sind Konkurrenten, die im Wettbewerb zueinander stehen. Sie sind auch auf Kundenbindung angewiesen.
Die Realität hat aber die enormen Nachteile gezeigt. Welche? Man hätte als Distributor Pakete, die Bibliotheken enthalten, einfach nach ihnen benennen sollen. Mandriva macht das übrigens so.
Während man dann meist 4-5 RPMs findet, gibts nur eine Debian Datei. Die ist dann gleich für alle Deb Distries geeignet. Ist sie nicht. Schau dich nur mal bei Opera um. Wenn man natürlich Qt etc. statisch linkt, wie das beim Skype-DEB der Fall ist, braucht man auch nur ein Paket.
Die RPM Distries haben sich an LSB festgehalten, und damit versucht ans Ziel zu kommen. Die LSB hat nicht das Ziel, Pakete der Distributionen untereinander kompatibel zu machen! Das Ziel ist, dass Dritte (ISVs) nur ein Paket bereitstellen müssen, das unter allen LSB-konformen Distributionen funktioniert. Dabei darf das Paket nur in der LSB erwähnte Symbole verwenden und muss die übrige Funktionalität selbst mitbringen. VMware und Co. brauchen nur ein RPM-Paket für alle Distributionen.
Andere haben schlicht auf eine freie Distrie aufgenbaut. Schon mal daran gedacht, dass die Entwicklungslinien von SUSE und Red Hat parallel zu Debian verlaufen und nicht erst später entstanden sind?
Nebenbei hat DEB noch den Nachteil, dass es keine Multi-Arch-Unterstützung gibt. Das erwähnte Skype-DEB lässt sich auf einem AMD64-Etch nicht installieren.
Von DuuuuDoooooh am Di, 10. Februar 2009 um 11:52 #
Mir ist es auch mit Anleitung nie gelungen, ein RPM zu bauen - irgendwelche "spec-files" editieren usw. usf.
Aha. Daraus soll man was folgern ? Dass das unten nirgens dokumentiert ist ? Oder du es gar nie versucht hast ?
1. Quellcode in Folder SOURCES ..--^^ muss NICHT ausgepackt werden. Geschieht automatisch ! 2. rpmdev-newspec myapp 3. Im Spec: Version Eintragen, Source0 Eintragen ..--^^ equivalent zum editieren der debian/rules 4. rpmbuild -bb myapp.spec ..--^^ dieser schritt Packt das tar.gz aus, ./configure, make, make install in fakeroot, dann auto requires / provides, und binary bauen
Ausser das dh_make Anforderungen ans (ausgepackte!!!) Tarball hat ( Paketname-Paketversion/... ) und sich damit dh_make den Schritt 2(@RPM) semiautomatisiert. Das RPM-Paket ist zwar vorne und hinten nicht konform, aber es wird gebaut. In 3,5 Schritten mit RPM. Das ist aber dein Deb auch nicht. Die Description / License etc... muss auch im rules angepasst werden (aber das hab ich mal aussenvorgelassen).
Ich weiß zwar nicht genau, was Du mir sagen willst, aber: Ich bin ein durchschnittlich erfahrener Linux-User. Ich habe mal eine RPM-basierte Distribution (Fedora 7 oder ausprobiert, davor hatte ich Debian (danach auch wieder). Ich brauchte ein neues Paket von LYX, das nirgends aufzutreiben war.
Komischerweise war die Anleitung, die ich zur Erzeugung von RPMs genutzt habe, nicht so einfach, wie Du sie beschreibst. Ich kam trotz Anleitung nicht zum Ziel, mit Debian schon. Das ist das einzige, worum es mir hier geht. Es sagt nicht, dass RPM "schlecht" ist.
Von DuuDooooooh am Do, 12. Februar 2009 um 09:01 #
Ich brauchte ein neues Paket von LYX, das nirgends aufzutreiben war.
Das geht meistens noch vieeeel Einfacher.
src.rpm des alten LYX organisieren, und auspacken. Die neue LYX (das tar.gz) in den SOURCES Ordner kopieren Im Spec die Version anpassen rpmbuild -bb lyx.spec
Oder anders: Debian ist zum Packagen nicht (mehr*) Einfacher. Gruss
*war früher wohl mal so (als noch keine spec helper scripts etc... vorhanden waren)
Von meisterlinus am Mo, 9. Februar 2009 um 18:17 #
Das wäre ein großer Schritt in Richtung Standardisierung und damit der Verfügbarkeit kommerzieller Software. Dann aber bitte auf einen durchdachten Standard setzen und nicht auf was, was zwar vlt. weiterverbreitet aber technologisch rückständiger ist. Den Einsatz von ODF statt DOC(X) würde schließlich auch jeder befürworten.
Schon lustig, daß es wieder mal ein Troll geschafft hat das Thema RPM vs. DEB anzuschneiden, und dann ganz viele "Experten" zum Thema sabbeln, die selbst offensichtlich noch kein einziges Paket (weder RPM noch DEB) erstellt haben:
Da kann mal wieder zw. Paketformat und Paketmanager nicht unterschieden werden.
Und das Thema "welches Format löst Abhängigkeiten besser auf" darf auch nicht fehlen. Natürlich kommt keinem in den Sinn, daß man beim Paketbau (egal ob RPM oder DEB) Fehler machen kann, wodurch bei beiden Formaten und in den meisten Fällen Probleme beim Auflösen der Abhängikeiten entstehen können. Außerdem gibt es dann noch die Spezialisten die einfach alles installieren, wenn nur rpm oder deb hinten dranstehnt. Noch schlimmer: Man wandelt per "alien" das Fremdpaket um. Und wundert sich dann, daß es Probleme im Paketsystem gibt...
Vorweg, ich war ~5 Jahre aktiver Debianpackager (diverse Backports, als auch einige Pakete selber maintained). Nun arbeite ich beruflich bedingt mit RPM. Ich erlaube mir also zu sagen: "ich kenne beide Systeme".
1. Deb haben genau gleich Abhängigkeitsprobleme wie RPM (Sofern die Requires nicht vorhanden sind, bzw. falsch sind). Was aber ist: Bei Debian kam gleich mal ein apt-get mit, bei den anderen war mal up2date, mal yum, mal yast, whatever. Alle die behaupten dass mit .deb (dem Paketformat) keine Dep-Hell möglich ist hat den Unterschied eines Paketformats zu einem Paketmanagement noch nicht begriffen.
2. Was für RPM Spricht: Man hat als Maintainer genau 1(!!) File das man pflegen muss. Das SPEC. Bei Debian ist es ein ganzer Folder (`control' `copyright' `changelog' `rules' `conffiles' `dirs' `docs' `postinst' `preinst' `postrm' 'prerm`...pipapo)
3. rpm -V builtin, debsums ist ein separates package
Dann was Subjektives: Ich (persönlich) find das bauen von rpm's viel Komfortabler als den Bau von deb's.
Was evt. nice wäre, wäre ein TAG wo man gewisse Distris Taggen könnte, die verhindern dass einer auf nem SuSe mit manuellem rpm -ivh es schafft ein Paket aufs System zu hauen, dass eigentlich für eine andere Distri gebaut wurde.
Ansonsten finde ich vor allem diese Neuerungen ganz Nett: * %{_topdir} defaults to $(HOME)/rpmbuild/ now, instead of former /usr/src/redhat/. * Rpm enforces BuildRoot for all packages and ignores the directive in spec. * Dependencies for pkg-config and libtool files are automatically generated by rpmbuild. * rpmbuild automatically creates the build directory structure if necessary.
"Alle die behaupten dass mit .deb (dem Paketformat) keine Dep-Hell möglich ist hat den Unterschied eines Paketformats zu einem Paketmanagement noch nicht begriffen."
Das Problem ist aber eben das apt schon da war, als SuSE und co. noch stark an ihren Tools gearbeitet haben, und diese eben langezeit ihre Arbeit auch nur sehr mittelmässig vollzogen haben. Nicht grundlos wurden sie inzwischen fast alle ausgewechselt. Natürlich ist apt eine andere Stufe als rpm, aber bei RPM Distries war der Kontakt mit rpm direkt oft nötig und vorgesehen, aber bei Debian war und ist eben apt bzw. jetzt aptitute der immer gepredigte weg. Ich habe lange Jahre RPM Distries genutzt, und bin selbst oft mit dem Problem in Berühung gekommen.
Man kann an dem Thema viel rumdiskutieren, aber es gibt eben den bekannten Begriff der RPM hell, aber niemand spricht von einer deb hell. Im grunde ist daran nicht rpm schuld, aber die Distries haben eben lange gepennt, bis es so oft gekracht hat das man es nicht mehr überhören konnte
Von meisterlinus am Mo, 9. Februar 2009 um 18:15 #
Alle die behaupten dass mit .deb (dem Paketformat) keine Dep-Hell möglich ist hat den Unterschied eines Paketformats zu einem Paketmanagement noch nicht begriffen. Nur löst apt(itude) die Probleme in aller Regel wesentlich intelligenter als yum, yast & co.
2. Was für RPM Spricht: Man hat als Maintainer genau 1(!!) File das man pflegen muss. Das SPEC. Bei Debian ist es ein ganzer Folder (`control' `copyright' `changelog' `rules' `conffiles' `dirs' `docs' `postinst' `preinst' `postrm' 'prerm`...pipapo)
Richtig. Und das ist auch gut so. Informationen sind so sauber getrennt und nicht in einer Datei zusammengewürfelt. Frag mich ja eh, wer auf die Idee kommt, z.B. Paketabhängigkeiten, Installationsscripte und Buildregeln in eine Datei zu schmeißen - schaffen nur die RPM-Frickler... Oder packe ich als Programmierer etwa den Inhalt von configure.ac/Makefile.am/CMakeLists.txt/whatever in meine Quellcodedateien? Gerade die sauberer Trennung sehe ich als einen der größten Vorteile von DEB überhaupt und ich hoffe, dass das auch so bleibt. Auch die strikte Versionshistory mittels debian/changelog sorgt in der Regel für eine viel bewusstere Arbeit beim Paketieren, da alle Änderungen sauber zu dokumentieren sind (wenn auch nicht zwangsweise). Ich baue selber seit mehreren Jahren Debian-Pakete und bin froh, dass ich vor 2 Jahren nur mal kurz mit RPM-Paketierung zu tun hatte..
3. rpm -V builtin, debsums ist ein separates package Auch hier wieder eine saubere Trennung der Lösung von Problemen. Klar, dem einen gefällt die Eier legende Wollmilchsau mit hunderten schwer-einprägbaren Parametern aber ich finde da den Ansatz "ein Programm für ein Problem" wesentlich übersichtlicher (oder hast du ein Gartengerät, was man immer erst umständlich zu einem Spaten, einer Harke, einem Laubbesen o.ä. umbauen muss?) und vorallem weniger fehlerträchtig bei der Verwendung - ein aus Versehen klein oder großgeschriebener Parameter macht nicht gleich was völlig anderes, als das, was ich will.
Nungut, was die Zerstückelung angeht, da kann man drüber streiten. Ich finds mühsam 12 Files zu pflegen wenn es auch in einem File geht.
Frag mich ja eh, wer auf die Idee kommt, z.B. Paketabhängigkeiten, Installationsscripte und Buildregeln in eine Datei zu schmeißen
Nungut, ein Specfile spezifiziert wie ein RPM gebaut werden soll. Sogesehen hat es sehr wohl Sinn dahinter alles in einem File zu halten.
schaffen nur die RPM-Frickler
...Sagt viel über dein Niveau aus... Debian halt :>
Auch die strikte Versionshistory mittels debian/changelog sorgt in der Regel für eine viel bewusstere Arbeit beim Paketieren
Stell dir vor, in den rpm spec's gibts genau eine solche. Boah.
Ich diskutiere gerne mit anderen. Solange Argumente kommen. Und nicht "Pha-Das-Ist-Frickelzeugs". Auf so ein Niveau gehe ich eigentlich nicht mehr ein (bin ich zulange dabei =).
Bei aller Geschmacksfrage stimme ich mit dem OP überein das eine saubere Trennung von Informationen und Funktionen ein wichtiger Grundstein indem insgesamt sauberer wirkendem DEB-System legen. Insofern finde ich au passage auch das der OP ein sehr wesentliches Argument bringt, dem Du nichts entgegensetzt. Ausser dem unglücklich benutztem "RPM-Frickler" fand ich den Beitrag also aussagekräftiger. Und wer so ein kleines Wörtchen gleich als Anlass zu Niveau-Diskussionen sieht sollte es vielleicht mit dem Niveau nicht immer zu ernst nehmen.
Man kann es mit der Trennung aber genauso auch übertreiben. In dem Sinne haben beide Seiten recht gute Argumente und es ist letztlich reine Geschmackssache.
Von DuuuuDoooooh am Di, 10. Februar 2009 um 09:44 #
Bei aller Geschmacksfrage stimme ich mit dem OP überein das eine saubere Trennung von Informationen und Funktionen ein wichtiger Grundstein indem insgesamt sauberer wirkendem DEB-System legen.
Für mich ist das Auftrennen in verschiedene Files vor allem eine Fehlerquelle. Das RPM-spec ist sauber gegliedert (Wie ein Buch, mit Titel, Einleitung, Kapitel und Anhang). Man editiert 1(!)File und hat auch ein Changelog in selbigen (im Prinzip der Anhang). Ich finde es unglückich, beim Packagen, mit einer IDE ein Projekt zu eröffnen um parallel >7 Files zu bearbeiten. Logo, grundsätzlich ist es gut gewisse Dinge zu trennen. Bei so etwas trivialem wie einem spec File sehe ich aber mehr Nachteile als Vorteile.
Einerseits Geschmackssache, andererseits denke ich aber, dass viele .deb Packager sich noch NIE wirklich mit rpm packagen veschäftigt haben. Wieso auch... die Erde ist eine Scheibe und alles ausser Debian ist sowieso Mist. Mitunter ein Grund, dass ich Debian den Rücken zugekehrt habe. Zuviele Fanatiker, zuviele "Möchtegern-UberHacker",... und ein massiv Arroganter Umgangston mit anderen Linux-Community Mitgliedern.
Nur löst apt(itude) die Probleme in aller Regel wesentlich intelligenter als yum, yast & co. Das liegt nicht an den Paketmanagern, sondern daran, dass die Paket-QS bei Debian wesentlich besser ist als bei allen anderen Distributionen. Upgrade-Probleme werden zu RC-Bugs, die Releases über Wochen/Monate hinauszögern. Bei anderen Distributionen sieht man da gerne mal drüber hinweg.
Schdimmt, Debian ist Fertig, wenns Fertig ist. Fedora bspw. Released alle 6 Monate. Ob fertig oder nicht :-/
Ob das gut ist, sei dahingestellt. Für die welche mit solchen Distris (wie Fedora) auf Nummer sicher gehen wollen: Zuwarten mis ReleaseDate + 3 Monate und sich nen Respin besorgen mit Updates :)
Die Fedorazyklen sind recht kurz, es gibt nur ca. 13 Monate Updates, wenn alle 6 Monate eine neue Fedora herauskommt. So kommt es wahrscheinlich schon einmal vor, dass ausgerechnet in dem Moment, in dem eine Fedora endlich völlig reibungslos funktioniert, ihr "end of life" verkündet wird. Dagegen ist OpenSuse mit 24 Monaten recht lang. Debian bringt es dem gegenüber auf etwa (mehr oder weniger (un)geplante) 36 Monate. Linuxnutzer haben natürlich unterschiedliche Prioritäten. Ich wüßte jetzt aus dem Stehgreif auch nicht, welchen Fedora-Versionen im Hinblick auf die "Aktualität" der verwendeten Software Debian Etch und Lenny in etwa entsprechen würden.
Von DuuuuDoooooh am Di, 10. Februar 2009 um 09:37 #
Ich wüßte jetzt aus dem Stehgreif auch nicht, welchen Fedora-Versionen im Hinblick auf die "Aktualität" der verwendeten Software Debian Etch und Lenny in etwa entsprechen würden.
Vielen Dank für die Auflistung: Die alte glibc in Etch (glibc 2.3.6) war übrigens "notwendig", um ein reibungsloses Update des Kernel 2.4-Sarge (glibc 2.3.2) nach Etch zu gewährleisten, sonst wäre es wenigstens glibc 2.4 geworden. Aus diesem Grund enthält auch die letzte Kernel-2.4-Version von Slackware (Slackware 11.0) noch glibc 2.3.6 und eben nicht wenigstens glibc 2.4. Glibc 2.4 und Kernel 2.4, das funktioniert leider nicht. Und bei einem dist-upgrade wird die glibc gleich zu anfangs aktualisiert. Ein Debian nicht problemlos auf die neue, folgende Version updaten zu können, ist für das Debian-Projekt ein schwerer Bug, der die Veröffentlichung um Monate verzögern kann. Lieber akzeptierte man damals die alte glibc in Etch. Von der Software her entspricht Etch wohl eher Fedora Core 6, jedenfalls ähnelt die Softwarezusammenstellung von Etch (von der glibc einmal abgesehen) sehr RHEL 5.
Von DuuuuDoooooh am Di, 10. Februar 2009 um 14:31 #
Von der Software her entspricht Etch wohl eher Fedora Core 6, jedenfalls ähnelt die Softwarezusammenstellung von Etch (von der glibc einmal abgesehen) sehr RHEL 5.
Kann ich bestätigen. Hab mir mal die Xorg Version angeschaut.
1) Fedora ist bereits gegenüber anderen Distributionen sehr schnell ausgereift. 2) Fedora wird immer bis zum Erscheinen des übernächsten Nachfolgers unterstützt, also mehr als 24 Monate. 3) Wer wirklich mehr will kann CentOS nehmen und auf 7 Jahre Updates zählen.
Aber bevor Debian auf RPM umsteigt, friert die Hölle zu.
Meiner Meinung nach wird Debian das selbst entwickelte DEB Paketformat nicht aufgeben.
Uh, echt? Wow, gut zu wissen ;)
"(wenn der Distributor es zu lässt) schneller als Deb"
Kann ich nicht bestätigen. Im großen und ganzen nehmen sie sich exakt nichts. Warum auch, beides sind eher einfache Prozesse. Lange Zeit aber war RPM langsamer, seine Datenbank zu verwalten kostetet einfach mehr Zeit.
"die Abhängigkeiten lassen sich bei korrekter Konfiguration"
Debian hält es einfach, und effizient. Die Erfahrung der letzten Jahre zeigt: Das ist auch der richtige weg. Der Begriff "RPM Hell" ist noch nicht so alt.
"Paketbauer ist rpm sowieso das non-plus-ultra"
Eher nein. Debian Pakete lassen sich wirklich extrem einfach bauen, einfacher geht es nicht mehr. RPM ist allerdings auch kein Krampf.
Die Antwort lautet natürlich nein.
Wenn man Distri-rpms nimmt, dann funktionieren die perfekt.
Wenn sich die Linuxwelt jetzt wenigstens auf ein Tool geeinigt hätte...
... weshalb sollte das gut sein? Damit auch die Doofen die Übersicht behalten?
sry konnte nicht widerstehen
Man muss das immer im Zusammenhang sehen: DEB wurde speziell für DEBIAN entwickelt. Das erkennt man auch daran, dass keine andere Distribution, außer den Debian Forks (*buntu, Knoppix, usw usf) DEB einsetzt.
Es gibt doch keinen Grund sich zu streiten :-). Die Nicht-Debianer bleiben bei RPM und die Debianer wissen, was sie an DEB haben und warum sie nie eine RPM basierte Distri vorziehen würden.
Ja. Wobei man es auch sonst einsetzen könnte. Es ist nicht wirklich nur für Debian geeignet.
"Es gibt doch keinen Grund sich zu streiten"
Das sagst du, ich sehe das ganz anders! *zwinker*
"und die Debianer wissen, was sie an DEB haben und warum sie nie eine RPM basierte Distri vorziehen würden."
Jup. Wobei sich die RPM Distries das Leben selbst schwer machen. Da hatte Debian schon Jahrelang apt, und anstatt das sie etwas ähnliches nutzen, oder gar Apt selbst, bauen sie 10 alternativen.
Das ist traurig, und für die User nur von Nachteil.
Etwas ähnliches gibt es mit YUM. Wie hätte man APT selbst einsetzen sollen? APT braucht /var/lib/dpkg.
Welche 10 Alternativen meinst du eigentlich?
Wie macht apt4rpm(?) das?
> APT braucht /var/lib/dpkg.
Ach, man kann ein eigenes System entwickeln, ist aber zu blöd ein vorhandenes anzupassen? Spricht ja eher gegen APT, wenn es so unflexibel ist
APT-RPM ist nicht APT. Es ist ein an RPM angepasstes System, das aber einige Design-Schwächen hat.
Man kann nicht einfach Debians APT einsetzen, da es auf DEB spezialisiert ist und damit am besten zurecht kommt. Es kennt keinerlei Besonderheiten von RPM. So war auch APT-RPM zumindest früher nicht in der Lage mit verschiedenen Architekturen umzugehen. In der Debian-Welt gibt es das ja auch heute noch nicht. Der Dependency-Resolver (das, was APT eigentlich ausmacht) musste also ohnehin neu geschrieben werden. Was letztendlich übrig bleibt, ist die Syntax.
Ach, man kann ein eigenes System entwickeln, ist aber zu blöd ein vorhandenes anzupassen? Spricht ja eher gegen APT, wenn es so unflexibel ist
Du hast mich offensichtlich missverstanden. Natürlich kann man einen vorhandenen Paketmanager (APT) mit mehr oder weniger Aufwand an ein völlig anderes Paketformat (RPM) anpassen, dann ist es aber eben nicht mehr APT, sondern nur noch APT-ähnlich.
wo schrieb ich das?
"und 'rpm hell' entstand wegen den Tonnen von Abhängigkeiten und nicht,"
ja, aber die art der Abhängigkeiten war eben durch RPM vorgegeben. Es hat nie eien Deb Hell gegeben, weil deb anders arbeitet. Die 'rpm hell' wurde durchaus durch das Format gefördert.
Ich bin mir zudem nicht sicher wen du mit bonsaikitten meinst.
deb mußte sich nie den Problemen stellen, die man rpm zugemutet hat.
http://www.gentooexperimental.org/~patrick/weblog/index.html
(gerade down)
Nein, deb fällt aus dem Grund nicht auseinander weil man dort selten mit einzelnen Dateien arbeitet. Apt, das früh zur verfügung stand, hat das Problem von vornerein vermieden. Zudem nenntn dir deb immer das fehlende Paket, nicht die fehlende Datei, was bei rpm früher ein großes Problem war.
Ich kann mich noch nur zu gut an die Suchorgien nach dem Paket mit der richtigen Datei erinnern.
"deb mußte sich nie den Problemen stellen, die man rpm zugemutet hat."
rpm wurde das aber auch zugemutet weil nicht weit genug gedacht wurde. Während Debian früh und effizient auf organisierte Paketquellen gesetzt hat, hatte rpm wie du schon sagst, immer eher den pro-Datei charakter. Das ist chaos pur.
Grundsätzlich ist eben das Problem das deb immer mit apt kommt, aber rpm alleine dasteht. Das mag als vergleich unfair wirken, aber am Ende ist es der Fehler der rpm Distries das sie die Lücken lange nicht geschlossen haben.
SuSE hatte es mit Yast2 versucht, aber der versuch war eher unschön. Yast2 ist zu fett und langsam (mehr oder weniger gewesen), die Handhabung externer quellen war unpraktisch, die Konsolentools galten als unfertig.
Und heute gibts praktisch eine Lösung pro Distrie, das ist auch nicht schön.
Da hätten die Distries lieber apt4rpm nutzen sollen.
Warum sollte man einen dreckigen Hack nutzen, der "rpm -i --force --nodeps" ausführt, weil er keinen Zugriff auf die Paketdatenbank hat? Debians APT dagegen kann direkt auf die dpkg-Datenbank zugreifen und ist deshalb nicht darauf angewiesen, Pakete irgendwie ins System zu hämmern.
Zweifellos hätte man aber mit wenig Mühe eine angemessene Lösung bauen können. Stattdessen wurden gleich mehrere Alternativtools gebaut. Das war wenig hilfreich.
Hat man das bei Debian nicht? apt, aptitude, dselect, ... Natürlich auch mit jeweils unterschiedlichen Features.
dselect, apt und aptitute aber stehen eher in einer evolutionären Reihe. apt hat dselect den rang abgelaufen, und apt soll durch aptitute ersetzt werden, nicht das gleiche für eine andere Zielgruppe nochmal bieten.
Das ist schlicht eine organische Weiterentwicklung, kein Konkurrenzkampf unter verschiedenen Distries.
Bitte? Woher hast du denn die Information? Wenn dem so wäre, hätte man die Funktionalität, dass der Paketmanager sich merkt, welche Pakete manuell und welche als Abhängigkeit installiert wurden, nicht nachträglich in apt eingebaut. Im Übrigen wird aptitude apt niemals ersetzen können.
Das ist schlicht eine organische Weiterentwicklung, kein Konkurrenzkampf unter verschiedenen Distries.
Wozu auch, wenn es nur eine einzige Distribution, nämlich Debian, gibt? Aber welchen Konkurrenzkampf siehst du? Sowohl Fedora als auch openSUSE kommen mit yum.
Beweis durch Behauptung? So ein Quatsch, natürlich kann aptitude apt ersetzen.
Außerdem ist aptitude nicht darauf ausgelegt, mit kaputten Dependencies, wie sie bei sid immer wieder auftreten, klar zu kommen. Es schlägt einem vor, das halbe System zu deinstallieren, was natürlich ein ganz schlechte Lösung ist. So etwas kann man nur gebrauchen, wenn die Abhängigkeiten sauber sind, wie in stable.
nope; aptitude war fuer sarge->etch upgrade empfohle weils damals einen besseren resolver als apt hatte; heute ist das aber wieder umgekehrt, aptitude hat ein paar sehr nervige bugs. seit lenny, und beim upgrade etch->lenny sollte man daher apt nehmen, nicht aptitude.
Also APT != Programm das APT nutzt.
Nicht nur. Debian konnte, dadurch das es Paketweise arbeitet, statt eher Dateiorientiert, von anfang an sauberer die Abhängigkeiten aufbauen, und auch für die User transparenter.
Heute haben wir verschiedene Deb Distries, die sich alle auf Namenschemen geeinigt haben, auf Pakete der Urdistrie aufbauen können, andere austauschen und immernoch eine hohe Kompatibilität bewahren. (auch wenn es natürlich Grenzen hat. Wenn sie völlig austauschbar wären, wären es garnicht erst verschiedene Distries)
Aber eben das haben die RPM Distries garnicht erst versucht.
"Außerdem find ich es um weiten sauberer mit Symbolen und Dateien als Abhängigkeiten zu arbeiten, als mit vollständigen Paketen."
Die Realität hat aber die enormen Nachteile gezeigt.
"Desweiteren ist .deb in vielen "Enterprise"-Bereichen durchgefallen, weil es einfach Ewigkeiten keine signierten Pakete gab. Wohl verschlafen, eben wie Delta-RPMs."
Debian hatte andere Prioritäten gesetzt. Niemand hätte aber die Distrie gehindert diese Funktionen zu integrieren. Bei RPM haben sie ja auch getan.
"Denn hat man einfach die Pakete seiner Distribution benutzt, gab es praktisch keine Probleme. "
Hierzu nochmal:
Das ist in der Realität eben sehr schwer. Wer will schon nur nutzen was die Distrie bietet? Spätestens bei 3. Quellen wird es dann schwer. Während man dann meist 4-5 RPMs findet, gibts nur eine Debian Datei. Die ist dann gleich für alle Deb Distries geeignet. Es geht also, wenn man will.
Die RPM Distries haben sich an LSB festgehalten, und damit versucht ans Ziel zu kommen. Andere haben schlicht auf eine freie Distrie aufgenbaut. Ich persönlich empfinde aktuell den letzten Ansatz als aktuell erfolgreicher bei der Kompatibilität, und Vermeidung der Pakethölle.
Nein, haben sie nicht. Jedenfalls hat keine formale Einigung stattgefunden. Dass die Paketnamen von Debian beibehalten werden, liegt einfach daran, dass man Debians Vorarbeit nutzen will, und das könnte man nicht, wenn man sich zu sehr entfernt. Red Hat und SUSE haben aber in der Historie nichts miteinander zu tun.
Aber eben das haben die RPM Distries garnicht erst versucht.
Es sind Konkurrenten, die im Wettbewerb zueinander stehen. Sie sind auch auf Kundenbindung angewiesen.
Die Realität hat aber die enormen Nachteile gezeigt.
Welche? Man hätte als Distributor Pakete, die Bibliotheken enthalten, einfach nach ihnen benennen sollen. Mandriva macht das übrigens so.
Während man dann meist 4-5 RPMs findet, gibts nur eine Debian Datei. Die ist dann gleich für alle Deb Distries geeignet.
Ist sie nicht. Schau dich nur mal bei Opera um. Wenn man natürlich Qt etc. statisch linkt, wie das beim Skype-DEB der Fall ist, braucht man auch nur ein Paket.
Die RPM Distries haben sich an LSB festgehalten, und damit versucht ans Ziel zu kommen.
Die LSB hat nicht das Ziel, Pakete der Distributionen untereinander kompatibel zu machen! Das Ziel ist, dass Dritte (ISVs) nur ein Paket bereitstellen müssen, das unter allen LSB-konformen Distributionen funktioniert. Dabei darf das Paket nur in der LSB erwähnte Symbole verwenden und muss die übrige Funktionalität selbst mitbringen. VMware und Co. brauchen nur ein RPM-Paket für alle Distributionen.
Andere haben schlicht auf eine freie Distrie aufgenbaut.
Schon mal daran gedacht, dass die Entwicklungslinien von SUSE und Red Hat parallel zu Debian verlaufen und nicht erst später entstanden sind?
Nebenbei hat DEB noch den Nachteil, dass es keine Multi-Arch-Unterstützung gibt. Das erwähnte Skype-DEB lässt sich auf einem AMD64-Etch nicht installieren.
Mir ist es auch mit Anleitung nie gelungen, ein RPM zu bauen - irgendwelche "spec-files" editieren usw. usf.
Bei Debian geht das in 95% der Fälle so:
1. Quellcode entpacken.
2. dh_make --createorig
3. fakeroot debian/rules binary
fertiges Paket.
Aha. Daraus soll man was folgern ? Dass das unten nirgens dokumentiert ist ? Oder du es gar nie versucht hast ?
1. Quellcode in Folder SOURCES ..--^^ muss NICHT ausgepackt werden. Geschieht automatisch !
2. rpmdev-newspec myapp
3. Im Spec: Version Eintragen, Source0 Eintragen ..--^^ equivalent zum editieren der debian/rules
4. rpmbuild -bb myapp.spec ..--^^ dieser schritt Packt das tar.gz aus, ./configure, make, make install in fakeroot, dann auto requires / provides, und binary bauen
Ausser das dh_make Anforderungen ans (ausgepackte!!!) Tarball hat ( Paketname-Paketversion/... ) und sich damit dh_make den Schritt 2(@RPM) semiautomatisiert.
Das RPM-Paket ist zwar vorne und hinten nicht konform, aber es wird gebaut. In 3,5 Schritten mit RPM.
Das ist aber dein Deb auch nicht. Die Description / License etc... muss auch im rules angepasst werden (aber das hab ich mal aussenvorgelassen).
Komischerweise war die Anleitung, die ich zur Erzeugung von RPMs genutzt habe, nicht so einfach, wie Du sie beschreibst. Ich kam trotz Anleitung nicht zum Ziel, mit Debian schon. Das ist das einzige, worum es mir hier geht. Es sagt nicht, dass RPM "schlecht" ist.
Das geht meistens noch vieeeel Einfacher.
src.rpm des alten LYX organisieren, und auspacken.
Die neue LYX (das tar.gz) in den SOURCES Ordner kopieren
Im Spec die Version anpassen
rpmbuild -bb lyx.spec
Oder anders: Debian ist zum Packagen nicht (mehr*) Einfacher.
Gruss
*war früher wohl mal so (als noch keine spec helper scripts etc... vorhanden waren)
Dann aber bitte auf einen durchdachten Standard setzen und nicht auf was, was zwar vlt. weiterverbreitet aber technologisch rückständiger ist. Den Einsatz von ODF statt DOC(X) würde schließlich auch jeder befürworten.
Inwiefern ist RPM gegenüber DEB rückständig?
Es sind selten die Distributionen die Innovationen verhindern. Und jetzt komm nicht mit dem Argument, dass Lenny doch überhaupt kein KDE4 mitbringt.
Da kann mal wieder zw. Paketformat und Paketmanager nicht unterschieden werden.
Und das Thema "welches Format löst Abhängigkeiten besser auf" darf auch nicht fehlen.
Natürlich kommt keinem in den Sinn, daß man beim Paketbau (egal ob RPM oder DEB) Fehler machen kann, wodurch bei beiden Formaten und in den meisten Fällen Probleme beim Auflösen der Abhängikeiten entstehen können.
Außerdem gibt es dann noch die Spezialisten die einfach alles installieren, wenn nur rpm oder deb hinten dranstehnt. Noch schlimmer: Man wandelt per "alien" das Fremdpaket um. Und wundert sich dann, daß es Probleme im Paketsystem gibt...
Nun arbeite ich beruflich bedingt mit RPM. Ich erlaube mir also zu sagen: "ich kenne beide Systeme".
1. Deb haben genau gleich Abhängigkeitsprobleme wie RPM (Sofern die Requires nicht vorhanden sind, bzw. falsch sind).
Was aber ist: Bei Debian kam gleich mal ein apt-get mit, bei den anderen war mal up2date, mal yum, mal yast, whatever.
Alle die behaupten dass mit .deb (dem Paketformat) keine Dep-Hell möglich ist hat den Unterschied eines Paketformats zu einem Paketmanagement noch nicht begriffen.
2. Was für RPM Spricht: Man hat als Maintainer genau 1(!!) File das man pflegen muss. Das SPEC.
Bei Debian ist es ein ganzer Folder (`control' `copyright' `changelog' `rules' `conffiles' `dirs' `docs' `postinst' `preinst' `postrm' 'prerm`...pipapo)
3. rpm -V builtin, debsums ist ein separates package
Dann was Subjektives:
Ich (persönlich) find das bauen von rpm's viel Komfortabler als den Bau von deb's.
Was evt. nice wäre, wäre ein TAG wo man gewisse Distris Taggen könnte, die verhindern dass einer auf nem SuSe mit manuellem rpm -ivh es schafft ein Paket aufs System zu hauen, dass eigentlich für eine andere Distri gebaut wurde.
Ansonsten finde ich vor allem diese Neuerungen ganz Nett:
* %{_topdir} defaults to $(HOME)/rpmbuild/ now, instead of former
/usr/src/redhat/.
* Rpm enforces BuildRoot for all packages and ignores the directive in
spec.
* Dependencies for pkg-config and libtool files are automatically
generated by rpmbuild.
* rpmbuild automatically creates the build directory structure if necessary.
:)
Das Problem ist aber eben das apt schon da war, als SuSE und co. noch stark an ihren Tools gearbeitet haben, und diese eben langezeit ihre Arbeit auch nur sehr mittelmässig vollzogen haben. Nicht grundlos wurden sie inzwischen fast alle ausgewechselt.
Natürlich ist apt eine andere Stufe als rpm, aber bei RPM Distries war der Kontakt mit rpm direkt oft nötig und vorgesehen, aber bei Debian war und ist eben apt bzw. jetzt aptitute der immer gepredigte weg.
Ich habe lange Jahre RPM Distries genutzt, und bin selbst oft mit dem Problem in Berühung gekommen.
Man kann an dem Thema viel rumdiskutieren, aber es gibt eben den bekannten Begriff der RPM hell, aber niemand spricht von einer deb hell.
Im grunde ist daran nicht rpm schuld, aber die Distries haben eben lange gepennt, bis es so oft gekracht hat das man es nicht mehr überhören konnte
Nur löst apt(itude) die Probleme in aller Regel wesentlich intelligenter als yum, yast & co.
2. Was für RPM Spricht: Man hat als Maintainer genau 1(!!) File das man pflegen muss. Das SPEC.
Bei Debian ist es ein ganzer Folder (`control' `copyright' `changelog' `rules' `conffiles' `dirs' `docs' `postinst' `preinst' `postrm' 'prerm`...pipapo)
Richtig. Und das ist auch gut so. Informationen sind so sauber getrennt und nicht in einer Datei zusammengewürfelt. Frag mich ja eh, wer auf die Idee kommt, z.B. Paketabhängigkeiten, Installationsscripte und Buildregeln in eine Datei zu schmeißen - schaffen nur die RPM-Frickler... Oder packe ich als Programmierer etwa den Inhalt von configure.ac/Makefile.am/CMakeLists.txt/whatever in meine Quellcodedateien? Gerade die sauberer Trennung sehe ich als einen der größten Vorteile von DEB überhaupt und ich hoffe, dass das auch so bleibt. Auch die strikte Versionshistory mittels debian/changelog sorgt in der Regel für eine viel bewusstere Arbeit beim Paketieren, da alle Änderungen sauber zu dokumentieren sind (wenn auch nicht zwangsweise). Ich baue selber seit mehreren Jahren Debian-Pakete und bin froh, dass ich vor 2 Jahren nur mal kurz mit RPM-Paketierung zu tun hatte..
3. rpm -V builtin, debsums ist ein separates package
Auch hier wieder eine saubere Trennung der Lösung von Problemen. Klar, dem einen gefällt die Eier legende Wollmilchsau mit hunderten schwer-einprägbaren Parametern aber ich finde da den Ansatz "ein Programm für ein Problem" wesentlich übersichtlicher (oder hast du ein Gartengerät, was man immer erst umständlich zu einem Spaten, einer Harke, einem Laubbesen o.ä. umbauen muss?) und vorallem weniger fehlerträchtig bei der Verwendung - ein aus Versehen klein oder großgeschriebener Parameter macht nicht gleich was völlig anderes, als das, was ich will.
Frag mich ja eh, wer auf die Idee kommt, z.B. Paketabhängigkeiten, Installationsscripte und Buildregeln in eine Datei zu schmeißen
Nungut, ein Specfile spezifiziert wie ein RPM gebaut werden soll. Sogesehen hat es sehr wohl Sinn dahinter alles in einem File zu halten.
schaffen nur die RPM-Frickler
...Sagt viel über dein Niveau aus...
Debian halt :>
Auch die strikte Versionshistory mittels debian/changelog sorgt in der Regel für eine viel bewusstere Arbeit beim Paketieren
Stell dir vor, in den rpm spec's gibts genau eine solche. Boah.
Ich diskutiere gerne mit anderen. Solange Argumente kommen. Und nicht "Pha-Das-Ist-Frickelzeugs". Auf so ein Niveau gehe ich eigentlich nicht mehr ein (bin ich zulange dabei =).
Trotzdem schönen Abend.
Bei aller Geschmacksfrage stimme ich mit dem OP überein das eine saubere Trennung von Informationen und Funktionen ein wichtiger Grundstein indem insgesamt sauberer wirkendem DEB-System legen.
Für mich ist das Auftrennen in verschiedene Files vor allem eine Fehlerquelle. Das RPM-spec ist sauber gegliedert (Wie ein Buch, mit Titel, Einleitung, Kapitel und Anhang). Man editiert 1(!)File und hat auch ein Changelog in selbigen (im Prinzip der Anhang). Ich finde es unglückich, beim Packagen, mit einer IDE ein Projekt zu eröffnen um parallel >7 Files zu bearbeiten.
Logo, grundsätzlich ist es gut gewisse Dinge zu trennen. Bei so etwas trivialem wie einem spec File sehe ich aber mehr Nachteile als Vorteile.
Einerseits Geschmackssache, andererseits denke ich aber, dass viele .deb Packager sich noch NIE wirklich mit rpm packagen veschäftigt haben. Wieso auch... die Erde ist eine Scheibe und alles ausser Debian ist sowieso Mist. Mitunter ein Grund, dass ich Debian den Rücken zugekehrt habe. Zuviele Fanatiker, zuviele "Möchtegern-UberHacker",... und ein massiv Arroganter Umgangston mit anderen Linux-Community Mitgliedern.
Das liegt nicht an den Paketmanagern, sondern daran, dass die Paket-QS bei Debian wesentlich besser ist als bei allen anderen Distributionen. Upgrade-Probleme werden zu RC-Bugs, die Releases über Wochen/Monate hinauszögern. Bei anderen Distributionen sieht man da gerne mal drüber hinweg.
Fedora bspw. Released alle 6 Monate. Ob fertig oder nicht :-/
Ob das gut ist, sei dahingestellt. Für die welche mit solchen Distris (wie Fedora) auf Nummer sicher gehen wollen: Zuwarten mis ReleaseDate + 3 Monate und sich nen Respin besorgen mit Updates :)
Schön dass man die Wahl hat
So kommt es wahrscheinlich schon einmal vor, dass ausgerechnet in dem Moment, in dem eine Fedora endlich völlig reibungslos funktioniert, ihr "end of life" verkündet wird.
Dagegen ist OpenSuse mit 24 Monaten recht lang.
Debian bringt es dem gegenüber auf etwa (mehr oder weniger (un)geplante) 36 Monate.
Linuxnutzer haben natürlich unterschiedliche Prioritäten.
Ich wüßte jetzt aus dem Stehgreif auch nicht, welchen Fedora-Versionen im Hinblick auf die "Aktualität" der verwendeten Software Debian Etch und Lenny in etwa entsprechen würden.
Interessante Frage, dem bin ich mal nachgegangen:
Hab mal die glibc Versionen verglichen:
Fedora Core 4: 2.3.5
Debian Etch: 2.3.6
--
Fedora Core 5: 2.4
Fedora Core 6: 2.5
Fedora 7: 2.6.3
--
Debian Lenny/SID: 2.7
Fedora 8: 2.7
--
Fedora 9: 2.8
--
Debian Experimental: 2.9
Fedora 10: 2.9
--
Oder Kurz: F10 ist bei Debian Experimental, Etch entspricht FedoraCore4, und Lenny/SID (haben die selbe libc6) sind in etwa F8+
Fedora ist halt was Releases angeht genau das gegenteil von Debian
Die alte glibc in Etch (glibc 2.3.6) war übrigens "notwendig", um ein reibungsloses Update des Kernel 2.4-Sarge (glibc 2.3.2) nach Etch zu gewährleisten, sonst wäre es wenigstens glibc 2.4 geworden.
Aus diesem Grund enthält auch die letzte Kernel-2.4-Version von Slackware (Slackware 11.0) noch glibc 2.3.6 und eben nicht wenigstens glibc 2.4.
Glibc 2.4 und Kernel 2.4, das funktioniert leider nicht.
Und bei einem dist-upgrade wird die glibc gleich zu anfangs aktualisiert.
Ein Debian nicht problemlos auf die neue, folgende Version updaten zu können, ist für das Debian-Projekt ein schwerer Bug, der die Veröffentlichung um Monate verzögern kann. Lieber akzeptierte man damals die alte glibc in Etch.
Von der Software her entspricht Etch wohl eher Fedora Core 6, jedenfalls ähnelt die Softwarezusammenstellung von Etch (von der glibc einmal abgesehen) sehr RHEL 5.
Kann ich bestätigen. Hab mir mal die Xorg Version angeschaut.
FC6 == RHEL/CENTOS 5.x == Debian Etch
es geht um Weisswürste, Chickn und Burger
2) Fedora wird immer bis zum Erscheinen des übernächsten Nachfolgers unterstützt, also mehr als 24 Monate.
3) Wer wirklich mehr will kann CentOS nehmen und auf 7 Jahre Updates zählen.