Nowe przebudowane ncurses

Tomasz Kłoczko kloczek w rudy.mif.pg.gda.pl
Pią, 19 Lut 1999, 00:58:33 CET


Siedziałem i wysiedziałem, a od tego pakietu trzeba było zacząć całe
preparowanie nowego stable gdyż reszta rzeczy jest mocno z tym pakietem
powiązana. Efekt końcowy jest taki, że w wyniku budowania na końcu
otrzymuję coś takiego:

Wrote: /home/kloczek/rpm/SRPMS/ncurses-4.2-12.src.rpm
Wrote: /home/kloczek/rpm/RPMS/ncurses-4.2-12.i386.rpm
Wrote: /home/kloczek/rpm/RPMS/ncurses-ext-4.2-12.i386.rpm
Wrote: /home/kloczek/rpm/RPMS/terminfo-4.2-12.i386.rpm
Wrote: /home/kloczek/rpm/RPMS/ncurses-devel-4.2-12.i386.rpm
Wrote: /home/kloczek/rpm/RPMS/ncurses-static-4.2-12.i386.rpm

Jeszcze wpis z %changelog:
* Wed Feb 17 1999 Tomasz Kłoczko <kloczek w rudy.mif.pg.gda.pl>
  [4.2-12]
- updated to 990213 snapshot,
- removed hjl patch (now is in 990213 snap),
- added LDFLAGS="-s" to ./configure enviroment,
- removed removing linux, linux-m terminfo on sparc,
- added "Conflicts: glibc <= 2.0.7" in main,
- added terminfo subbackage with full terminfo database (minimal term db
  is in main package),
- added separated subpackage ext with non-base ncurses libraries
  (separating this allow minimize minimal system size).

I krótki komentarz co, jak i dlaczego.
Otóż dotychczasowe ncurses wynikowo miało ~660KB .. teraz ~230KB (objętość
niespakowana to 2,490KB i 530KB). Już tylko z tego widać, że system oparty
o Base będzie mógł być dzięki temu o ~2MB mniejszy :) .. 2MB na flashu w
romfs to dużo.

Teraz co jest w poszczególnych pakietach i jak one są nawzajem od siebie
uzależnione. Otóż główny zawiera wyłącznie /lib/libncurses.so.* (od tego
momentu należy zakładać, że ta biblioteka jest tu, a nie w /usr/lib),
narzędzia jakie są w /usr/bin, many do tego wszystkiego i minimalną bazę
terminfo zawierającą najczęściej używane typy terminali jak vt100, vt220,
vt52, linux*, console, xterm* (podobny model jest w Debianie i SuSe ale
ten w SuSe jest kompletnie skwaszony gdyż całość wpada do dwuch pakietów
.. ncurses i terminfo; czyli ncurses zawiera wszyskie liby statyczne i
devel stuff .. jak to można było aż tak skwasić ? .. no nie wiem). Cała
reszta terminfo (dopełnienie do pełnej bazy) jest w pakiecie terminfo i
pakiet ten będzie mógł być ewentualnie wykorzystywany na serwerach
dostępowych gdzie ludzie logować się mogą choćby i z własnego Palm Pilota
(tak jak ja gdzie mam emulację vt200 ;). Pakiet ext zawiera dodatkowe liby
jak panel, menu, form. Wydzielenie tego jest niemal naturalne gdyż jak na
razie np. w obecnym PLD devel owych trzech libów używają tylko chyba dwa
czy trzy pakiet (iptraf i coś jeszcze). Podpakiet devel wymaga już
obecności głównego i ext. Static zawiera liby statyczne i wymaga (jak inne
static) pakietu devel.

Obecna postać pakietu jest IMHO już do przyjęcia choć są jeszcze dwie
rzeczy do zrobienia których dokończenie nie będzie się propagowało na
resztę pakietów, które z nowego układu w ncurses będą chciały skorzystać.
Chodzi już o wspominane Ada95 i C++ bindings. Pierwsze próbować będzie
można robić jak ktoś zrobi pakiet z Adą gdyż bez tego Ada95 bindings nie
chce się próbować kompilować (autoconf sprawdza czy ma się Adę). Drugi
IMHO na razie bez patchowania na razie nie ma sensu, gdyż wynikowo
dodawanych jest drugie tyle plików nagłówkowych i lib statyczny. Trzeba by
dorobić generowanie liba shared (przeróbka c++/Makefile.in) czego mi na
razie nie chciało się robić. Tak jak napisałem obie rzeczy są TODO ale w
obecnej chwili możemy spokojnie bez tego wytrzymać.

Kolejna sprawa, że usunąłem sym linki *.h -> ncurses/*.h jakie są w
/usr/include. Dawało to to, że pliki nagłówkowe od ncurses były widoczne w
/usr/include i /usr/include/ncurses. Tu może być kilka pakietów które mogą
tego nie wytrzymać podczas budowania ale taki dualizm jest IMHO
niepotrzebny i powinno się raczej przyzwyczajać resztę źródeł do tego żeby
plików nagłówkowych ncurses szukały w jednym miejscu. W razie czego z tej
ostatniej zmiany można się wycofać ale można IMHO spróbować to też przy
okazji uporządkować. Anóż nie będzie to wymagało dużej ilości poprawek w
innych pakietach.

I jeszcze jedna konsekwencja powyższego. Otóż każdy nowy pakiet
produkowany od teraz, a który będzie korzystał z ncurses powinien dostać w
nagłówku linijkę:

Requires: ncurses >= 4.2-12

Ponieważ w obecnym rh[1] jest ncurses 4.2-11 mamy pewność, że niezależenie
od tego czy ktoś będzie brał ncurses z PLD czy z rh czy z przyszłej
oficjalnej dystrybucji powstaej z rh to będzie on pracował poprawnie
ponieważ obecny stuff w rh pracuje na nowym glibc. Jednocześnie powyższe
spowoduje to, że da się uniknąć sytuacji w której nie pojawi się
ostrzeżenie o konieczności wykonania upgrade ncurses co będzie powodować
SIGSEGV tak jak mi przy iptraf czyli już tutaj widać, że o jeden dołek
związany z przejścien na kernel 2.2/glibc 2,1 mamy mniej w porównaniu do
rh :)
Samo ncurses dostaje jeszcze:

Conflicts: glibc <= 2.0.7

Co powoduje, że bez przeginania z --nodeps nie uda się użyć nowego
ncurses w systemie z starym glibc (wyraźna sugestia, że należy użyć
czegoś nowszego). "Requires: glibc >= 2.1.0" mogłoby gdzieś w przyszłości
wiącać jakoś ręce temu ncurses, a Conflicts determinuje w tym wypadku
wystarczająco układ zależności.

Muszę jeszcze tylko to wszystko wrzucić do CVS i o ile już nie będzie nić
do poprawki to jutro jeszcze korekta joe (Requires) jakie już wyczyściłem
i będą pierwsze dwa src do nowego stable. Czyli zaczyna się czyszczenie po
kolei .. pakiet po pakiecie. Po woli nie śpiesząc się ale systematycznie.
To co Wojtek w tym momencie robi nie stoi z tym wszystkim w sprzeczności
gdyż jego robota to poligon z którego aktywnie korzystam (czyli tak jak
było zakładane od początku) przed ostatecznym "zatwierdzeniem" pakietu,
jego oznakowaniem i udokumentowaniem ewentualnie tego co w nim można
jeszcze próbować zrobić.

kloczek
[1] rh == rawhide
    RH == RedHat 5.2
-- 
-----------------------------------------------------------
*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