On Sat, 2003-10-11 at 14:59, Philipp Thomas wrote:
Ralf Corsepius
[Sa, 11 Okt 2003 03:29:08 +0200]: On Sat, 2003-10-11 at 01:39, Christian Boltz wrote:
Anderer Seiteneffekt dieses Problems: Hast Du ein Paket installiert, das aus irgentwelchen Gründen nicht-komprimierte Man/Info-Pages beinhaltet, werden diese komprimiert, sobald Du ein rpm als root übersetzt. Somit wird deine rpm-Datenbank inkonsistent zum Systemzustand.
Und das ist jetzt ein SUSE anzukreidender Fehler? IMNSHO, definitiv ja. Wenn ich ein RPM übersetze, hat sich RPM auf das momentane RPM zu beschränken und nicht im Hintergrund am System "herumzufummeln" und auf gar keinen Fall die rpm-Datenbank in Inkonsistenz zu bringen.
Andere Sachen (z.B. %{install_info_prereq}) würde ich als entsorgungswürdig bezeichnen.
Und warum? Du weist für alle Zukunft, welche Dateien für den Aufruf von install-info nötig sind?
PreReq: /sbin/install-info ist nur deshalb notwendig, da es lokal innerhalb des RPMS in %post/%preun Sections zur Registrierung der infos in $(prefix)/info/dirs benötigt wird. Wird /sbin/install-info aus dem System entfernt, scheitern auch die %post/%preun-Sections. Nun ist es zwar theoretisch denkbar, dass /sbin/install-info irgendwan mal durch ein anderes Tool abgelöst wird und es deshalb mal notwendig würde, /sbin/install-info dann im RPM-spec zu ersetzen. In diesem Fall wäre es notwendig, das RPM-spec zu editieren. Ein allgemeines, Distri-unabhängiges "%{install_info}"-Macro in RPM wäre dazu sinnvoll, doch ist es Fakt, das es dieses nicht gibt. An anderen Stellen gäbe es derartige Macros, doch sind einzelne davon unter SuSE leider nicht verwendbar (z.B. %configure).
* Entwickler scheinen nicht zur Zielgruppe der SuSE-Distri zu gehören.
Was sich worauf begründet? Das ist mein subjektiver Gesamt-Eindruck aus 8 oder 9 Jahren SuSE-Benutzung.
* Der SuS€-Aspekt.
Du meinst den Preis der Distribution? Nein, das wäre nur ein Detailaspekt davon.
Ich meine die Auswirkungen der kommerziellen Interessen der Fa. SuSE auf die SuSE-Distri und Interaktion eines einzelnen Users/Kunden mit der Fa. SuSE im Allgemeinen. Dazu gehören die ganzen soziologisch, politisch, wirtschaftlich u.ä. motivierten Aspekte, die u.a. hier immer wieder im Breite diskutiert werden (Marketing, Feedback, Produktgestaltung, Support, Fairness, Service, Preis/Leistung, Kooperationsbereitschaft, Technische Kompetenz, ROI/Rentabilität usw.) und die Motivation, die hinter Teilen von Debian steckt ("Freie Software", "Freie Entwickler", usw.). Die radikalste Ablehnungshaltung wäre die, die manche Debianer vertreten: "Freie Entwickler sollten $$/€€-Distris weder verwenden noch unterstützen".
* Von anderen Distributionen gibt es zumindest für Entwickler geeignete, zentrale, halb-offizielle Updates.
Mit welchem Vorteil? Wer sein System "bleeding edge" halten will, ist IMO mit keiner Distribution so richtig glücklich. Dem würde ich zustimmen, doch ...
Als Entwickler brauchst Du in der Regel eine stabile Basis und eine Auswahl von Paketen, die "neuer als auf der Distri" (Bleeding-Edge oder kurz davor) sind. Um die unmittelbar bearbeiteten Pakete wird man sich selbst kümmern. Auf mich bezogen, ich arbeite intensiv mit den Autotools, Binutils, GCC, Gdb, Gtk, Gnome, GL und einigen Nicht-Standard-Tools unter RH-9. Um meine SW mit neueren Versionen zu testen oder weil ich in den Versionen der Distri auf Bugs gestossen bin, bzw. ein Feature brauche, das erst in neueren Versionen verfügbar ist, greife ich oft zunächst auf Rawhide zu, da es dort die entsprechenden Pakete für RH-9 meist schon gibt. Es erspart mir in einer nicht unerheblichen Anzahl von Fällen den Aufwand eigene RPM erstellen zu müssen. Bei SuSE gibt es, von den supplementary-Paketen abgesehen, nichts Vergleichbares. Ein anderer Fall: Bugfixes. Als Entwickler arbeitet man oft sehr intensiv mit einzelnen Paketen und stößt dabei auf Bugs. Nun kann man diese Bugs an den Originalautor und/oder den Distri melden und auf baldige Behebung der Bugs hoffen. Der Weg über den Originalautor ist in der Regel langwierig und aufwändig. Der kürzere Weg wäre der über den Distri. Weder SuSE noch RH stellen Updates für "nicht Sicherheitsrelevante Bugs" bereit, jedoch stellte RH bisher derartige Fixes oftmals in kürzester Zeit über Rawhide zur Verfügung (PR in bugzilla.redhat.com -> Wenige Tage später "fixed in rawhide"). Meine dies bez. Erfahrungen mit SuSE sehen anderes aus (Mail an feedback@suse.com -> Keine Antwort).
* Die SuSE-Distri verwendet an vielen Stellen andere Konventionen als praktisch alle anderen Distibutionen.
Das hätte ich jetzt gerne mal möglichst genau spezifiert (wenn es dir nicht zuviel Mühe macht), um dazu dann detailliert Stellung nehmen zu können. Ein Beispiel für generelle Probleme wäre genau die Thematik, die wir in diesem Thread seit Tagen diskutieren (RPM-Spec-Konventionen).
Klassiker unter den generellen SuSE-spezifischen Problemen wären SuSE's Pfade (--prefix=/opt/[kde|gnome] vs. --prefix=/usr, die /var/* Konventionen, /usr/share/doc/packages usw. ), inserv und SuSEConfig. Weiterhin gibt es noch diverse paketspezifische Probleme, wie z.B. die Tatsache, dass es (IIRC) unter SuSE keine parallel installierten autotool-Versionen gibt (bzw. bis einschliesslich SuSE-8.1 nicht gab), und keine parallel installierten älteren GCCs (Beides gibt es bei RH). Daraus resultieren eine Reihe von Problemen bei der Installation von SW aus dritten Quellen.
So kann ich nur sagen, dass dies nicht unbedingt ein Nachteil ist. Auch wahr, man wird durch die SuSE-Konventionen z.B. auf versteckte Probleme mit Pfaden gestossen, die auf anderen Distris nicht auftreten da diese meist (insb. RedHat und Debian) alles unter /usr installieren.
* Der "Aussen-Hui", "Innen-Pfui"-Aspekt.
In wie fern? Manche Leute unterstellen SuSE "Bunte Haube, Murks darunter" und wenden sich deshalb von ihr ab. Soweit zu gehen, dies zu behaupten, würde ich nicht, doch mehr als einen Funken Wahrheit darin musste auch ich schon erfahren und kann es nachvollziehen, dass Leute diese Meinung vertreten.
Stark vereinfacht und verkürzt ausgedrückt, aus meiner Sicht ist die SuSE-Distri eine Win-Umsteiger/Home-*User*-Distri (Da hat sie eindeutige Vorteile gegenüber anderen)
Jetzt überlege bitte mal, welche potentielle Kundengruppe deutlich grösser ist und damit auch entsprechend deutlich mehr Umsatz verspricht und du wirst verstehen, warum Entwickler nicht die primäre Zielgruppe für ein kommerzielles Unternehmen sein *können*. Tja, die Sache ist doch eigentlich ganz banal: Die SuSE-Distri hat eine bestimmte Ausrichtung. Anwender haben bestimmte Bedürfnisse/Wünsche. Wenn sich eine hinreichende Schnittmenge finden lässt, kommt möglicherweise ein Geschäftsverhältnis zustande.
Beide Seiten haben die Freiheit ihre Entscheidungsgrundlagen selbst zu definieren, und ihre Konsequenzen daraus zu ziehen. SuSE tut es, ich tue es ;)
und sich deutlich vom Bedarf der Entwickler entfernt.
Welcher wäre? Der dürfte individuell sehr unterschiedlich sein ;)
Ralf