* Thomas Hertweck schrieb:

Ekkard Gerlach wrote:

...

habe das e2fsprogs von 7.2 gegen das aktuellere ausgetauscht. Das neuere ist kein rpm und yast meint bei jeder Installation das alte e2fsprogs.rpm nachinstallieren zu müssen. Wie kann ich yast dauerhaft klarmachen, daß er das "Fehlen" dieses rpm nicht mehr anzeigt ?

Beim Installieren "checkinstall" (./configure, make, checkinstall) verwenden, dann bleibt die RPM Datenbank konsistent. Checkinstall bastelt ein RPM und installiert es dann im System. Erfahrene Linux-

Muß dazu das alte rpm sozusagen als "Vorbild" noch installiert sein? Oder muß ich das alte rpm vorher löschen ? Muß nach der Installation des neuen Paketes das alte rpm gelöscht werden ?

User bauen sich ihr eigenes RPM - wer sich damit nicht so auskennt, fuer den ist Checkinstall sehr hilfreich. .. habe auch vor mir das mal anzusehen ...

Gruss Ekkard

On Mon, 16 Dec 2002 05:34:05 +0100 David Haller wrote:

- das make install (das checkinstall per default aufruft) installiert direkt ins laufende System (aber protokolliert eben mit). Das hat [..]

Ja, es _ist_ oft muehsam, selber ein RPM zu erstellen (aber es gibt ja Vorlagen, und das rudimentaere was checkinstall macht, _das_ laesst sich fast ebenso schnell selber und besser machen[2]). [..] [2] primaer z.B., dass make install eben _nicht_ ins laufende System installiert, dazu dann ggfs. noch Provides/Obsoletes ergaenzen, dann noch ein find $RPM_BUILD_ROOT | sed ... (scripts dazu "kursieren", z.B. ne Variante von mir[3])... Der Hauptaufwand der dann noch bleibt sind die paar Eintraege in der "Praeambel" des .specs. Ansonsten ist so ein spec Schema f:

Magst Du das mal näher erläutern? Soweit ich rpm kenne, führt ein rpm-build wie auch ein srpm-build _immer_ über eine Installation alias "make install". Zumindest verstehe ich die Beschreibung unter rpm --help so. Gruß, Tobias.

Am Montag, 16. Dezember 2002 09:28 schrieb Ralf Corsepius:

Ein rpm -b* führt über ein %install im rpm-spec. Was diese %install bewirkt liegt im Ermessen des Schreibers des rpm-specs.

Naja, erst wird compiliert, dann installiert, demzufolge werden %prep und %build natürlich auch benötigt.

Typischerweise wirst Du in %install ein make DESTDIR=$RPM_BUILD_ROOT install finden.

Das ist etwas völlig anderes als ein blankes make install

Richtig! Das hat mitunter den Vorteil, dass man dafür keine root-Rechte benötigt (Ausnahmen betätigen die Regel). Würde der build oder install Prozess also schieflaufen, ist das System nicht direkt gefährdet. Fehler im Makefile sind ja nun nicht 100% auszuschliessen. Die Installation des RPMs, für die dann wieder root-Rechte benötigt werden, ist dann eigentlich auch ungefährlich, da nur die Dateien aus dem RPM in die entsprechenden Verzeichnisse kopiert werden. Es sei denn, die %post, %postrun oder %pre bzw. %prerun Sektionen sind gefüllt, dort können auch beliebige Programme oder scripts ausgeführt werden, ein RPM das die Platte formatiert ist also durchaus denkbar. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de

On 16 Dec 2002 09:28:59 +0100 Ralf Corsepius :

Am Mon, 2002-12-16 um 08.43 schrieb Tobias Crefeld:

...

On Mon, 16 Dec 2002 05:34:05 +0100 David Haller

...

...

- das make install (das checkinstall per default aufruft) installiert direkt ins laufende System (aber protokolliert eben mit). Das hat [..]

...

Ja, es _ist_ oft muehsam, selber ein RPM zu erstellen (aber es gibt ja Vorlagen, und das rudimentaere was checkinstall macht, _das_ laesst sich fast ebenso schnell selber und besser machen[2]). [..] [2] primaer z.B., dass make install eben _nicht_ ins laufende System installiert, dazu dann ggfs. noch Provides/Obsoletes ergaenzen, dann noch ein find $RPM_BUILD_ROOT | sed ... (scripts dazu"kursieren", z.B. ne Variante von mir[3])... Der Hauptaufwand der dann noch bleibt sind die paar Eintraege in der "Praeambel" des.specs. Ansonsten ist so ein spec Schema f:

Magst Du das mal näher erläutern? Soweit ich rpm kenne, führt ein rpm-build wie auch ein srpm-build _immer_ über eine Installation alias"make install".

Nein.

Ein rpm -b* führt über ein %install im rpm-spec. Was diese %install bewirkt liegt im Ermessen des Schreibers des rpm-specs. [Erläuterung über fake-installation]

Falscher Fokus, ich dachte, es geht um das Installieren von funktionierenden Archiven an für sich und nicht darum, noch fehlerhafte tarballs oder specs oder fehlende Build-Anleitungen einzukalkulieren. Ansonsten: Wenn es da was besonderes außer configure;make;make install gibt, dann muß ich das halt beachten und das geht ja auch mit checkinstall und Konsorten, wenn man es denn will. Kompromiß kann ja auch der default der local-Installation sein. Ne raffinöse Konfigurationsbearbeitung bekommst Du damit nicht hin, aber wer braucht das schon für den Eigenbedarf. Das man etwaige spezialisierte rpm-Installationsscripte wieder erstmal testen muß, ist naheliegend, aber wenn diese nur Standard, da Automaten-Output sind, dann gibts auch nichts zu testen. Ab da beschränkt sich der Sinn und Zweck von Fakeinstallation eher auf RPM-Bäckereien. IMHO. Gruß, Tobias.

Am Mon, 2002-12-16 um 09.07 schrieb Thomas Hertweck:

Moin moin!

David Haller wrote:

...

[...]

Fazit (fuer mich, noch vor der Installation):

rm -rf checkinstall-*

Ja, es _ist_ oft muehsam, selber ein RPM zu erstellen (aber es gibt ja Vorlagen, und das rudimentaere was checkinstall macht, _das_ laesst sich fast ebenso schnell selber und besser machen[2]).

Hmm, also um ehrlich zu sein, da muss ich Dir widersprechen! Und dem muss ich nun widersprechen.

Ich finde, checkinstall ist ein sehr hilfreiches Tool, was es eben auch dem nicht so versierten Anwender erlaubt, seine RPM Datenbank konsistent zu halten. Nein, es ist ein Tool, dass es versierten Anwendern erlaubt in vereinfachter Weise rpms zu erstellen.

Für weniger versierte User ist es ein nahezu todsicherer Weg auf Dauer das System zu vernichten. Ich rate Anfängern dringend von checkinstall ab. Ralf

Am Mon, 2002-12-16 um 09.38 schrieb Thomas Hertweck:

Ralf Corsepius wrote:

...

Und dem muss ich nun widersprechen.

Darfst Du gerne, es kann ja jeder seine Meinung haben ;-) So sollte es auch sein ;)

...

[...checkinstall...] Nein, es ist ein Tool, dass es versierten Anwendern erlaubt in vereinfachter Weise rpms zu erstellen.

Für weniger versierte User ist es ein nahezu todsicherer Weg auf Dauer das System zu vernichten.

Ich rate Anfängern dringend von checkinstall ab.

Komisch, ich setze es jetzt schon eine recht lange Zeit ein und hatte nie Probleme - und das, obwohl ich vom Erstellen von RPMs nicht besonders viel Ahnung habe.

Was wohl daran liegt, dass Du eben _kein_ Anfänger bist ;)

Insofern kann ich die Argumentation von Dir und David nicht nachvollziehen. Mag sein, dass ihr in gewisser Weise recht habt, aber meine Erfahrung lehrt mich eben etwas Anderes. Das Hauptproblem an checkinstall:

Es suggeriert eine Sicherheit beim Erstellen von RPMs, die es in Wirklichkeit nicht bietet. So wird z.B. in keinster Weise sichergestellt, dass * in das generierte RPM die korrekten Abhängigkeiten eingeflochten werden (Welche minimale glib2 benötigte pango-1.1.5 nochmal?). * korrekte configure-Optionen verwendet werden (z.B. --sysconfdir=.., --prefix=/opt/gnome oder --prefix=/usr oder --prefix=/usr/local) * init.d/sysconfig/SuSEconfig Scripte nicht verloren gehen. * benötigte post|pre-install/uninstall-Scripte verwendet werden. * das laufende System ge-/stört nicht wird (z.B. Dateien in /etc/* nicht überschrieben werden) * Paketaufteilungen erhalten bleiben (SuSE installiert paket.rpm + paket-devel.rpm, dein checkinstall generiert paket.rpm, paket-devel geht verloren und führt zu Abhängigkeitsproblemen) usw. usf. D.h. aus meiner Sicht bewegt sich checkinstall mehr oder weniger auf dem Sicherheitsniveau eines blanken make install als Root, mit dem Unterschied, dass mittels checkinstall installierte RPMs in vielen Fällen wieder deinstalliert und dadurch gestörte Installationen restauriert werden können. Da das Schreiben eines einfachen RPM.specs auch nicht wesentlich schwieriger als checkinstall ist (David hat ein nettes Skelett gepostet), aber in der Regel ein wenig Nachdenken erfordert, das Bauen von rpms auch als normaler User erfolgen kann, sehe ich kaum Vorteile von checkinstall. Ralf

Henning Hucke wrote:

*** Thomas Hertweck (Thomas.Hertweck@gpi.uni-karlsruhe.de) schrieb in...:

...

[...] Das Erstellen eigener RPMs wollte ich immer schon mal lernen, aber leider fehlt mir die Zeit, mich mal intensiv mit dem Ma- ximum-RPM-Handbuch zu beschaeftigen. Und sooo einfach, wie Du das nun darstellst, ist es auch wieder nicht mit dem Erstellen.

Hmpf...

Und hier liebe Leute seht Ihr ein Beispiel für self fullfilling prophecy und für die Mähr, dass Unixe schwierig seien.

- Weil Thomas denkt, rpm sei schwierig zu lernen, setzt er sich garnicht erst hin und erzählt statt dessen den Leuten (direkt oder indirekt), dass rpm schwierig sei (ohne dass er das überprüft hätte) und

Aha, Du weisst also darueber Bescheid, was ich schon alles gelernt habe und was nicht. Erstaunlich! Du versuchst da Dinge zwischen den Zeilen zu lesen, die da nicht stehen, und das finde ich reichlich unverschaemt! Ich habe mich mit RPM durchaus beschaeftigt und dann eben festgestellt, dass es nicht so einfach ist. Und, da ich mich mit Linux doch vielleicht ein wenig besser auskenne wie mancher An- faenger oder Umsteiger, erlaube ich mir, eine Ein- schaetzung abzugeben. Und hier, liebe Leute, seht Ihr ein Beispiel fuer jemanden, der eigentlich nichts zu sagen hat, sondern die Meinung von anderen nicht akzeptieren kann und deswegen darueber her- zieht. Ich finde das nicht schoen. Man sollte auch offen fuer die Meinung von anderen sein.

- wenn er mit der Einstellung dran geht, es sei schwierig, wird er natürlich erst ein ganzes Buch durchlesen, bis er sich dran traut und dann wird er erst recht verbreiten, dass es schwierig ist, denn er mußte dafür ja ein ganzes Buch lesen...

Wenn man wirklich korrekte RPMs erstellen will, dann kommt man um das Lesen des Buches einfach nicht herum. Wenn man nur mal drin stoebert, dann mag man in der Lage sein, RPMs zu erstellen, aber ob die dann regelkonform sind steht in einem anderen Zusammenhang. Ist die Verbreitung oder Nutzung dieser nicht konformen RPMs dann besser? IMHO nein. Um das Ganze zu verstehen, muss man sich mit dem Umfeld und den ganzen Moeglichkeiten von RPM auskennen und dazu muss man alles lesen. Sonst passiert es eben, wie auch David schon schrieb, dass man im Internet zahlreiche "beschissen ge- packte RPMs" findet.

Nicht, dass ich damit schreiben wollte, dass nichts wirklich schwierig sei. Vielmehr kann man das schlecht be_urteilen_, wenn man sich noch nicht damit beschäftigt hat. _Wenn_ man sich erstmal ein wenig eingearbeitet hat, _kann_ sich herausstellen, das etwas schwierig ist und die Feinheiten und Tricks lernt man eh erst mit der Zeit...

Und nun sag mir mal, wo steht, dass ich nicht versucht habe, mich einzuarbeiten. Ich gebe in der Regel nur Kommentare zu Dingen ab, wovon ich auch ein wenig Ahnung habe, sonst bin ich naemlich lieber ruhig. Du versuchst da Dinge in meinen Text zu interpretieren, der so einfach nicht stimmt. Also halte Dich in Zukunft bitte damit zurueck oder frage mich direkt, wenn Dir was am Herzen liegt.

Tatsache ist, dass ich mein erstes funktionierendes RPM nach drei Stunden spielerei mit RPM gebacken habe. Und dabei bin ich auch noch extra vorsichtig vorgegangen, um mir jahnichts zu zerschießen.

Und wer sagt Dir, dass es ein korrektes RPM war?

Und wenn man heutzutage noch nichtmal mehr an einem beliebigen Abend drei Stunden erübrigen kann, stimmt entweder mit dem entsprechenden Arbeitnehmer/Studenten (?) oder mit unserer Arbeitskultur etwas nichtmehr.

Es gibt Leute, die haben neben Linux noch andere Hobbies und verbringen nicht die ganze Zeit vor dem Rechner. Oder sie ha- ben, nachdem sie den ganzen Tag vor dem Rechner verbracht ha- ben, schlicht abends keine Lust mehr. Wenn ich es brauche, dann kann ich fuer das Lesen sicherlich Zeit eruebrigen, wenn Checkinstall fuer mich die Aufgabe erledigt in einer Art und Weise, mit der ich zufrieden bin, dann ist das fuer mich OK und ich brauche mich nicht detaillierter einzuarbeiten. C'est la vie - Du kannst Dich gerne Tag und Nacht mit Deinem Rechner beschaeftigen, ich tue das nicht.

...

[...], aber fuer mich hat eben auch diese Software ihre Daseinsberechtigung und kann gerade fuer jemanden, der "nur mal eben schnell etwas installieren moechte"(tm) eine gute Hilfe sein.

Und bei solchen Formulierungen kommt mir das kalte und gruselige Kribbeln unter die Haut. Was ich schon an Systemen, Firewalls und Netzwerken gesehen habe, "die nur mal eben schnell" installiert, modifiziert oder aufgesetzt worden sind, bringt mich jedesmal dazu, nachhause telefonieren zu wollen und meine Mit-Aliens bitten zu wollen, "mal eben" eine Novabombe auf die Erde zu werfen...

Du leidest irgendwie an Arroganz, stelle ich fest. Es geht hier nicht um die Konfiguration von Firewalls etc., es geht darum, mal schnell die Software xyz zum Testen installieren zu koennen. Oder eben seine RPM Datenbank konsisten zu halten. Du ver- gleichst da Aepfel mit Birnen. Bi Firewalls ist sicherlich eine ganz andere Perfektion gefragt.

Das hat wenig mit "Perfektionsdrang" oder "Monaten von Arbeit" zu tun, sondern damit, dass man sich vorher schlicht und einfach mal ein paar Stunden mit solchen Themen beschäftigen sollte. Oft genug stellt man fest, dass der Aufwand bei weitem nicht so groß ist, wie man meint und der Vorteil, ein paar Stunden, Tage oder Wochen investiert zu haben, die Nachteile dann deutlich überwiegt; oder man stellt _dadurch_ erst fest, dass monate- oder gar jahrelang diverse Scheunentore offen standen...

Natuerlich bildet lesen weiter, das steht ausser Frage. Die Frage ist aber immer, ob es den Aufwand wert ist. Bevor ich hier eine Frage in der Liste stellen wuerde zu dem Thema, wuerde ich sicher versuchen, mich da detaillierter einzuarbeiten. Aber das halte ich eben momentan fuer nicht noetig. Ich verstehe nicht, warum Du die- se Meinung nicht akzeptieren kannst. Genauso gut kann man sagen, Du solltest das Programmieren des Linux-Kernels lernen - da stehen bestimmt auch Scheunentore offen, und wenn man sich damit befasst, ist es auch nicht so schwer. Und stell Dir vor, dann kannst Du Deine eigenen Hardwaretreiber programmieren - ist das nicht toll? Ja schon, aber ist es den Aufwand wert? Das kannst Du nur selbst entscheiden. Gruesse, Thomson *der es mal wieder bescheuert findet, wie hier aus einer harm- losen und IMHO durchaus sinnvollen Diskussion ueber Vor- und Nachteile einer Software eine persoenliche Sache wird* -- Thomas Hertweck, Geophysicist Geophysical Institute, Karlsruhe University (TH)

Hallo, On Mon, 16 Dec 2002, Thomas Hertweck wrote:

David Haller wrote:

...

[...]

Fazit (fuer mich, noch vor der Installation):

rm -rf checkinstall-*

Ja, es _ist_ oft muehsam, selber ein RPM zu erstellen (aber es gibt ja Vorlagen, und das rudimentaere was checkinstall macht, _das_ laesst sich fast ebenso schnell selber und besser machen[2]).

Hmm, also um ehrlich zu sein, da muss ich Dir widersprechen! Ich finde, checkinstall ist ein sehr hilfreiches Tool, was es eben auch dem nicht so versierten Anwender erlaubt, seine RPM Datenbank konsistent zu halten. Und wenn man einige Dinge be- achtet (u.a. das von Dir dargelegte Verhalten von checkinstall), dann kann man damit sehr gut zurecht kommen. Aber die Regeln zum Beachten diverser Dinge gelten ja prinzipiell bei jeder Software. Ich habe bisher jedenfalls nur positive Erfahrungen mit checkinstall gemacht.

Das meiste wurde schon geschrieben... Der Punkt ist, checkinstall suggeriert eine Einfachheit, die es nicht gibt. Fuer dich, der du dich IIRC generell etwas mit kompilieren auskennst, mag checkinstall sinnvoll sein. Fuer einen Anfaenger, der schon dran scheitert gcc und -devel Pakete nachzuinstallieren ist es IMO eher gefaehrlich (weniger dabei was es macht, als dabei was es vorgibt zu koennen / suggeriert). Solange die Software sich "sauber" installiert und nicht von anderer SW benoetigt wird (z.B. ein Programm und keine lib), solange _kann_ es gut gehen -- kommen dann aber libs wie z.B. von kde oder gnome/gtk ins Spiel wird's kritisch. Und dann wird die "Einfachheit" von checkinstall zum Bumerang. Extrembeispiel waere z.B. die glibc. Wuerdest du die mit checkinstall installieren wollen, dann wuerdest du, wenn du dich gut mit Linux auskennst, kurz nach dem Aufruf die Rettungs-CD raussuchen duerfen, wenn du Anfaenger bist, muesstest du wohl neu installieren... [..]

Ja, das liest sich fuer einen "normalen" Anwender ungefaehr wie chinesisch ;-) Sicher hast Du recht, dass das Erstellen eigener RPMs mit "korrekten" Eintraegen besser ist als das Benutzen von checkinstall, aber fuer mich hat eben auch diese Software ihre Daseinsberechtigung und kann gerade fuer jemanden, der "nur mal eben schnell etwas installieren moechte"(tm) eine gute Hilfe sein.

Das, was checkinstall macht _ist_ einfach. Dazu musst du nicht das RPM-Book kennen. Du kannst dir z.B. auch einfach die Vorlage, die checkinstall verwendet schnappen. Ein Beispiel eines solchen minimal RPMs hat auch Manfred geschrieben. Das RPM-Book und make musst du dann kennen, wenn checkinstall ebenso versagen wuerde, und dann ist checkinstall sowieso nicht zu empfehlen. Ich halte es jedenfalls fuer nicht gut, immer 'checkinstall' zu empfehlen... -dnh -- 39: EBCDIC an american data encryption standard (nach terra)

Hallo, On Mon, 16 Dec 2002, Thomas Hertweck wrote:

David Haller wrote:

...

[...] Das meiste wurde schon geschrieben... Der Punkt ist, checkinstall suggeriert eine Einfachheit, die es nicht gibt. Fuer dich, der du dich IIRC generell etwas mit kompilieren auskennst, mag checkinstall sinnvoll sein. Fuer einen Anfaenger, der schon dran scheitert gcc und -devel Pakete nachzuinstallieren ist es IMO eher gefaehrlich (weniger dabei was es macht, als dabei was es vorgibt zu koennen / suggeriert).

OK, vielen Dank fuer die ganzen Ausfuehrungen, auch an Ralf und Manfred, ich blicke nun ein bisschen mehr durch :-) Si- cherlich habt ihr da recht. Nur, die Frage bleibt, was soll dann ein Anfaenger machen? Frueher oder spaeter wird er si- cher Software compilieren, und dabei sicherlich erst mal keine eigenen RPMs bauen, zumal ja (wie David das oben so schoen ausgefuehrt hat) manche schon am gcc oder den Devel- Paketen scheitern. Ist es da nun besser, dass er ein einfa- ches "make install" macht oder "checkinstall" benutzt?

IMO weder noch. Sondern mit kleinen, einfachen und unkritischen(!) Programmen/RPMs experimentieren. Und IMO braucht man einfach ein gewisses Grundlagenwissen ueber make und rpm. Wer diese Voraussetzungen nicht erfuellt, sollte lieber die Finger davon lassen. Ja, natuerlich, ich hab auch irgendwann mal angefangen mit selbst- kompilieren und RPMs erstellen -- und ich habe fuer meine Fehler bezahlt. Ich habe mehrfach gnadenlos mit 'rpm -e' eigene RPMs wieder deinstalliert und dafuer wieder die von meinen SuSE 6.2 CDs installiert. Und ich hatte damals schon einiges an Erfahrung damit "andere" RPMs zu installieren, z.B. welche von SuSE 6.4 oder RH oder so. Uebrigens: Es gibt immer noch gewisse Inkonsistenzen in meinem System, die ich mir damals eingehandelt habe -- ich weiss halt aber welche das sind und wie ich damit umgehen kann/muss. Und parallel habe ich u.a. auch make/autoconf/automake gelernt usw. So kommt dann eben eins zum anderen ;) Wie gesagt, IMO sind Grundlagen ueber make (und rpm) essentiell. Wer nicht weiss, was zu tun ist, wenn configure/make mit nem Fehler aussteigt, der sollte fertige RPMs von SuSE oder packman[2] verwenden. Wem, wie dir "nur" das Wissen ueber rpm-specs fehlt, fuer _den_ _kann_ checkinstall ein Hilfsmittel sein.

Ich bin mir da nun nicht mehr so sicher, aber mit "make install" wird es sicher auch oefters zu Problemen kommen. Gerade wenn es eben um das spaetere erneute Updaten der Software oder das Deinstallieren geht.

Ack. Insofern: ja, dann lieber noch checkinstall. Das aber im Wissen um die Risiken/Nachteile/Einschraenkungen. Kurz: Mir ist bei beidem unwohl ;) Genauso uebrigens, wenn "blind" ein "irgendwo" ein rpm gefunden wurde (z.B. eins fuer Mandrake o.ae.)...

...

[...] Das, was checkinstall macht _ist_ einfach. Dazu musst du nicht das RPM-Book kennen. Du kannst dir z.B. auch einfach die Vorlage, die checkinstall verwendet schnappen. Ein Beispiel eines solchen minimal RPMs hat auch Manfred geschrieben. Das RPM-Book und make musst du dann kennen, wenn checkinstall ebenso versagen wuerde, und dann ist checkinstall sowieso nicht zu empfehlen.

Nun, vielleicht habe ich mich da etwas irritieren lassen. Ich habe so manchen Thread hier verfolgt und oefters nicht mehr folgen koennen, wenn ihr[1] euch ueber die RPM-Interna unter- halten habt. Kleines Beispiel, da war z.B. der Thread vor eini- ger Zeit zwischen Ralf und Philipp ueber das Kernel-RPM, der dann auch per PM noch ein bisschen weiter ging - da musste ich irgendwann einfach aussteigen.

Das Kernel-RPM ist sowieso ein Sonderfall. Und ich habe bei mir bisher genau 2 Kernel-RPMs installiert. Beide waren die von der Installations-CD der beiden SuSE-Versionen die ich bisher installiert habe.

Ich habe mir dann eben das Maximum RPM-Handbuch mal angeschaut, und feststellen muessen, dass ich das nicht so einfach fand.

Die Abschitte ueber spec-Dateien im Maximum-RPM muss man selektiv, eher wie eine Referenz[3], lesen. Das MRPM-Book ist leider bei vielen (wichtigen) Fragen die einzige Quelle (die ich kenne), wo diese Details dokumentiert sind.

Vielleicht habt ihr[1] da aber eben auf einer Ebene diskutiert, die man gar nicht so unbedingt braucht, wenn man eigene RPM erstellen will.

IIRC: Jep.

Aber, wenn man das so hoert, man moechte ja auch nichts falsch machen.... :-)

Das will man sowieso nicht, oder? :) Naja, wenn man richtig drangeht (z.B. prefix erstmal auf ~/test-rpms o.ae. setzt), dann geht das bei einem halbwegs sauberen Makefile schon -- und wie man mit make umgeht sollte man (s.o.) sowieso wissen ;) -dnh

[1] diejenige, die sich mit der Erstellung von RPMs gut ausken- nen

[2] oder einer anderen, "guten" Quelle fuer SuSE-spezifische RPMs (ich kenn aber keine). [3] Im Prinzip reichen (erstmal, als Ersatz fuer checkinstall): * Inside the Spec File * Creating Subpackages * Concise Spec File Reference Und auch dort muss man noch ein wenig selektiv lesen. -- Die Deutsche Sprache ist also nicht ursprünglich deutsch, sondern ein Konglomerat aus verschiedenen anderen Sprachen, die aber auch nicht ursprünglich sind, sondern wieder Konglomerate aus verschiedenen noch anderen Sprachen, die... [Volker Tanner in suse-talk]