On Mon, 2003-10-13 at 20:48, Philipp Thomas wrote:
Ralf Corsepius
[Mo, 13 Okt 2003 07:51:12 +0200]:
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)? Probiers aus, ich erinnere mich nicht mehr an die Details, die Probleme waren aber augenscheinlich ;) [1]
IIRC, gab es 2 Probleme, einerseits irgendwelche falsch gesetzten Pfade, andererseits die configure --build=<target>/--host=<target> vs. configure <target> Kompatibilitätsproblem mit autoconf-2.13/2.5x.
Bei SuSE gibt es, von den supplementary-Paketen abgesehen, nichts Vergleichbares.
Aber wo willst du die Grenze ziehen?
IMHO gibt es keine, da jeder Anwendungsfall individuell verschieden ist. Zum einen gäbe es die reinen Bugfixes, die sich meist auf wenige isolierte Pakete auswirken, zum anderen sind es Paketgruppen (Gnome, KDE, perl, python o.ä.) die u.U. einen "Rattenschwanz" von Paketupdates nach sich ziehen. Die Kunst dabei besteht darin, sich sein System nicht zu zerschiessen.
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. Auch diese Tools sind nicht ohne ;)
Die potentiellen Probleme sind nur entweder "richtig brachial" (sofort offensichtlich) oder aber sehr subtil und schwierig zu finden.
Aber bei gtk+, glib etc. wird es schon schwierig. Ja, aber genau die sind die für mich interessanten, da sie sich anderes als die autotools/binutils/gcc/gdb nicht auf einzelne Pakete beschränken, sondern u.U. grosse Teile der Distri betreffen und ich es gerne vermeide, diese selbst übersetzen zu müssen (Hatte ich lange Zeit gemacht).
SUSE macht nunmal keinen öffentlichen Betatest, daher wird es sowas wie Rawhide auf absehbare Zeit nicht geben. Eure Entscheidung, für mich unverständlich, aber ein deutlicher Hinweis auf wenig Interesse an Entwicklern und Feedback.
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.
Nun, aus Anwendersicht ist ein Bug solange nicht gefixt, solange es keinen Bugfix-Update gibt, egal ob SuSE ihn intern behoben hat oder nicht. Umgekehrt kann ein Disti die subjektiven Auswirkungen eines Bugs nur schwer einschätzen. Soll heissen, was für SuSE als Marginale aussehen mag, kann für den einzelnen Anwender ein "ultimativer Showstopper" sein.
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? Weil es einfacher ist? Weil es Missverständnisse auf Userseite vermeidet?
und keine parallel installierten älteren GCCs (Beides gibt es bei RH).
Parallel installierte Versionen von GCC funktionieren nur bei unterschiedlichem Pfad. Jein, das C-Frontend lässt sich parallel mit gleichem Prefix installieren, das C++-Frontend braucht zusätzlich noch --enable-version-specific-runtime-libs, die anderen Frontends haben teilweise Probleme mit paralleler Installation.
Aber Du hast recht, parallele Installation mit unterschiedlichen Prefixes ist der einfachste Weg.
Dafür musst du dir deinen GCC aber eh selber kompilieren. Mach ich mit FSF-GCCs, aber nicht mit RH oder SuSE-GCCs ... ... dafür werdet Ihr ja bezahlt ;)
Und das RedHat parallel mehrere Compiler unterstützt, liegt wohl eher auf dem viel zu früh erfolgten Umschwenk auf egcs/gcc 2.96. Sicherlich auch ein Grund ...
... weitere Gründe wären schlechte SW, die mit neueren GCCs nicht zurechtkommt und die ABI-Änderungen in GCC. Ralf [1] Wir hatten dieses Problem vor einiger Zeit schonmal diskutiert.