Hallo,
ich probiere gerade ein SPEC-File von einem Suse SRC-Paket für Centos 5.3 umzubauen. So einige Probleme habe ich schon beseitigt, zb. Die %{insserv_ Variable im Spec-File und das Programm insserv gibt es unter Centos nicht, da muss ich mit chkconfig und service arbeiten. usw.....
Mein primäres Problem ist allerdings das in diesem SRC-File auch einige Python Files drin sind. Baue ich nun mittels rpmbuild -ba dieses Paket unter Centos neu, dann entstehen für alle *.py Dateien jeweils auch noch ein *.pyc und ein *.pyo Datei in den entsprechenden Verzeichnissen. Was dann beim Erstellen des RPMs zu einem Fehler führt.
Also diese *.pyc/pyo entstehen nur wenn ich über rpmbuild gehe. Kompiliere ich das SRC-File über den normalen Dreisatz, dann entstehen sie nicht. Daher muss es ein Problem o. Feature vom Centos rpmbuild sein das diese Dateien entstehen.
Hat jemand hier eine Idee warum diese *.pyc/pyo erstellt werden und wie ich dieses "Feature" evt. deaktivieren kann?
Cu
Achim
Am Mittwoch, den 10.06.2009, 18:27 +0200 schrieb Achim Theobald:
Hallo,
ich probiere gerade ein SPEC-File von einem Suse SRC-Paket für Centos 5.3 umzubauen. So einige Probleme habe ich schon beseitigt, zb. Die %{insserv_ Variable im Spec-File und das Programm insserv gibt es unter Centos nicht, da muss ich mit chkconfig und service arbeiten. usw.....
Mein primäres Problem ist allerdings das in diesem SRC-File auch einige Python Files drin sind. Baue ich nun mittels rpmbuild -ba dieses Paket unter Centos neu, dann entstehen für alle *.py Dateien jeweils auch noch ein *.pyc und ein *.pyo Datei in den entsprechenden Verzeichnissen. Was dann beim Erstellen des RPMs zu einem Fehler führt.
Also diese *.pyc/pyo entstehen nur wenn ich über rpmbuild gehe. Kompiliere ich das SRC-File über den normalen Dreisatz, dann entstehen sie nicht. Daher muss es ein Problem o. Feature vom Centos rpmbuild sein das diese Dateien entstehen.
Hat jemand hier eine Idee warum diese *.pyc/pyo erstellt werden und wie ich dieses "Feature" evt. deaktivieren kann?
Cu
Achim
Das ist ein Feature das er dir automagisch vorkompilliertes python Zeugs erstellt. Ich würde das nicht abstellen sondern die %files-Sektion entsprechend erweitern.
Chris
financial.com AG
Munich head office/Hauptsitz München: Maria-Probst-Str. 19 | 80939 München | Germany Frankfurt branch office/Niederlassung Frankfurt: Messeturm | Friedrich-Ebert-Anlage 49 | 60327 Frankfurt | Germany Management board/Vorstand: Dr. Steffen Boehnert (CEO/Vorsitzender) | Dr. Alexis Eisenhofer | Dr. Yann Samson | Matthias Wiederwach Supervisory board/Aufsichtsrat: Dr. Dr. Ernst zur Linden (chairman/Vorsitzender) Register court/Handelsregister: Munich – HRB 128 972 | Sales tax ID number/St.Nr.: DE205 370 553
Am Mittwoch, 10 Juni 2009 19:43:51 schrieb Christoph Maser: CM> Das ist ein Feature das er dir automagisch vorkompilliertes python Zeugs CM> erstellt. Ich würde das nicht abstellen sondern die %files-Sektion CM> entsprechend erweitern. CM> CM> Chris
zumindest für /usr/share/ fur bindir würde cih die 2 mit exclude rausnehmen
Simon Wesp schrieb:
Am Mittwoch, 10 Juni 2009 19:43:51 schrieb Christoph Maser: CM> Das ist ein Feature das er dir automagisch vorkompilliertes python Zeugs CM> erstellt. Ich würde das nicht abstellen sondern die %files-Sektion CM> entsprechend erweitern. CM> CM> Chris
zumindest für /usr/share/ fur bindir würde cih die 2 mit exclude rausnehmen
Also sind das jetzt (vorkompilierte) Files, die normalerweise während der Laufzeit bzw. beim Aufruf des entsprechenden Python Scripts erstellt würden? Und diese werden jetzt als Feature bereits vom rpmbuild erstellt und im Paket angelegt um den Start der Scripte zu beschleunigen?
Wenn dem so ist, dann kann ich damit auch leben.
Diese Files bereits in den %files aufzunehmen, hatte ich bereits gemacht um überhaupt mal das RPM erfolgreich erstellen zu können.
Achja, wo im Spec-File muss (%)exclude verwenden um die Files vom Paket auszuschließen?
Cu
Achim
Am Mittwoch, 10 Juni 2009 22:35:34 schrieb Achim Theobald: AT> Achja, wo im Spec-File muss (%)exclude verwenden um die Files vom Paket AT> auszuschließen?
%files %{_bindir}/foo.py %exclude %{_bindir}/foo.pyc %exclude %{_bindir}/foo.pyo
Am Mittwoch, den 10.06.2009, 23:50 +0200 schrieb Simon Wesp:
Am Mittwoch, 10 Juni 2009 22:35:34 schrieb Achim Theobald: AT> Achja, wo im Spec-File muss (%)exclude verwenden um die Files vom Paket AT> auszuschließen?
%files %{_bindir}/foo.py %exclude %{_bindir}/foo.pyc %exclude %{_bindir}/foo.pyo
Wieso excluden, was spricht dagegen die Dateien einfach zu behalten?
financial.com AG
Munich head office/Hauptsitz München: Maria-Probst-Str. 19 | 80939 München | Germany Frankfurt branch office/Niederlassung Frankfurt: Messeturm | Friedrich-Ebert-Anlage 49 | 60327 Frankfurt | Germany Management board/Vorstand: Dr. Steffen Boehnert (CEO/Vorsitzender) | Dr. Alexis Eisenhofer | Dr. Yann Samson | Matthias Wiederwach Supervisory board/Aufsichtsrat: Dr. Dr. Ernst zur Linden (chairman/Vorsitzender) Register court/Handelsregister: Munich – HRB 128 972 | Sales tax ID number/St.Nr.: DE205 370 553
Am Donnerstag, 11 Juni 2009 07:53:58 schrieb Christoph Maser: CM> Am Mittwoch, den 10.06.2009, 23:50 +0200 schrieb Simon Wesp: CM> SW> Am Mittwoch, 10 Juni 2009 22:35:34 schrieb Achim Theobald: CM> SW> AT> Achja, wo im Spec-File muss (%)exclude verwenden um die Files vom CM> SW> AT> Paket auszuschließen? CM> SW> CM> SW> %files CM> SW> %{_bindir}/foo.py CM> SW> %exclude %{_bindir}/foo.pyc CM> SW> %exclude %{_bindir}/foo.pyo CM> Wieso excluden, was spricht dagegen die Dateien einfach zu behalten?
naja, ich sagts ja bereits ich pers. würde sie in /usr/share/* belassen aber aus bindir der Übersicht wegen löschen, insbesondere da diese pyc und pyo nicht das Programm ausführen und somit mit ihrer Anwesenheit für Verrwirrung sorgen könn(t)en. Der User kann sie nicht aufrufen und das pythonapp braucht sie nicht? Was spricht deiner Meinung nach dafür es zu behalten?
-
Achim Theobald -
Christoph Maser -
Simon Wesp