Ralf Corsepius
[ ] Du kennst den Sinn und Zweck der autotools.
Können wir solche dummen rethorische Fragen lassen? Natürlich kenne ich den.
Sinn und Zweck der autotools ist, dass Du gar nichts anpassen sollst.
Ah ja, und dann schleppt ein Paket z.B. uralte gnome autoconf Makros mit sich rum, die nicht zur aktuell installierten Version passen. Ohne autoreconf, bzw. regenerierung von configure.in knallt das Ganze gewaltig.
Nominiell werden rpms mit rpmbuild (rpm-4) bzw. rpm (rpm-3) übersetzt. Ein sauberes RPM.spec liefert dabei saubere Fehlermeldungen, sollte etwas nicht stimmen. Ein rpm.spec, das während des rpmbuilds stirbt, ist deshalb schlicht und einfach als fehlerhaft einzustufen.
Von mir aus ist es das dann halt. Über den Punkt werden wir uns wahrscheinlich nie einigen können.
Was die Fa. SuSE in ihre Kommentare in rpm-Specs packt, um hausinterne Scripte (build) anzusteuern, ist deshalb aus RPM-Sicht völlig irrelevant.
Mag ja sein, aber für SUSE ist build und das internes Build-System alles andere als irrelevant.
Warum? Du verwendest doch auch sonst autoreconf?
Lies noch mal. Ich verwende autoreconf, wo dies möglich ist. Ansonsten werden autoconf/automake eben explizit aufgerufen oder, wo das nicht geht weil der Autor des Packetes meinte, direkt m4 anzusprechen zu müssen, wird eben configure direkt gepatchet.
Woher weißt Du dass das autoreconf aus zukünftigen auto*tool-Versionen noch funktionionsfähige Dateien generiert?
Du kannst es nicht wissen. Gerade der Wechsel von libtool-1.4 zu libtool-1.5 ist ein Musterbeispiel dafür, wie autoreconf funktionsfähige configure-Scripte vernichten kann.
Erzähl mir nichts, libtool 1.5 hat auch mir mächtig Kopfschmerzen gemacht. libtool gehört zu den Tools, die tendenziell mehr Probleme schaffen als sie lösen.
Einer davon sorgt dafür, dass ich libtool-1.5 für ein Projekt nicht verwenden kann.
Welcher, mal so aus Neugier?
Wozu? Der einzige Grund, libtoolize (bzw. autoreconf) zu einzusetzen, wäre der, dass die im Paket enthaltenen Libtool-Scripte fehlerhafte libs generieren würden.
Oder z.B. das Paket auf einer neuen Architektur gebaut wird, welche von libtool nicht erkannt wird? Philipp