Ralf Corsepius
Wenn eure Macros denn vernünftig durchdacht wären, könnte man sie als SuSE-proprietäre Lösung hinnehmen.
Die meisten sind es.
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.
.. 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. Kompatibilität zu anderen Distributionen ist daher, zumindest für Source-RPMs, nicht von interesse.
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?
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.
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! Philipp