On Thu, 2003-10-09 at 09:17, Michael Born wrote:

Hallo Ralf + Liste.

...

...

Leider brauchen die Sourcen neuere Versionen von automake/autoconf, als installiert sind - das ist doch witzich, oder?

Unfug.

Aktuell sind autoconf-2.57 und automake-1.7.8. * Zur Installation braucht autoconf-2.57 weder autoconf noch automake. * Automake-1.7.8 braucht zur Installation mindestens ein installiertes autoconf-2.54. ok, ok, es SOLLTE funktionieren. Leider bricht make bei autoconf-2.57 mit folgender Meldung ab :

Making all in doc make[1]: Wechsel in das Verzeichnis Verzeichnis »/home/tisa/temp/autoconf-2.57/doc« /bin/sh /home/tisa/temp/autoconf-2.57/config/missing --run makeinfo --no-split -I . \ -o autoconf.info `test -f 'autoconf.texi' || echo './'`autoconf.texi autoconf.texi:70: Unbekannter Befehl »copying«. autoconf.texi:94: Nicht übereinstimmendes »@end«. autoconf.texi:145: Unbekannter Befehl »insertcopying«. autoconf.texi:3802: Unbekannter Befehl »verbatim«. autoconf.texi:3817: Fehlplazierte {. autoconf.texi:3821: Fehlplazierte }. autoconf.texi:3823: Fehlerhaftes Argument zu »end«, »verbatim«, benutze »defmac«. autoconf.texi:3823: Nicht übereinstimmendes »@end«. autoconf.texi:4281: Unbekannter Befehl »verbatim«. autoconf.texi:4298: Fehlerhaftes Argument zu »end«, »verbatim«, benutze »defmac«. autoconf.texi:4298: Nicht übereinstimmendes »@end«. autoconf.texi:4519: Unbekannter Befehl »verbatim«. autoconf.texi:4526: Nicht übereinstimmendes »@end«. autoconf.texi:7739: Unbekannter Befehl »verbatim«. autoconf.texi:7747: Nicht übereinstimmendes »@end«. makeinfo: Entferne Ausgabe-Datei »autoconf.info« wegen der Fehler; --force benutzen, um diese beizubehalten. make[1]: *** [autoconf.info] Fehler 1 make[1]: Verlassen des Verzeichnisses Verzeichnis »/home/tisa/temp/autoconf-2.57/doc« make: *** [all-recursive] Fehler 1

Die "info" Sachen der Suse8.0 habe ich aber installiert ... Die Symptome sprechen für ein veraltetes texinfo. Vermutlich hast Du noch texinfo-4.0. IIRC, braucht autoconf-2.57 mindestens texinfo-4.2 (Bleeding Edge wäre 4.5!)

...

[Pssst: Nimm die SRC-RPMs von rawhide und übersetz sie oder die von einer neueren SuSE-Version.] Ich habe jetzt die von 8.2 genommen.

arthur:/usr/src/packages/SPECS # rpm -bb /usr/src/packages/SPECS/autoconf.spec line 19: Dependency tokens must begin with alpha-numeric, '_' or '/': PreReq: %{install_info_prereq}

Und wieder nix. So wie es aussieht, verwendet SuSE im diesem RPM spec wiedereinmal ein SuSE-spezifisches RPM-Macro, dass es in deiner SuSE-Version noch nicht gab (*kopfschüttel*).

Sehr wahrscheinlich wird es helfen dieses PreReq: %{install_info_prereq} durch PreReq: /sbin/install-info zu ersetzen.

Ich muß schon sagen ... Obwohl ich schon einige Jahre mit Linux arbeite bin ich doch erschüttert, wie schnell alles veraltert und wie schnell dann alles kompliziert wird. Ich bin ein bischen ENTTÄUSCHT. Kann ich nachvollziehen.

Was die Paketierung der Autotools anbetrifft lag unter SuSE-8.0 und SuSE-8.1 einiges im Argen (Du siehst gerade erst die Spitze des Eisberges ;) ) Über die Tatsache, dass sich SuSE als lernresistent gegenüber proprietären Konstrukten in SuSE's rpm-specs erweist, schweige ich mich an dieser Stelle besser aus ;)

Kann mir jemand sagen, was beim make von autoconf falsch läuft, oder wie ich das Erstellen der Doku abschalten kann?! Höchstwahrscheinlich ist dein texinfo veraltet.

Muß ich erst ein neueres rpm einspielen (mit rpm selbst?), um die srpm's von Suse8.2 übersetzen zu können? So wie es aussieht ja. Andererseits müsste es möglich sein, die Binär-RPMs von SuSE-8.2 auch unter SuSE-8.0 zu installieren.

Ralf

Hallo Ralf + Liste.

Am Donnerstag, 9. Oktober 2003 13:25 schrieb Ralf Corsepius:

...

...

Ich muß schon sagen ... Obwohl ich schon einige Jahre mit Linux arbeite bin ich doch erschüttert, wie schnell alles veraltert und wie schnell dann alles kompliziert wird. Ich bin ein bischen ENTTÄUSCHT.

Kann ich nachvollziehen.

Was die Paketierung der Autotools anbetrifft lag unter SuSE-8.0 und SuSE-8.1 einiges im Argen (Du siehst gerade erst die Spitze des Eisberges ;) )

Über die Tatsache, dass sich SuSE als lernresistent gegenüber proprietären Konstrukten in SuSE's rpm-specs erweist, schweige ich mich an dieser Stelle besser aus ;) Gibt es eine Linux Distribution, die sich hier standardkonform verhält (ich weiß nicht mal, ob es einen Standard gibt ...) ??? Einen wirklichen Standard gibt es nicht. Die Portabilitätsprobleme entstehen dadurch, dass Distributoren dazu übergegangen sind, rpm um

On Thu, 2003-10-09 at 16:09, Michael Born wrote: proprietäre Macros zu erweitern, anstatt mit "Vanilla-RPM" Bordmitteln zu arbeiten.

Ich würde doch gern auch Linux Systeme ein bischen länger betreiben ...

...

...

Muß ich erst ein neueres rpm einspielen (mit rpm selbst?), um die srpm's von Suse8.2 übersetzen zu können?

So wie es aussieht ja. Andererseits müsste es möglich sein, die Binär-RPMs von SuSE-8.2 auch unter SuSE-8.0 zu installieren. Ich habe jetzt Binärpakete von 8.2 mit "yast -i" eingespielt. Ich dachte wegen unterschiedlicher libc's bei 8.0 und 8.2 würde das garnicht funktionieren ... Autoconf und Automake sind architektur-unabhängig, und hängen somit nicht von der libc ab. Solange die Pfade nicht zwischen unterschiedlichen Distributionsversionen verändert wurden, sollte es deshalb eigentlich keine Probleme geben.

Ralf

Hallo Michael, hallo Leute, Am Donnerstag, 9. Oktober 2003 16:09 schrieb Michael Born:

[...] Ich habe jetzt Binärpakete von 8.2 mit "yast -i" eingespielt. Ich dachte wegen unterschiedlicher libc's bei 8.0 und 8.2 würde das garnicht funktionieren ...

Da es sich scheinbar noch nicht überall herumgesprochen hat: yast -i installiert _alles_ ohne Rücksicht auf Verluste. [1] Du hättest genausogut [2] rpm -U --force --nodeps verwenden können... Und dass --force und --nodeps nur in sehr seltenen Ausnahmefällen angebracht sind, sollte ja jedem klar sein. Funktioniert noch alles? Glück gehabt ;-) Ansonsten solltest Du schnellstmöglich wieder die alten Pakete installieren und, falls Du neue Pakete nutzen möchtest, diese per rpm --rebuild neu kompilieren. BTW: Ein Austauschen/Updaten von /usr/lib/rpm/suse_macros dürfte gefahrlos sein und manche Probleme mit den neuen specs beseitigen ;-) Gruß Christian Boltz [1] Das hab ich sogar mal demonstriert, siehe http://marc.theaimsgroup.com/?l=suse-linux&m=104794110703358&w=2 [2] besser: genauso schlecht -- Wünschenswert wäre es auch, wenn Umfragen vor jeder Bundestagswahl, ob die Erst- oder die Zweitstimme die wichtigere sei, wenigstens soviele richtige Ergebnisse zeitigten, als würde man die gleiche Anzahl Schimpansen befragen. ;) [Bernd Brodesser in suse-linux]

On Thu, 2003-10-09 at 17:10, Philipp Thomas wrote:

Ralf Corsepius [Thu, 09 Oct 2003 13:25:38 +0200]:

...

Über die Tatsache, dass sich SuSE als lernresistent gegenüber proprietären Konstrukten in SuSE's rpm-specs erweist, schweige ich mich an dieser Stelle besser aus ;)

Es gibt IMO keine vernünftigere Lösung.

Wenn eure Macros denn vernünftig durchdacht wären, könnte man sie als SuSE-proprietäre Lösung hinnehmen. Ich erinnere mich aber an Macros, die ins laufende System eingreifen, statt sich auf das momentan in Bearbeitung befindliche RPM zu beschränken.

Wenn wir keine Makros nehmen würden, müsste jeder unserer Maintainer den entsprechenden Code in die Specs einbauen, was zum Einen höchst fehleranfällig ist und zum Anderen einen deutlich erhöhten Wartungsaufwand bedeuten würde.

.. andererseits die Portabilität euerer RPMS auf andere Distributionen, bzw. wie im vorliegenden Fall offensichtlich geschehen, zwischen unterschiedlichen SuSE-Versionen auf Null reduziert, solange diese Macros nicht Bestandteil der rpm-Pakete anderer Distributoren sind.

Gerade als Programmierer sollte dir Kapselung ein Begriff sein :) Wohl wahr, doch das Stichwort "Proprietäre Insellösung" sollte ebenfalls bekannt sein ;)

Ich halte daher nach wie vor /usr/lib/rpm-lib/suse_macros für die beste Lösung, auch langfristig. Um es mal hart auszudrücken: Ich halte sie für einen fundamentalen Designfehler der SuSE-Distribution und für eine Insellösung innerhalb der Fa. SuSE.

Will man "halbwegs portable" RPMS bauen, bleibt kein Ausweg, als diese Macros nicht zu verwenden. Ralf

On Thu, 2003-10-09 at 19:35, Philipp Thomas wrote:

Ralf Corsepius [09 Okt 2003 19:09:48 +0200]:

...

Wenn eure Macros denn vernünftig durchdacht wären, könnte man sie als SuSE-proprietäre Lösung hinnehmen.

Die meisten sind es.

;) Da kann man anderer Meinung sein.

...

Ich erinnere mich aber an Macros, die ins laufende System eingreifen, statt sich auf das momentan in Bearbeitung befindliche RPM zu beschränken.

Sachen wie 'fillup_and_insserv' beziehen sich nunmal auf das laufende System. Schon mal RPMs als Nicht-root gebaut?

Es macht wirklich Spass, wenn das Bauen eines RPMS als Non-Root stirbt, weil mal SuSE's rpm mal wieder versucht, irgendwo etwas am System zu verbiegen.

...

.. andererseits die Portabilität euerer RPMS auf andere Distributionen, bzw. wie im vorliegenden Fall offensichtlich geschehen, zwischen unterschiedlichen SuSE-Versionen auf Null reduziert, solange diese Macros nicht Bestandteil der rpm-Pakete anderer Distributoren sind.

Warum sollte SUSE daran interessiert sein? Als kommerzielles Unternehmen ist die SUSE daran interessiert, mit dem kleinstmöglichen Aufwand das bestmögliche Ergebnis zu erzielen. Daher ist es vornehmlich unser Interesse, das Bauen von Paketen für unsere Maintainer möglichst einfach zu machen und die Gefahr von Fehlern möglichst klein zu halten.

Stellt sich die Frage, warum es praktisch alle anderen Distributoren schaffen, weitgehend ohne derartige Macros auszukommen ...

...

Wohl wahr, doch das Stichwort "Proprietäre Insellösung" sollte ebenfalls bekannt sein ;)

Ach, und das unterschiedliche Aufteilen von Paketen ist keine solche Insellösung? Doch. Nur ist *das* in der Regel kein wirkliches Problem.

...

Um es mal hart auszudrücken: Ich halte sie für einen fundamentalen Designfehler der SuSE-Distribution und für eine Insellösung innerhalb der Fa. SuSE.

Du musst auch nicht eine aus tausenden Paketen bestehende Distribution pflegen. Und? Ich sprach ja auch nicht von "Kleinigkeiten in einzelnen RPM-specs".

...

Will man "halbwegs portable" RPMS bauen, bleibt kein Ausweg, als diese Macros nicht zu verwenden.

Dich interessieren "halbwegs portable" Source-RPMs verständlicherweise, aber ich sehe nicht, warum sie auch im Interesse von SUSE sein sollten. Uns interessiert nunmal vorrangig nur die eigene Distribution. Wohlgemerkt bei Source-RPMS!

Neulich fragte jemand auf suse-linux-e warum SuSE bei Entwicklern so wenig Berücksichtigung finde. Ich denke, ein oder zwei wesentliche Punkte, die dazu beitragen, dürften hier offensichtlich geworden sein. Ralf

Hallo Philipp, hallo Ralf, hallo Leute, Am Freitag, 10. Oktober 2003 09:30 schrieb Philipp Thomas:

Ralf Corsepius [Fri, 10 Oct 2003]:

...

...

Sachen wie 'fillup_and_insserv' beziehen sich nunmal auf das laufende System.

Schon mal RPMs als Nicht-root gebaut?

Schon mal angesehen, *wo* das sitzt? fillup_and_insserv stehen im %post.

...

Es macht wirklich Spass, wenn das Bauen eines RPMS als Non-Root stirbt, weil mal SuSE's rpm mal wieder versucht, irgendwo etwas am System zu verbiegen.

Und jetzt verrate mir mal, wo beim bauen %post ausgeführt wird.

Es muss nicht unbedingt %post sein. Ich hatte z. B. mit Problemen zu kämpfen, als ich die Fontlinge in ein RPM verpacken wollte. Falls Du die Fontlinge nicht kennst: sie bestehen aus einigen Perl-Scripten, zwei Perl-Modulen, einigen PHP-Dateien, die nach $(prefix)/share/fontlinge/ installiert werden, und natürlich Doku. Die Installation erfolgt mit recht einfachen Makefiles sowie (bei den Perl-Modulen) einem per Makefile.PL und ExtUtils::MakeMaker generierten Makefile. Das spec und sonstige Dateien kannst Du gern im CVS angucken: http://sourceforge.net/projects/fontlinge http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/fontlinge/fontlinge_rc/ Hier ein Ausschnitt der Ausgabe von rpm -tb - als User "compile" ausgeführt, der Schreibrechte in /usr/src/packages/* hat und natürlich auch in /var/tmp/, getestet unter SuSE 8.2 und 7.3. + RPM_BUILD_ROOT=/var/tmp/fontlinge-2.0-buildroot + export RPM_BUILD_ROOT + test -x /usr/sbin/Check -a 505 = 0 -o -x /usr/sbin/Check -a '!' -z /var/tmp/fontlinge-2.0-buildroot + echo 'I call /usr/sbin/Check...' I call /usr/sbin/Check... + /usr/sbin/Check rm: Entfernen von »/usr/share/info/dir.bak.gz« nicht möglich: Keine Berechtigung gzip: /usr/share/info/dir.bak.gz: Permission denied -rw-r--r-- 1 root root 4073 2001-04-13 19:54 /usr/share/info/dir.bak.gz rm: Entfernen von »/usr/local/man/man1/saned.1.gz« nicht möglich: Keine Berechtigung gzip: /usr/local/man/man1/saned.1.gz: Permission denied -rw-r--r-- 1 root root 2393 2002-07-07 16:06 /usr/local/man/man1/saned.1.gz rm: Entfernen von »/usr/local/man/man1/scanimage.1.gz« nicht möglich: Keine Berechtigung gzip: /usr/local/man/man1/scanimage.1.gz: Permission denied [gleiches mit diversen anderen manpages in /usr/local] Wieso wurstelt dieses /usr/sbin/check in meinem System run, wenn ich innerhalb eines BUILD_ROOT arbeite??? (zum Glück habe ich das Paket nicht als root gepackt, sonst wäre ich vermutlich einige Manpages losgeworden :-( ) Inzwischen hat mir David die Zeile %define __os_install_post true empfohlen, damit läuft es jetzt.

...

...

Du musst auch nicht eine aus tausenden Paketen bestehende Distribution pflegen.

Und? Ich sprach ja auch nicht von "Kleinigkeiten in einzelnen RPM-specs".

Wenn du tausende von Paketen pflegen willst, *musst* du so viel wie möglich kapseln und zentralisieren, sonst wird das ziemlich unübersichtlich.

Aber es sollte IMHO immer noch so sein, dass ein "normales" spec immer funktioniert und nicht erst, nachdem man den ein oder anderen SuSE-Automatismus abgeschaltet hat... Vorschlag: SuSE könnte in allen specs eine einzelne Zeile einbauen, die diese Automatismen aufruft, z. B. %suse_rpm_postprocess Oder (vermutlich noch einfacher) in den specs per %define exec_suse_rpm_macros 1 eine Variable setzen setzen und die SuSE-eigenen Makros nur dann ausführen, wenn diese Variable gesetzt ist. Das wäre für SuSE ein IMHO vertretbarer Aufwand und würde den Bau von Paketen mit "normalen" Specs wesentlich erleichtern.

...

Neulich fragte jemand auf suse-linux-e warum SuSE bei Entwicklern so wenig Berücksichtigung finde.

Ich denke, ein oder zwei wesentliche Punkte, die dazu beitragen, dürften hier offensichtlich geworden sein.

*Kein* externer Entwickler muss auch nur eines der Makros benutzen, wo also liegt das Problem?

Das Problem liegt darin, dass einige Makros _zwangsweise_ ausgeführt werden, wenn man sie nicht explizit abschaltet. Und da ich vom RPM-Bauen recht wenig Ahnung habe und von Problemen dieser Art noch weniger, gäbe es immer noch kein funktionierendes spec für die Fontlinge, wenn mir nicht David [1] geholfen hätte. Ähm... wieso findet man eigentlich verhältnismäßig wenig RPMs, die für SuSE gepackt sind [2]? Ich könnte mir vorstellen, dass solche Probleme schon manchen Hobby-Programmierer davon abgehalten haben... Gruß Christian Boltz [1] von dem stammt auch das fontlinge.spec. Allerdings hat es ihn doch sehr verwundert, dass das RPM-basteln meine Manpages in /usr/local verwursteln will... (siehe auch meine sig) Inzwischen hab ich das spec ein wenig überarbeitet (und mich in die Grundlagen zum RPM-bauen eingelesen), aber sobald ich die Zeile %define __os_install_post true entferne oder auskommentiere, kommt wieder der obige Fehler. [2] von Packman mal abgesehen ;-) --

...

...

Liegt nicht an meinem .spec. Das sagt jeder ;-) Naja, aber ich zu Recht ;)) Sagt auch jeder ;-) *SCNR* [> David Haller und Christian Boltz in fontlinge-devel]

Ralf Corsepius [Sa, 11 Okt 2003 03:29:08 +0200]:

On Sat, 2003-10-11 at 01:39, Christian Boltz wrote: In diesem Fall wird versucht, alle Manpages und Infos zu gzip-en, was aber scheitern muss, da Du als User nicht die Rechte dazu hast.

Für SUSE ist das Verhalten OK, aber ich muss mal prüfen (nach meinem Urlaub), ob sich check nicht auf das BUILD_ROOT beschränken lässt.

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? Ich bitte dich! Aber ich will mal sehen, ob sich der Aufruf von Check nicht per sysconfig unterbinden lässt. Damit wären dann auch Leute wie du zufrieden gestellt, oder?

Hmm, SuSE hat (wie alle anderen RPM-basierten Distros) versucht diese Geschichten transparent in ihr rpm selbst einbauen (Genauer: in eine der /usr/lib/rpm/*macros Dateien).

Nicht nur. Teilweise werden auch zusätzliche Skripte verwendet, die aber auch in /usr/lib/rpm liegen.

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?

* Entwickler scheinen nicht zur Zielgruppe der SuSE-Distri zu gehören.

Was sich worauf begründet?

* Der SuS€-Aspekt.

Du meinst den Preis der Distribution?

* 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.

* 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. So kann ich nur sagen, dass dies nicht unbedingt ein Nachteil ist.

* Der "Aussen-Hui", "Innen-Pfui"-Aspekt.

In wie fern?

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*.

und sich deutlich vom Bedarf der Entwickler entfernt.

Welcher wäre? Philipp

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

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.