troche zmieszany ..

Tomasz Kłoczko kloczek w rudy.mif.pg.gda.pl
Sob, 26 Paź 2002, 00:23:41 CEST


jestem, bo właśnie wywszło że zrobiłem coś co wydawać by się mogło że 
jest źle, a to coś i tak dział dobrze :_>

Ab owo ..

W kde{base,graphics}.spec wstawiłem:

%define		no_install_post_chrpath		0

Makro które na to niby ma reagować wyglada tak:

#%no_install_post_chrpath       1

%__spec_install_post_chrpath {%{!?debug: \
%{!?no_install_post_chrpath: \
        %{?verbose:set -x;} \
        echo "Remove RPATH from executable binaries and shared object files."; \
        filelist=`find $RPM_BUILD_ROOT -type f ! -regex ".*ld-[0-9.]*so.*"`; \
        elfexelist=`echo $filelist | xargs -r file | \
                awk '/ELF.*executable/ {print $1}' | cut -d: -f1`; \
        elfsharedlist=`echo $filelist | xargs -r file | \
                awk '/LF.*shared object/ {print $1}' | cut -d: -f1`; \
        if [ -n "$elfexelist$elfsharedlist" ]; then \
                chrpath -d $elfexelist $elfsharedlist; \
        fi; } \
} }

!?no_install_post_chrpat jeżeli no_install_post_chrpath=0 powinno być
1 czyli że niby chrpath ma się wykonać.
Dotąd byłem przekonany, że %{?<foo>:<bar>} czy %{!?<foo>:<bar>} reaguje na 
wartość <foo> a nie na to czy <foo> jest zdefiniowane czy nie bo wychodzi
na to że to właśnie tak działa :>

Sam nie wiem czy to jest błąd czy ficzer. W końcu w bcond to masowo
wykorzystujemy ale wszędzie było to używane z myślą nie o tym czy jest to 
zdefiniwane czy nei tylko czy takze ma konktretna wartość i przyu braku 
brane było jako wartość "0".

Jeszcze nie wszystkie potrzebne pakiety dostały wyłacznie chrpath i chyba
spróbuję to tym razem ustawioć na .. 1 żeby się pzrekonać jak to jest :_>

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*



Więcej informacji o liście dyskusyjnej pld-devel-pl