Ralf Corsepius
Nun, autoreconf im spec-File halte ich schon für gewagt.
Ich halte es für deutlich einfacher als automake etc. explizit aus dem spec-file aufzurufen.
Manuelles autoreconf mit anschliessenden Tests + Patch im src.rpm hingegen kann sinnvoll sein.
Und wenn eines oder mehrere der Autotools-Pakete aktualisiert werden den Patch wieder anpassen? Nein danke.
Insofern autoreconf denn funktioniert ...
Zumindest für meine Pakete überprüfe ich das. Wenn autoreconf nicht funktioniert, wird es auch nicht aufgerufen.
Dann sollte das rpm.spec aber auch ein BuildPreReq: autoconf automake gettext libtool enthalten, um User frühzeitig darauf zu stossen.
Es sind SUSE-Pakete und der korrekte Weg sie zu bauen ist die Verwendung des mitgelieferten "build" Skriptes. Das mag dir nicht schmecken, ist aber so.
"interessant" (Lass mal autoreconf auf gcc los ;) )
Solange gcc noch nicht auf die aktuellen Autotools umgestellt ist? Sicherlich nicht!
Welche sollten das sein? Eigentlich sollte keinerlei Notwendigkeit geben, irgendwelche der auto*-generierten Scripte zu regenerieren.
Zum Beispiel eine neue Version von libtool?
Gut, es gibt Bugs in auto*tool generierten Dateien, die sich *nach* der Installation auswirken könnten, doch wären das Bugs in den Paketen, die sich gefixt gehören (z.B. falsche Pfade in *.la).
Diese mittels autoreconf beheben zu wollen halte ich für "die grosse Keule".
Mag sein, dass das die grosse Keule ist, aber lieber die als immer wieder an dem Paket rumbasteln zu müssen. Philipp