On Sat, 2003-10-11 at 01:39, Christian Boltz wrote:
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. Auf eine derartige Mail hatte ich gewartet ... ;)
%post u.Co. sind kein Problem, es sind die %{suse_config*} Macros (Mangels SuSE kann ich jetzt nicht genau sagen welche) und einige der rpm-internen Macros in SuSE's RPM selbst ...
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??? Dieses Problem ist mir auch schon begegnet ;)
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. Damit Du als User unter SuSE rpms übersetzen kannst, müssen alle Man- und Info-Pages komprimert sein :-(=) 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.
(zum Glück habe ich das Paket nicht als root gepackt, sonst wäre ich vermutlich einige Manpages losgeworden :-( ) Nö, verloren gegangen wäre nichts, SuSE's rpm meint aufräumen zu müssen. SuSE's rpm weiss nichts davon, dass Du als User übersetzt, es will immer im System aufräumen :-)
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
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). Was Du siehst ist schlichtweg ein Bug. Allerdings gibt es SuSE-Macros, die sich nicht so ohne weiteres transparent kapseln lassen z.B. alle SuSEConfig-Geschichten, insserv u.ä. Andere Sachen (z.B. %{install_info_prereq}) würde ich als entsorgungswürdig bezeichnen.
Ä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...
Eine kleine, subjektive Auswahl von Gründen: * Die vergleichsweise geringe Verbreitung der SuSE-Distri ausserhalb Deutschlands. Die weitaus meisten dürften Debian oder RH verwenden. * Entwickler scheinen nicht zur Zielgruppe der SuSE-Distri zu gehören. * Der SuS€-Aspekt. * Von anderen Distributionen gibt es zumindest für Entwickler geeignete, zentrale, halb-offizielle Updates. * Die SuSE-Distri verwendet an vielen Stellen andere Konventionen als praktisch alle anderen Distibutionen. * Der "Aussen-Hui", "Innen-Pfui"-Aspekt. Nicht falsch verstehen, ich will hier kein SuSE-Bashing betreiben, doch die Frage lässt sich nur mit negativen Antworten beantworten ;) Meine subjektive Erfahrung ist jedoch die, dass es sich unter RH wesentlich leichter Entwickeln lässt wie unter SuSE. 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) und sich deutlich vom Bedarf der Entwickler entfernt.
[2] von Packman mal abgesehen ;-) Es gibt schon noch einiges ausser Packman, so ist es nicht, doch kein Vergleich zu dem was es für andere Distris "fertig" gibt.
Ralf