Re: [opensuse-programmin g-de] Bitte um Korrekturlesen eines .spec für s BS + dessen Bedienung

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