Ralf Corsepius
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.
Ach, du meinst das während des Bauens aufgerufene Check? Ja, da würde ich dir im Prinzip Recht geben. Und ich schrieb ja bereits, dass ich nach meinem Urlaub mal prüfen werde, ob sich das Verhalten evtl. ändern lässt.
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.
Und das PreReq stellt sicher, dass install-info installiert werden muss, *bevor* das betreffende Paket installiert wird.
Ein allgemeines, Distri-unabhängiges "%{install_info}"-Macro in RPM wäre dazu sinnvoll, doch ist es Fakt, das es dieses nicht gibt.
Dazu müsste man es erst einmal in RPM hineinkriegen, was nicht ganz einfach sein dürfte.
An anderen Stellen gäbe es derartige Macros, doch sind einzelne davon unter SuSE leider nicht verwendbar (z.B. %configure).
Wieso ist %configure nicht verwendbar (ich habe es bisher nie verwendet)?
Die radikalste Ablehnungshaltung wäre die, die manche Debianer vertreten: "Freie Entwickler sollten $$/-Distris weder verwenden noch unterstützen".
Fragt sich dann, wo ein guter Teil der Entwickler freier Software arbeiten würde, wenn es keine kommerziellen Distributoren mehr gäbe. Aber das steht auch einem anderen Blatt.
Bei SuSE gibt es, von den supplementary-Paketen abgesehen, nichts Vergleichbares.
Aber wo willst du die Grenze ziehen? Bei reinen Entwicklertools wie den autotools, gdb, binutils und gcc würde ich dir noch zustimmen und sähe keinen Grund, diese Pakete nicht über /pub/projects zur Verfügung zu stellen. Aber bei gtk+, glib etc. wird es schon schwierig. SUSE macht nunmal keinen öffentlichen Betatest, daher wird es sowas wie Rawhide auf absehbare Zeit nicht geben.
Meine dies bez. Erfahrungen mit SuSE sehen anderes aus (Mail an feedback@suse.com -> Keine Antwort).
Ja, nicht immer gibt es Feedback, wenn der Bug wirklich gefixt wurde. Das ist ein bedauerlicher Zustand, aber nicht ganz vermeidbar.
Klassiker unter den generellen SuSE-spezifischen Problemen wären SuSE's Pfade (--prefix=/opt/[kde|gnome] vs. --prefix=/usr, die /var/* Konventionen,
Warum sollten wir /usr/bin zumüllen? Nur weil andere es auch machen?
inserv und SuSEConfig.
Was ist gegen insserv zu sagen? Verwende doch /usr/lib/lsb/install-initd und gut ist. Letzterer ist von LSB vorgeschrieben, also wo ist das Problem?
und keine parallel installierten älteren GCCs (Beides gibt es bei RH).
Parallel installierte Versionen von GCC funktionieren nur bei unterschiedlichem Pfad. Dafür musst du dir deinen GCC aber eh selber kompilieren. Und das RedHat parallel mehrere Compiler unterstützt, liegt wohl eher auf dem viel zu früh erfolgten Umschwenk auf egcs/gcc 2.96.
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.
Soweit stimme ich dir zu :) Die Frage ist nur: rechtfertigt der zu erwartende Umsatz das mehr an Arbeitsaufwand?
SuSE tut es, ich tue es ;)
Eben :) Philipp