Hallo, Am Son, 21 Jun 2009, Manfred Tremmel schrieb:

Am Sonntag, 21. Juni 2009 schrieb David Haller:

...

hab heute "mal eben" ein Paket gebastelt, und würde mich freuen, wenn jemand, der sich besser als ich mit dem BS / den SUSE Gepflogenheiten für spec-Dateien auskennt, mal drüberlesen könnte, ob irgendwas auffällt / falsch ist ...

Schaut nicht übel aus.

*freu*

Ist es sinnvoll uniconv nach uniconvertor umzubenennen, oder wäre es nicht günstiger einen link zu setzen, um beide Varianten zur Verfügung zu haben?

Nein, es gibt noch ein anderes '/usr/bin/uniconv' a la iconv, das bei 'yudit' dabei ist. Siehe auch die Diskussion in opensuse-de ("Subject: Inkscape" ab dem 18.6) was das für Irritationen verursacht hat. Und yudit ist ein "normales" openSUSE (11.1) repo-oss Paket und hat also IMO auf jeden Fall Vorrang. Vgl.: http://packages.opensuse-community.org/index.jsp?searchTerm=%2Fusr%2Fbin%2Funiconv&distro=openSUSE_111 Bei Debian scheint's das gleiche Problem zu geben, darüber hab ich auch erst gefunden, daß es da ein anderes 'uniconv' gibt... Bzgl. dem Paketnamen und dem Scriptnamen hab ich mich also an der Lösung orientiert, die AFAIK bei Debian verwendet wurde, daher auch das "rabiate" mv ..../uniconv ..../uniconvertor, denn erstens findet man diese Lösung bei der Websuche und zweitens ist das eh nur ein kl. Wrapperscript um einen python Aufruf: $ delcomments /usr/bin/uniconvertor ; echo python -c "from uniconvertor import uniconv; uniconv();" "$@" $

Ansonsten bin ich bei meinen spec Files immer etwas vorsichtig, was das "%clean" angeht. Wenn sich ein Schlaumeier buildroot auf / legt, dann gute Nacht. Ich verwende deshalb gerne folgende Konstruktion:

[ "%{buildroot}" != "/" ] && %__rm -rf "%{buildroot}"

Öh, stimmt eigentlich, hab ich einige Jahre auch so gemacht. In letzter Zeit verwende ich (lokal) aber nur noch 'rm -rf %{buildroot}' ;) Ähm, und irgendwie meine ich dabei auch: ein Schlaumeier, der buildroot so dämlich anpasst und nicht das .spec anpasst, dem ist sowieso nicht mehr zu helfen ... ;P Ich guck aber mal, daß ich das bei Gelegenheit doch wieder einbaue (bzw. mir generell wieder angewöhne).

Ist manchmal auch ganz sinnvoll sich das oben in den "%install" Bereich zu legen, damit man nicht Erblasten aus früheren Build-Versuchen dort vorfindet (hatte schon oft mit Files zu kämpfen, die ich zwar nicht mehr installiert habe, die aber trotzdem immer wieder als unpackaged aufgeführt wurden, ein Aufräumen hilft da weiter.

Das mache ich generell -- allerdings hat mir rpmlint heute gerade bei diesem spec erzählt, daß rpmbuild sowieso das buildroot plattmacht, zumindest die aktuelle Version und ich somit, wenn ich's selber machen soll auch das buildroot selber neu und sicher anlegen muß (wobei 'mkdir -p' und 'install -d' offenbar als unsicher gewertet werden wg. Race-Conditions oder so). Ich hab mir dann keinen Kopp drum gemacht und das 'rm -rf %{buildroot}' einfach aus dem .spec geworfen. Das olle rpm v3, das ich hier noch verwende löscht %{buildroot} allerdings nicht selber -- und AFAIR kennst du diese RPM-Version ja auch noch sehr gut :) Und ja, das gibt manchmal nette Effekte wenn %install mehrfach läuft, und %buildroot noch "voll" ist ;) Das sind allerdings IMO meist kaputte Install-Routinen die da Ärger machen (und sei's ein eigenes 'ln -s foo bar' statt 'ln -sf foo bar'.). Davon gibt's aber leider mehr als genug. Eine Prüfung auf 'unpackaged files' hätte ich hier auf der ollen Kiste gerne optional ;) Danke für deinen Kommentar :) -dnh, der hier schon lange mit boost kämpft. Gibt's eigentlich noch ein dooferes build-tool als bjam? Das rödelt hier immer erstmal mindestens 10 Minuten oder länger vor sich hin, bevor es dann mal auch nur irgendwas macht. In der Zeit hätte make (bei boost) schon 10 oder mehr files kompiliert (und mit ccache schon die halbe lib oder so :). Die paar Sekunden(-Bruchteile), die make jew. dazwischen braucht sind leicht zu ignorieren ... Und bei make kann ich viel leichter FLAGS anpassen. Bei bjam bin ich nur am Fluchen, wenn das wieder irgendwoher irgendeinen bekloppten Default als gcc Option nimmt. Was ist z.B. das bjam-Kommandozeilen-Äquivalent zu make -e CC="ccache /opt/gcc/3.3.5/bin/gcc -v -save-temps" bzw. make -e CC="ccache $CC -v -save-temps" ???? Und eine Boost-Version die mit nem gcc-3.3.5 oder besser noch 2.95.3 kompilierbar ist hätte ich auch gern mal. Und IIRC hab ich auch mit nem gcc-4.irnkwas Probleme. IIRC sogar auf der 11.1: boost-src.rpm, gcc, und Rest an -devel von SuSE -> läuft nicht durch. Hä? *KOTZ* Ich kann gar nicht soviel essen wie ich da kotzen muß. *Cat5'o'9 such* *Motorsäge such* *Benzin such* *Roten Hering such* -- Warning: Pregnancy can cause birth -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org