Biuletyn PLD nr 3

[Tomasz Kłoczko]

 -- mc już poprawione --

Przed chwilą skończyłem to co uniemżoliwiało mi poprawne skompilowanie mc.
Obecnie już wszystko jest pod kontrolą. Może trochę komentarza do tego
przypadku, który IMHO może być pouczający.

Zaczęło się od tego, że jakiś czas temu zauważyłem, że kilka programów z
dystrybucji jest linkowanych z dwoma lub z nawet trzema biblitekami do
niskopoziomowej obsługi terminala. Były to takie programy, które były
linkowane jednocześnie z libslang/liblibncurses, libncurses/libtermcap,
libslang/libtermcap lub libslang/libtermcap/libncurses. Jak poszukacie
trochę w tym co macie to znajdziecie trochę takich programów. Jednym z
nich jest mc, które kiedyś było linkowane z wszystkimi trzema libami ..
potem tylko z dwoma (slang/ncurses .. podesłałem kiedyś patcha do tego
Miguelowi). Takie podwójne linkowanie jest dość patologiczne. Wszystkie
trzy biblioteki w pewnym podzbiorze funkcji moga być wzajemnym
ekwiwalentem. Samo ładowanie dodatkowej bibioteki zabiera pamięć i czas
przy inicjaji programu. Zacząłem się bliżej przyglądać temu dlaczego tak
się dzieje, że mc jest linkowane z ncurses/slang. Okazało się, że tak
naprawdę, to podczas linkowania mc w liście bibliotek z którymi to mc ma
być zlinkowane nie ma ncurses ale jest ono dołączane pośrednio gdyż libgpm
podczas budowania jest linkowane z libncurses. Tu mi się narodził pomysł
żeby tak przerobić gpm-a żeby jako term bibliotekę wykorzystywał slanga.
Okazało się to w zasadzie bardzo proste gdyż slang jest kompatybilny z
duzym podzbiorem interfejsu curses/termcap.

Dopracowane rozwiązanie związane z połaczeniem gpm ze slang dzisiaj
umieściłem już w gotowym pakiecie, który jest na cenzorze (jest możliowość
wyboru [n]curses lub slang z poziomu configure).

Teraz dlaczego mc jakie miałem wyprodukowane dwa dni temu było wadliwe ?
NA początku myślałem, że przyczyna jest jedna, że było nią to, że mc było
linkowane z libslang.so.1, a ja na dysku miałem libslang.so.1 włącznie z
potrzebnymi do tej wersji plikami nagłówkowymi (zawartoś pakietu devel). W
normalnym przypadku powinienem jednak otrzmać binarkę, która powinna się
od razu wyłożyć. Tymczasem była taka sytuacja, że mc w tej wersji jaką
wyprodukowałem chodziło tylko u mnie ( nie liczę Krzyśka, który wykonywał
dodatkowe zabiegi zna sym linkach :).
Przyczyna tkwiła w plikach nagłowkowych. Otóż slang ma swoje pliki w
/usr/include/slang i ja tam też miałem .h od slang 1.2.2 ale katalog wyżej
przyplątał mi się slang.h od starego slanga. Dzięki temu zbiegowi
okoliczności otrzymałem coś co chodziło tylko u mnie :(

Teraz jeszcze drobny komentarz wogóle nt slanga. Otóż o ile będzie to
mozliwe, to będę się starał tak wszystko pozmieniać żeby wszystko co tylko
może korzystało z libslang zamiast libtermcap i libmcurses. Dalaczego ?
Chodzi o to, że zlinkowanie z libtermcap zmusza do posiadania drugiej bazy
terminali o naziew termcap (/etc/termcap), a libncurses ma większe
wymagania pamięciowe niż slang. Jak uda się to co zaplanowałem, to
otrzymamy kompilaty, które będą łatwiejsze w administrowaniu (dopracować
będzie trzeba tylko terminfo) i będą one miały mniejsze wymagania
pamięciowe, a bezpośrednim efektem będzie to, że na słąbych maszynkach
będą się ciut szybciej uruchamiały.

Mniejsze wymagania co do dysku czy pamięci RAM nawet o kilkaset czy
kilkadziesiąt KB będą ważne w przypadku takich niewielkich systemów typy
rescue, install lub restore system from backup czy nawet pod niewielki
router. 

Acha generalnie te przypadki duo lub tertio linkowani z term libami są
związane z takimi pośrednimi powiązaniami jak w przypadku libgpm no iwarto
by to wyczycić.


 -- Koncik Speca ----------------------------
 --------------------------------------------
 -- rpm i rozszerzenia językowe            --
 --------------------------------------------

Był sygnał żeby omówić sprawy związane z rozszerzeniami językowymi rpm-a.

Po co to ? Chodzi o to, żeby różne nacje mogły mieć opisy pakietów w
w swoim włąsnym a nie arbitralnym (angielskim) języku. Drauga sprawa, to
optymalizowanie tego co ma umieszczane na dysku podczas instalaccji
pakietw pod komntem wymagań językowych na danej jednostce gdyż ilość
dokumentacji zlokalizowanej pod konkretne nacje jest już dość duża, a
wiadomo, że będzie tego jeszcze więcej. Może się okazać, że gdyby nie było
pewnych możliwości PM to, za jaki czas po zainstalowaniu pakietów na danym
komputerze sporą część przestrzeni będą mogły zajmować potencjalnie
zasoby, które nigdy nie bedą wykorzystywane przez lokalnych użytkowników.

Czyli potrzebe były w pewnym momencie pewne rozszerzenia dotyczące opisu
zawartości pakietów, które powyższe wymagania by spełniały.

Sama realizacja tego typu rozwiązań została zrealizowana w dwuch
częściach. Pierwsza dotyczy strony opisu pakietów na poziomie speca czyli
pewnychc rozszerzeń składni tegop co tam można stosować. Druga dotyczy
etapu instalacji pakietów tak żeby on install/upgrade time można było
wybrać to co chce sie zainstalować.

 -- opis rozszerzeń językowych na poziomie speca --

W zasadzie dotyczy to trzech elementów:
- pole Summary,
- sekcja %description,
- dodatkowe atrybuty pozycji w sekcjach %files w posyaci wpisów z makrem
  %lang.

   -| Summary |-

Ma składnię:

Summary[\(lng1,[lng2],..]\): Krótki opis

czyli możliwe postacie powyższego mogą być następujące:

Summary:     Short description
Summary(pl): Krótki opis

lub też:

Summary(pl,en): Short description

   -| %description |-

Ma skłądnię:

%description [-l lng1 [lng2 ...]] [-n package_name]
Long description.

czyli możliwe postacie powyższego mogą być następujące:

-----------------
%description
Long description.

-----------------
%description -l pl
Pełen opis pakietu.

-----------------
%description -l pl -n gmg
Pełen opis pakietu gmc, który jest częścią tego co jest generowane z
pakietu mc*src.rpm.

   -| %lang w sekcji %files |-

Ma postać dodatkowego atrybutu w linii opisującej wpis w %files. Składnia:

%files(lng1 [,lng2 ...]) [inne_makra] /katalog/zplikiem/lub/sam/katalog

czyli możliwe postacie powyższego mogą być następujące:

%lang(pl) /usr/share/locale/pl/LC_MESSAGES/mc.mo

%lang(pl) /usr/doc/%{name}-%{version}/pl

  -- symbole nazw języków --

Są to symbole literowe ytakie jakie wynikajz najkrótszego poisu w LOCALE,
czyli np. pl, pt, es ...

Jeżeli np mamy w /usr/share/locale/de_DE/LC_MESSAGES/ jakieś pliki to będą
one opisane tak:

%lang(de) /usr/share/locale/de_DE/LC_MESSAGES/*


 -- pewne uwagi dot sh-utils --

Pierwsza grupa uwag będzie dotyczyć strony technicznej tego co
ptrzygotował Konrad.

Może błędy (różnej grubości):

W %files źle wymienione pliki z zasobami językowymi. Jest tam coś takiego:

%lang(de) /usr/share/locale/de/
%lang(fr) /usr/share/locale/fr/
%lang(nl) /usr/share/locale/nl/
%lang(pl) /usr/share/locale/pl/
%lang(pt) /usr/share/locale/pt/
%lang(sv) /usr/share/locale/sv/

Powyżej jest makro %defattr(-, root, root), z którego nie wynika jakie
atrybuty będą miały te i inne pozycje wymieniuone w filews. Poprawnie
powinno być tak, że domyśle atrybuty powinny być wymienuone w postaci:

%defattr(644, roor, root, 755)

Po co ten czwarty parametr oznaczający atrybuty ewentualnych katalogw ?
Otóż pod %defattr jest pozycja z %doc. Wszystko z tego czegoś jest
umieszczane w osobnym katalogu /usr/doc/%{name}-{%version} i gdyby tego
755 nie było, to dokumentacja znalaxła by się w katalogu z atrybutami 644
czyli do katalogu z dokumjenentacją mógłby wejśc tylko root.

Drugi błąd który jeszcze tkwi w powyższym polega na tym, że powyższe wpisy
poweinny być dłużesze, bo w katalogach /usr/share/locale/*/ są podkatalogi
LC_MESSAGES w dopiero których to znajdują się pliki sh-utils.mo. Powodować
to będzie tyle, że powyższe katalogi /usr/share/locale/*/LC_MESSAGES będą
należeć do dwuch pakietów (glibc i sh-utils). Oczywiście nieprawidłowo.

Jeszcze jedna uwaga dotycząca "coding style". Chodzi mi o pewnien porządek
w nagłówkach pakietów, żeby wyglądało to mniej więcej tak:

Summary:     Desc_eng
Summary(de): Desc_de
Summary(fr): Desc_fr
Summary(pl): Desc_pl
Summary(tr): Desc_tr

Jak widać w powyższym przykładzie uład języków jest alfabetyczny. Czyli
spełnia wymogi PC ;-)

To samo bym prosił żeby było z sekcjami %description, a żeby dodatkowo
cały shemat speca w przypadku pakietów składajcych sie z kilku podpakietów
wyglądała mniej więcej tak: 

-------------------
Summary:     Desc_eng
Summary(de): Desc_de
Summary(fr): Desc_fr
Summary(pl): Desc_pl
Summary(tr): Desc_tr

%description
............

%description -l de
............

%description -l fr
............

%description -l pl
............

%description -l tr
............

%package subpacakage
Summary:     Desc_eng
Summary(de): Desc_de
Summary(fr): Desc_fr
Summary(pl): Desc_pl
Summary(tr): Desc_tr

%description subpacakage
............

%description -l de subpacakage
............

%description -l fr subpacakage
............

%description -l pl subpacakage
............

%description -l tr subpacakage
............

%prep

%build

%install

%post

%postun

%pre

%preun

%verify

%trigger

%files

files subpacakage

%changelog

----------------

Idę spać ..

kloczek
PS. Na samym pocztku jak wymyśliłem ten periodyk chałem go nazwać
Dziennikiem .. ale to byłoby bez sensu bo de facto musiałby się nazywać
Nocnik :)
PS2. W którymś z kolejnych odcinków KS będę musiał jeszcze zawrzeć resztę
coding style. Oczywiście jeżeli ktoś miałby jakieś propozycje co do
standardowej posdtaci peca to sprawa otwqarta. W tym wypadku akurat
powyższe w dużej części jest mojego pomysłodastwa ale jest także
przedmiotem umowy między przedstawicielami co najmniej czterech nacji i
dobrze by było zeby to za bardzo nie zmieniać, bo możemy zyskać kilku
ciekawych ludzi, któży już zaakceptowali powyższy standard :-)
PS3. Zapewne w opowyższym jest kupa literówek ale już padam i nie chce mi
się czytać tego jeszcze raz .. proszę o pobłażliwość jeśli chodzi o błędy.
-----------------------------------------------------------
*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*