![](https://seccdn.libravatar.org/avatar/7b33cb1e776e35b87edb8ef09f0c888f.jpg?s=120&d=mm&r=g)
Hallo, On Sun, 15 Dec 2002, Ekkard Gerlach wrote: [checkinstall]
Muß dazu das alte rpm sozusagen als "Vorbild" noch installiert sein? Oder muß ich das alte rpm vorher löschen ?
Nein, nein. checkinstall laedt eine lib ('installwatch') (via LD_SO_PRELOAD), die alle Datei-funktionen abfaengt und die Dateinamen loggt. Aus dieser Liste von Dateinamen bastelt checkinstall dann ein RPM. Dieses Konzept hat Vor- und Nachteile: - man kann "mal eben" ein RPM backen - das make install (das checkinstall per default aufruft) installiert direkt ins laufende System (aber protokolliert eben mit). Das hat u.U. gravierende Nebenwirkungen (z.B. falls mal was nicht laeuft). Erst wenn man dann das erstellte RPM tatsaechlich _drueberbuegelt_[1] wird die RPM-DB aktualisiert (und die von 'make install' installierten Dateien eben nochmal ueberschrieben). - auf Sachen wie Dokumentation, Config-Dateien, Requires, Obsoletes usw. geht checkinstall hoechstens rudimentaer, in der Regel aber wohl gar nicht ein (das waere auch sehr schwierig zu implementieren). 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]).
Muß nach der Installation des neuen Paketes das alte rpm gelöscht werden ?
Das solltest du eigentlich ueber 'rpm -U' vs. 'rpm -i' loesen, aber ob das auch mit checkinstall geht? Ich bezweifle es -- v.a. wenn du z.B. aeltere SuSE RPMs im System hast, checkinstall wird sicher kein 'Provides: foodev\nObsoletes: foodev\n' einbauen, d.h. dein neues foo-devel wuerde kollidieren und auch das -U wuerde fehlschlagen, da sich der Paketname geaendert hat. In dem Fall ist's IMO besser, sich ein aktuelles und das SuSE .spec zu greifen/extrahieren und dann eine "Sythese" aus beiden zu schaffen ;) Oder mal auf packman schauen oder hier fragen, ob jemand ein spec/src.rpm hat. -dnh [1] kann sein, dass checkinstall die Dateien zwischenzeitlich loescht, aber das bringt weitere Probleme mit sich, z.B. wenn man erstmal nur das RPM backen will, aber noch nicht installieren, dann wuerde checkinstall die Dateien trotzdem erstmal loeschen, und schwups geht u.U. garnichts mehr [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: ==== %prep %setup -q %build CFLAGS="$RPM_OPT_FLAGS" ./configure make %install make DESTDIR="$RPM_BUILD_ROOT" install ~/bin/rpm-gen-filelist.sh > .filelist %files -f .filelist ==== Das Ergebnis ist IMO besser als checkinstall und so einiges was mir ansonsten schon an .specs begegnet ist... Den Aufruf von ./configure bzw. 'make install' muss man eben ggfs. anpassen, aber das bleibt einem ja auch mit checkinstall nicht erspart. [3] ==== ~/bin/rpm-gen-filelist.sh ==== #! /bin/bash : ${RPM_BUILD_ROOT:=$1} find "${RPM_BUILD_ROOT}" -not -type d -printf "/%P\n" | sort \ | sed \ -e 's¡^.*/\(etc\|app-defaults\|init.d\|rc.d\)/.*¡%config &¡' \ -e 's¡^.*/.*\(rc\|\.cf\)$¡%config &¡' \ -e 's¡^.*/.*/\(man\|info\|doc\)/.*¡%doc &¡' \ -e 's¡^.*/.*\.sh$¡%attr(755,-,-\) &¡' \ -e 's¡%doc %config¡%doc¡' \ -e 's¡%doc \(%doc \)*¡%doc ¡' \ -e 's¡%config \(%config \)*¡%config ¡' ==== -- - Macs sind für die, die nicht wissen wollen, warum Ihr Rechner funzt. - Linux ist für die, die wissen wollen, warum er funzt. - DOS ist für die, die wissen wollen, warum er nicht funzt, und - Windows ist für die, die nicht wissen wollen, warum er nicht funzt.