%strip

[Tomasz Kłoczko]

On Sat, 9 Sep 2000, Tomasz Kłoczko wrote:
[..]
> A w tych dwuch makrach byłoby wyszukowanie findem plików
> ELF*executables (i te byłyby wprost traktowane stripem) i ELF*{shared
> objects,LSB relocatable} i te były traktowane strip --strip-unneded.
> Odpowiednie kawałki można niemal żywcem do powyzszego wyciagnąć ze
> skryprów find-{provides,requires} i wstawiłbym je już jako makra, a nie
> jako osobne skrypty. Oczywiście stripowanie powinno być jak powyżej w tym
> co napisałeś kontekstowe zależnie od %debug.
> 
> Jeżeli pójdziemy tą drogą to z czasem zapomnimy o tym, że trzaba pakować
> many czy info i że trzeba coś stripować.

Wydaje mi się, że przynajmniej część zwiazana z kompresowaniem manów i
info jest już zrobiona (mi działa to na kilku pakietach).

Zostało jeszcze dokończenie stripowania i to już jutro zrobię.

Na razie jest jeszcze sporo innych zmartwień zwiazanych z powyższym. Otóż
wprowadzenie powyższego w życie spowoduje to, praktycznie prawie wszystkie
spece bendą musiały ulec różnym zmianom. Oprócz zmian wynikającz z
powyższego to:

- usunięcie z %build LDFLAGS="-s"; export LDFLAGS (czasami jest to
  rozdzielone na osobną linikę z LDFLAGS="-s" i exportowanie LDFLAGS jest
  razem z innymi zmiennymi w pojedynczym export),
- usunięcie kompresowania manów i info z %install,
- usunięcie wszystkich miejsc użycia strip,

Wszystro to powinno zadzaiłać na pewno w pakietach które używają
autoconf/automake ale jest troche paskudnych pakietów i z nimi zapewne
będziemy się jeszcze rozprawiać przez jakis czas. W specach nie opartych o
autoconf/automake zapewne można będzie zastępować użycie LDFLAGS, CFLAGS
CXXFLAGS i FFLAGS przez:

s#CFLAGS#${CFLAGS:-%optflags}%{?debug: -g -O}#
s#LDFLAGS#${LDFLAGS}%{!?debug: -s}#
s#CXXFLAGS#${CXXFLAGS:-%optflags}%{?debug: -g -O}#
s#FFLAGS#${FFLAGS:-%optflags}%{?debug: -g -O}#

po to żeby wyłączyć optymalizację czy obcinanie symboli przy
linkowaniu zależnie od %debug.
Zapewne też należałoby wyszukać użycie
"install -s" żeby użycie "-s" użależnić też od %debug.

Po za tym wydaje mi się że powyższe jeszcze należąłoby zmienić. Wydaje mi
się, że powyższe ma możliwości składni "if []; them <if_true> else
<if_false>; fi". Musiałbym to jeszcze sprawdzić ale zdaje się że to
wyglada jakoś tak:

%{?<var>:<if_var_true>!<if_var_false>}

(już nie pamietam czy miedzy <if_var_true> i <if_var_false> powinno być !,
| czy coś takiego ale zdaje się zę tak to leciało).O ile tak ejst
rzeczywiście to przykładowo dla LDFLAGS bedzie to wyglądało mniej wiecej
tak:

%{?debug: -g -O|${LDFLAGS}}

To chyba będzie komplet jeśli chodzi o powyższe (przynajmneij jeśli chodzi
o punkty zaczepienie ścieżek które bezie trzeba przejść i sprawdzić).
Jeżeli czegoś jeszcze nie zauważyłem to prośba o uzupełnienie żebyśmy
mieli jasność tego co trzeba zrobić.

Przy okazji tak masowych zmian wydaje mi się, że powinniśmy spróbować
ruszyć z posad hierarhię grup.
Już część zmian wykonałem (intergracja Utilities/* z Applications/*) i w
sumie powstaje jedna duża grupa Applications. W sumie po tym wszystkim na
pierwszym poziomie mamy teraz:
- Applications,
- Development,
- Documentations,
- Themes.

Troche mało jednoznacznie w powyższym jakiś mi sie sadowi Development bo w
sumie możnaby to rozparcelować w Applications i Documentations.
Kwestia kolenja to wydzielanie bąć nie podgrup */X11 (przynajmniej w
pierwszych trzech). Wydaje mi sie to do przyjęcia ale chętnie
dowiedziałbym sie czy ktoś inny nie ma tutaj w tej kwestii jakiś innych
pomysłów.
Obecnie jest jeszcze na pierwszym poziomie Base i na potrzeby
konfigurowania bardzo minimalnych systemów wydaje mi się, że można
zostawić tu taką małą niespójność po to żeby ułatwić takie operacje.

Przy kompletowaniu hierarhii grup trzeba na to patzreć z dwuch punktów:
- z punktu ergonomii wyboru pakietu przy instalacji/upgrade,
- jednoznaczności i łatwości przypisania pakietu do punktu w hierarii.

Tak czy inaczej przed wdrożeniem rpm-a z nowymi makrami dobrze byłoby
rozstrzygnąć a także poszykować odpowiednie kawałki skryptów które będą
służyły do możliwie automatycznego wykonania wszystkich potzrebnych zmian
o ile będziemy je mieli już wszystkie sformalizowane, skolejkowane i
skompletowane. Tutaj przydałaby sie pomoc kilku osób sprawnych w
posługianiu perla, seda czy awka.

Także od jutra dobrze by było zacząć kompletować wszystkie powyższe
rezeczy po to żeby wszystkie zmiany wykonać w możliwie krótkim odcinku
czasu skracająć do minimum stan nieustalony zasobów.

Jeżeli powyższe wprowadzimy w życie to same spece ulegną dalszym
uproszczeniom, a po wyszyyskim np. %__spec_clean_pre bedzie mozan zacżąć
kompletować dalej różne procedury automatycznej kontroli poprawności
pakietów (w efekcie końcowym powinno to dać jeszcze dalsze zwiększenie
jakosci tego co daje się wyprodukować z zasobów nad jakimi pracujemy i
także oszczędości w czasie potrzebnym na preparowanie i konserwację
pakietów).

kloczek
PS. Jeszcze mi tak sie nasuwa czy przypadkiem pod kontem powyśzsych zmian
też nie będzie trzeba wykonać jakiś zmian w adapetrze (?? .. choć chyba
nie ale mogę się mylić).
-- 
-----------------------------------------------------------
*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*


___________________________
polish  linux  distribution
-> http://lists.pld.org.pl/