GNU gettext z punktu widzenia programisty oraz tłumacza

GNU gettext dla programisty i tłumacza

Arkadiusz Miśkiewicz

$Id: gettext-art.lyx,v 1.1 2000/03/12 21:12:04 misiek Exp $

1 Wprowadzenie

Systemy UNIX, a w szczególności Linux zdobywają coraz większą popularność
na świecie. Linux używany jest zarówno przez wyszkolonych administratorów
jak i początkujących. Kilku programistów wychodząc na przeciw początkującym
użytkownikom nie znającym języka angielskiego stworzyło pakiet GNU
gettext. GNU gettext jest zbiorem aplikacji oraz bibliotek przeznaczonych
do tworzenia programów oraz skryptów potrafiących komunikować się
z użytkownikiem w dowolnym (obsługiwanym) języku.

2 Jak to działa ?

GNU gettext działa na zasadzie modułowej. Każde nowe tłumaczenie programu
jest osobnym plikiem tzw. plikiem MO (jeden plik dla każdego języka).
W większości dystrybucji Linuxa tego typu pliki można znaleźć w katalogach
/usr/share/locale/*/LC_MESSAGES/. Załóżmy, że jakiś program wyświetla
tekst “Hello world!”. Gdy ów program będzie wykorzystywał gettext
zostaną wykonane następujące operacje:

1. sprawdź aktualne zmienne locale (opisane w locale(7)). Najczęściej
używa się zmiennych LC_ALL oraz LANG.

2. sprawdź czy istnieje odpowiedni plik MO dla języka określonego w
zmiennych locale.

3. jeśli istnieje – wczytaj i używaj tłumaczeń; jeśli nie istnieje –
użyj domyślnego języka (w naszym przykładzie jest to język angielski).

Zaletą takiego rozwiązania jest to, że na jednym systemie może pracować
kilkunastu użytkowników używających różnych języków ! Ponadto dodanie
nowego tłumaczenia to tylko dodanie jednego niewielkiego pliku. Jeśli
czytelnik zaglądał to któregoś z plików MO to zapewne wie iż jest
to plik binarny. Pliki binarne MO generowane są z plików tekstowych
PO (zazwyczaj dostępnych wraz ze źródłami programu) przez niewielki
program ,,msgfmt” należący do pakietu gettext.

3 Chcę zostać tłumaczem.

Pliki tekstowe PO są to pliki zawierające wszystkie komunikaty w języku
domyślnym oraz (po przetłumaczeniu) komunikaty w języku docelowym
(np. polskim). Fragment typowego pliku PO przed tłumaczeniem wygląda
mniej więcej tak (w nawiasach klamrowych moje komentarze, których
nie powinno być w oryginalnym pliku PO):

#: src/man-config.c:233
{ nazwa pliku i numer lini, w której występuje podany tekst }
#, c-format
{ dodatkowe informacje o tekście }
msgid “Reading config file %sn”
{ sam tekst w języku domyślnym }
msgstr “”
{ miejsce na tekst w języku docelowym }

Praca tłumacza sprowadza się do przetłumaczenia tekstu znajdującego
się po polu msgid na język docelowy. Uwaga: nie wolno zmieniać tekstu
znajdującego się po polu msgid ! Powyższy fragment po przetłumaczeniu
może wyglądać tak:

#: src/man-config.c:233
#, c-format
msgid “Reading config file %sn”
msgstr “Odczytuję plik konfiguracyjny %sn”

Powyżej, w komentarzu do ,,c-format” napisałem o ,,dodatkowych informacjach
o tekście”. W miejscu tym może się pojawić kilka słów kluczowych:

* fuzzy. Generowane przez program msgmerge (o którym później). Oznacza
to iż prawdopodobnie tłumaczenie nie jest prawidłowe. Po skontrolowaniu
poprawności tłumaczenia usuwamy słowo fuzzy z pliku PO.

* c-format, no-c-format. Dodawane automatycznie (nie powinny być dodawane
czy modyfikowane przez użytkownika). Odpowiednio oznaczają, że tekst
zawiera znaki formatujące z języka C, oraz że ich nie zawiera. Słowo
c-format jest jednocześnie sygnałem dla msgfmt by zwrócił większą
uwagę na poprawność tłumaczenia tegoż tekstu podczas generowania
plików MO.

Przed zabraniem się do tłumaczenia pliku PO pochodzącego z jakiegoś
programu należy zaktualizować plik PO. W typowym programie wykorzystującym
autoconf’a wygląda to mniej więcej tak: ./configure && make -C po
update-po. Oczywiście można wygenerować nowy plik PO (bez żadnych
tłumaczeń) wykonując ./configure && make -C po Nazwa_Programu.pot.
Powstanie plik *.pot – zwykły plik PO nie zawierający żadnych tłumaczeń
(POT == PO Template). Pozostaje jedynie zabranie się za tłumaczenie
pliku. Przyjęto zasadę by w tłumaczeniach używać form bezosobowych.

Poprawność syntaksy przetłumaczonego pliku PO można sprawdzić przy
użyciu msgfmt: msgfmt -v plik.po -o /dev/null. Program poinformuje
o wszelkich nieprawidłowościach. Rola tłumacza właściwie się tu kończy.
Przetłumaczony plik należy przesłać do odpowiedniej grupy tłumaczy
GNU (np. polska grupa tłumaczy GNU jest dostępna pod adresem: pl@li.org)
lub autora programu.

4 Piszę program i chcę dodać obsługę wielu języków.

Poniższy opis dotyczy nie tylko autorów nowych programów ale także
wszystkich osób, które chcą dodać obsługę języków do już istniejącego
oprogramowania. Na początek parę słów o programach oferowanych w pakiecie
GNU gettext:

– gettextize; wykonanie tego skryptu w katalogu, w którym znajduje
się nasz program spowoduje stworzenie struktury katalogów i skopiowanie
standardowych plików używanych przez gettext podczas kompilacji itp.
Ponadto skopiowane zostaną źródła biblioteki libintl na wypadek gdyby
systemowa biblioteka nie obsługiwała funkcji gettext() i jej towarzyszących.

* msgcmp; porównuje dwa pliki PO, żeby sprawdzić czy zawierają te same
zbiory łańcuchów msgid.

* msgcomm; wyszukuje podobne zbiory łańcuchów w plikach PO

* msgfmt; generuje binarne pliki MO z plików tekstowych PO

* msghack; do automatycznej zmiany plików PO np. zamiany miejscami
zbiorów msgid z msgfmt.

* msgmerge; łączy dwa pliki PO, tak by wynikowy plik zawierał maksimum
tłumaczeń z podanych dwóch plików

* msgunfmt; funkcja odwrotna do msgfmt

* xgettext; generuje plik PO z tekstami do przetłumaczenia wynajdując
je w plikach źródłowych programu (*.c itp).

Część z powyższych programów nie wchodzi w skład standardowej dystrybucji
GNU gettext i jest dostępna w formie patchy (pełny pakiet m.in. w
PLD GNU/Linuxie).

Programiście pakiet gettext oferuje kilka funkcji:

char *textdomain (const char *domain_name);

– funkcja ustala tzw. TEXTDOMAIN. Tłumaczenia będą pobierane z pliku
TEXTDOMAIN.mo z katalogu zależnego od ustawień systemowych (typowo
jest to /usr/share/locale/).

char *bindtextdomain (const char *domain_name, const char *dir_name);

– funkcja ,,przydziela” danej domenie (domain_name) katalog, w którym
będzie poszukiwany plik TEXTDOMAIN.mo (na wypadek gdyby występowało
kilka plików *.mo o tej samej nazwie).

char *gettext (const char *msgid);

– funkcja, której przekazujemy string do tłumaczenia.

char *dgettext (const char *domain_name, const char *msgid);
char *dcgettext (const char *domain_name, const char *msgid, int category);

– funkcje będące połączeniem funkcji gettext() z bindtextdomain();.

Poza powyższymi funkcjami wykorzystuje się jeszcze jedną zawartą w
bibliotece glibc – setlocale(3). Funkcja ta służy do ustawienia aktualnie
używanego locale. Prototyp tej funkcji to:

char *setlocale(int category, const char *locale);

gdzie category to nazwa kategorii dla jakiej ustawiamy locale (typowo
jest to LC_ALL lub LC_MESSAGES) natomiast locale może być zarówno
pustym stringiem “” (wtedy locale zostanie ustawione zgodnie z wartościami
zmiennych powłoki odpowiedzialnych za locale tj. LC_ALL, LC_MESSAGES
itd) lub stringiem oznaczającym język dla jakiego ustawiamy locale
(np. “da_DK”). Ponieważ w większości wypadków program powinien wykorzystywać
zmienne powłoki dlatego będziemy używali pustego stringu “” jako locale
w funkcji setlocale(3).

Dla ułatwienia sobie pracy zamiast funkcji gettext będziemy używali
makra _(). Ponadto zdefiniujemy puste makro pełniące funkcję informatora
dla programu xgettext (o czym później).

#define _(String) gettext(String)
#define N_(String) (String)

Dodajmy więc obsługę gettextu do przykładowego programu:

#include
int main()
{
printf(“Hello world!n”);
exit(0);
}

Po pierwsze musimy włączyć dodatkowe pliki nagłówkowe: “libintl.h”
(zawiera funkcje typowe dla gettextu) oraz “locale.h” (prototyp funkcji
setlocale(3)). Następnie dodajemy ustawienie locale, przydzielenie
TEXTDOMAIN, a we wszystkie teksty, które mają być tłumaczone przekazujemy
do funkcji gettext() (w naszym wypadku za pośrednictwem makra _()).
W efekcie plik będzie wyglądał następująco:

#include
#include #include

#define _(String) gettext(String)

int main()
{
setlocale(LC_ALL, “”);
bindtextdomain(“example”, “/usr/share/locale”);
textdomain(“example”);
printf(_(“Hello world!n”));
exit(0);
}

Uważny czytelnik zapewne zauważył, że puste makro N_() nigdzie nie
zostało użyte – więc po co ono jest potrzebne. Otóż program xgettext
(o którym pisałem wcześniej) generuje plik PO wyszukując w plikach
*.c teksty przekazywane do funkcji gettext(). W naszym programie przykładowym
xgettext znalazł by tekst “Hello world!n”. Niestety w pewnych okolicznościach
nie można bezpośrednio używać funkcji gettext() np. mamy:

char *tablica[] = { “dogn”, “catn”, “Polandn” };
[…]
int main()
{
int i;
[…]
for (i = 0; i < 3; i++) printf(tablica[i]); } Użycie funkcji gettext() w definicji "tablica" jest oczywistym błędem programisty. Wyjściem z tej sytuacji jest właśnie makro N_(). Powyższy program w wersji z obsługą gettextu: #define _(String) gettext(String) #define N_(String) (String) char *tablica[] = { N_("dogn"), N_("catn"), N_("Polandn") }; [...] int main() { int i; [...] /* tutaj powinny znaleźć się funckcje setlocale(), textdomain() itd */ for (i = 0; i < 3; i++) printf(_(tablica[i])); } xgettext dzięki N_() będzie teraz ,,wiedział'', które teksty są przeznaczone do tłumaczenia, a sama funkcja gettext() zajmie się tłumaczeniem. No dobrze. Mamy już pliki źródłowe zawierające odpowiednie wywołania funkcji gettext(). Jak teraz wygenerować plik PO ? Właśnie w tym momencie użyjemy programu xgettext: $ xgettext -d example -o example.po -s plik1.c plik2.c plik3.c W wyniku działania programu xgettext (na pliku z pierwszym przykładem - "Hello world" otrzymamy plik PO o następującej zawartości): # SOME DESCRIPTIVE TITLE. # Copyright (C) YEAR Free [az url='http://www.amazon.com/b/?node=229534&tag=0202020202-20']Software[/az] Foundation, Inc. # FIRST AUTHOR , YEAR.
#
#, fuzzy
msgid “”
msgstr “”
“Project-Id-Version: PACKAGE VERSIONn”
“POT-Creation-Date: 2000-03-10 22:28+0100n”
“PO-Revision-Date: YEAR-MO-DA HO:MI+ZONEn”
“Last-Translator: FULL NAME n”
“Language-Team: LANGUAGE n”
“MIME-Version: 1.0n”
“Content-Type: text/plain; charset=CHARSETn”
“Content-Transfer-Encoding: ENCODINGn”

#: przyklad1.c:17
msgid “Hello world!n”
msgstr “”

Po przetłumaczeniu pliku PO generujemy plik MO:

$ msgfmt example.po -o example.mo

i kopiujemy go do katalogu /usr/share/locale/JĘZYK/LC_MESSAGES/ (gdzie
JĘZYK to kilkuliterowa nazwa oznaczająca określony język. Dla języka
polskiego będzie to “pl”).

Pozostaje już tylko podziwianie efektów naszej pracy:

$ LANG=pl ./przyklad1
Witaj świecie!
$ LANG=C ./przyklad1
Hello world!

(“C” – oznacza domyślny język ustawiony w bibliotece systemowej; typowo
jest to język angielski).

Programiści stosujący pakiety automake oraz autoconf w swych programach
mogą używać paru ułatwień związanych z gettextem. Po pierwsze należy
uruchomić program gettextize (o którym już pisałem):

~/moj_program/$ gettextize -c -f

Do configure.in dodajemy:

ALL_LINGUAS=”pl” – lista języków dla których już posiadamy tłumaczenie
(oddzielone spacją np. “pl fr de”)

AM_GNU_GETTEXT – makro robiące całą czarną robotę i przegenerowujemy
skrypt configure (wywołując program: autoconf).

To już wszystkie najważniejsze rzeczy dotyczące dodawania gettextu
do programów. Pełną informację jak zawsze można znaleźć na stronach
info dostarczanych z pakietem GNU gettext.

5 A co ze skryptami w shellu czy perlu lub innych językach ?

Jedyną znaną mi powłoką obsługującą skrypty z tłumaczeniami jest bash
2. W skrypcie basha 2 wpisujemy po prostu:

$ echo $”Hello world!”

Plik PO przygotowujemy natomiast przy użyciu samej powłoki:

$ bash –dump-po-strings skrypt.sh

Generację pliku MO przeprowadzamy już przy użyciu msgfmt z pakietu
GNU gettext. Należy ponadto w skrypcie ustawić zmienną TEXTDOMAIN
na nazwę tekstowej domeny. Niestety nie każdy ma czy chce używać basha
2. Pozostali powinni wykorzystywać w swych skryptach program gettext
zawarty w pakiecie GNU gettext. Przykładowe wywołanie to:

$ gettext –domain=TEXTDOMAIN “Hello world!”

Mogę na marginesie dodać, że dzięki tej metodzie skrypty startowe w
PLD GNU/Linuxie potrafią komunikować się z użytkownikiem m.in. w języku
polskim ! Podobna sytuacja jest w perlu – wystarczy ściągnąć dodatkowy
moduł z archiwum CPAN dodający funkcję gettext. Z gettextu można również
korzystać pisząc programy w innych, nie wspomnianych tutaj językach
programowania np. w pascalu (FreePascal Compilator), a także pod innymi
niż Unixowe systemami – np. pod DOSem (dzięki źródłom biblioteki libintl).

6 Problemy z GNU gettextem.

Niestety gettext nie jest rozwiązaniem idealnym. Jest to narzędzie
dość ograniczone. Podstawowym problemem jest odmiana czy liczba mnoga.
W języku angielskim kilka plików to po prostu ,,files”. W języku
polskim sytuacja się zmienia zależnie od ilości plików (2,3,4 pliki;
5-21 plików itd), natomiast GNU gettext nie pozwala na tłumaczenie
zależne od np. ilości plików. Problem ten nie został rozwiązany do
dnia dzisiejszego (osobom zainteresowanym polecam kod źródłowy programu
lftp, w którym gettext został uzupełniony o częściowe rozwiązanie
umożliwiające tłumaczenie z uwzględnieniem odmian itp.).

7 Na zakończenie.

Mimo licznych ograniczeń GNU gettext jest ważnym narzędziem przybliżającym
środowisko Linuxa ludziom z poza grona osób znających język angielski
– np. sporej liczbie użytkowników polskiej wersji Windows 8-). Zapraszam
wszystkich chętnych do tlumaczenia plików PO w ramach GNU Translation
Project oraz do dodawania obsługi gettexu do już istniejących programów.

8 Adresy.

* GNU Translation Project
http://www.iro.umontreal.ca/~pinard/po/HTML/
http://www.iro.umontreal.ca/contrib/po/

* Polski ,,oddział” GNU Translation Project
http://www.ceti.com.pl/~kravietz/gnu/gnu_tp.html

* Repozytorium CVS PL GNU TP
http://cvsweb.pld.org.pl/index.cgi/i18n/

* Słownik informatyczny, zasady tłumaczenia tekstów informatycznych
http://venus.ci.uw.edu.pl/~milek/

9. Przykłady

PLD GNU/Linux

PLD GNU/Linux – Polish Linux Distribution

Arkadiusz Miśkiewicz$Id: pld-art.lyx,v 1.1 2000/03/12 21:54:23 misiek Exp $

1 Odrobina historii.

W 1998 roku niewielka grupa osób postanowiła stworzyć pierwszą polską dystrybucję Linuxa. Projekt przyjął nazwę Polish Linux Distribution (PLD GNU/Linux). W wyniku wielu dyskusji postanowiono równocześnie prowadzić dwie linie rozwoju dystrybucji. Pierwszą określaną mianem ,,stable” (przeznaczoną dla szerokiego odbiorcy) oraz drugą ,,devel” (jak nazwa wskazywała przeznaczoną dla wąskiego grona developerów oraz administratorów). Rok później obie linie rozwojowe zostały połączone w jedną całość (rozwijaną do dziś). Zaprzestano używania nazw stable oraz devel.


2 Co na pokładzie ?

Podstawowymi cechami charakteryzującymi PLD GNU/Linuxa sa:

* IPv6. PLD GNU/Linux zawiera kompletny zestaw pakietów umożliwiający pracę w sieciach komputerowych wykorzystujących protokół IPv6 nazywany również IPng – Internet Protocol Next Generation (Protokół Internetowy
Następnej Generacji). Zainteresowanych protokołem IPv6 odsyłam na strony: http://www.6bone.pl/ (Polish 6bone Network) oraz http://www.ipv6.org/.

* Kerberos 5. Wsparcie dla systemu autentykacji Kerberos rozwijanej w europie (oczywiście wspierającej IPv6).

* OpenSSL. Dzięki OpenSSL użytkownik może w sposób bezpieczny łączyć się ze stronami www, odbierać pocztę i wiele innych. Dostarczamy szereg programów wykorzystujących możliwości SSL np. apache (serwer www), lynx (przeglądarka www), postfix, zmailer (agenci transferu poczty), fetchmail (program do ściągania poczty), stunnel (bezpieczne tunelowanie) i wiele innych.

* OpenSSH. Ze względów bezpieczeństwa podstawowym programem do zdalnej pracy w PLD jest SSH w wersji ,,free” rozwijanej przez OpenBSD Team.

* PAM. Oferujemy własną wersję modułowego systemu autentyfikacji PAM (znacznie rozbudowaną w stosunku do oryginału), a rozwijaną przez jednego z członków Zespołu PLD.

* Wsparcie dla rozwojowych jąder i programów. Ze względu na fakt iż kilku naszych developerów lubuje się w nowinkach dostarczanych przez Linusa i społeczność Linuxową – w PLD można znaleść oprogramowanie umożliwiające wykorzystanie np. z wysoko wydajnego systemu plików z kroniką (RaiserFS), nowego systemu firewall/NAT (netfilter), znacznie ulepszonego bridge, modułu zarządzania woluminami (lvm) itp.

* Wolny wybór. Nie narzucamy użytkownikom określonych rozwiązań. Staramy się udostępnić szereg pakietów z których użytkownik wybierze sobie te, które najlepiej mu odpowiadają. Dlatego też dostarczamy np. kilka agentów transferu poczty (postfix, qmail, sendmail, zmailer, exim, …), różne serwery www (apache, boa, thttpd, …) czy kilka
serwerów typu inetd (inetd, rlinetd, xinetd) itd. Podobnie jest z zarządcami okien Xwindows. W PLD znaleść można np. zarówno KDE (właśnie aktualizowane do wersji beta2.0), GNOME jak i Xfce czy WindowMakera.

* Standaryzacja. Staramy się by PLD GNU/Linux odpowiadał współczesnym standardom takim jak: FHS 2.0 (File System Hierarchy 2.0), SUSv2 (Single Unix(R) Specification version 2).

* Język polski. Wszystkie pakiety rpm dostarczane przez Zespół PLD zawierają opisy w języku polskim. Do programów dołączamy tłumaczenia dostarczane przez GNU Translation Project (http://www.ceti.com.pl/~kravietz/gnu/gnu_tp.html) oraz strony podręcznika systemowego tłumaczone w ramach Projektu Tłumaczenia Manuali (http://ptm.linux.pl/).

* Inne.

Jak widać PLD GNU/Linux zawiera ogrom oprogramowania w możliwie najnowszych wersjach umożliwiającego wykorzystanie wszelkich cech jakie daje jądro Linuxa. Dystrybucja przeznaczona jest dla wszystkich zainteresowanych szczególnie administratorów i studentów ,,zapaleńców”. Osobiście jednak nie polecam PLD początkującym użytkownikom, choć docelowo dystrybucja ma być przyjazna nawet dla osób mających styczność z Linuxem po raz pierwszy.

3 Chcę pomoć.

Wszyscy chętni do pomocy są mile widziani. Wyjaśnię pokrótce zasady tworzenia pakietów w PLD. Wszyscy developerzy wykorzystują system kontroli wersji zasobów – CVS. Jest to bardzo proste i efektywne narzędzie
(polskie opisy obsługi CVSu znajdują się na naszej stronie www w dziale technikalia). Poprawienie, uaktualnienie jakiegoś programu sprowadza się do ściągnięcia pliku spec oraz źródeł danego programu z repozytorium CVS (można to zrobić wykorzystując skrypt ,,builder” znajdujący się w module SPECS repozytorium CVS), poprawieniu błędów, uzupełnieniu itp, a następnie potwierdzeniu (przesłaniu) poprawek do serwera CVS. Odpowiednie osoby przejrzą zmiany dokonane przez developera/ów i jeśli uznają, że pakiet rpm jest ukończony przebudują go i umieszczą na oficjalnym serwerze ftp. Wszelkie konsultacje dotyczące kształtu pakietów prowadzone są na liście pld-list, której adres podam na końcu artykułu. Przed zabraniem się do pracy nad określonym pakietem można zapytać się na liście czy inna osoba już się nim nie zajmuje. Aktualnie najważniejszą sprawą jest dokończenie pakietów bazowych (należą do nich m.in. dialog, basesystem, dev, dev86, getty_ps i kilka pomniejszych) oraz poprawienie wszelkich zauważonych błędów.

W tym momecie warto wspomnieć, że Zespół PLD udostępnia także autorom oprogramowania nie należącym do Zespołu PLD swoje zasoby (tj. serwer CVS, listy dyskusyjne (z archiwum i wyszukiwarkami), miejsce na serwerze ftp). Z takiej możliwości skorzystało już wiele projektów jak np. LinuxDOC (dokumentacja, http://www.linuxdoc.org/), xmps (świetny odtwarzacz wideo MPEG, http://www-eleves.enst-bretagne.fr/~chavarri/xmps/), irssi (klient irc), emma (obsługa finansów), minicom (terminal, http://www.clinet.fi/~walker/minicom.html), GNU TP Polska. Jeśli tworzysz jakiś interesujący program – daj nam znać.

4 Pytania.

Postaram się odpowiedzieć na kilka typowych pytań dotyczących PLD:

* kiedy PLD będzie gotowe ?
Tego naprawdę nikt nie wie. Problem z powolnym rozwojem dystrybucji wynika głównie z faktu, że zajmują się nim osoby mające przede wszystkim inne obowiązki przez co nie mają czasu na skoncentrowanie się wyłącznie na PLD. Jeśli potrafisz i chcesz pomóc – przyłącz się. Skończymy dystrybucję szybciej.

* dlaczego planowany instalator będzie działał w trybie tekstowym, a nie graficznym ?
Jest na to bardzo prosta odpowiedź: po prostu tekstowy jest wygodniejszy ! Sam Xserwer wymagany w przypadku instalatora graficznego pożera sporo zasobów systemowych, a przecież nie każdy ma maszynę z 64MB ramu i kilkuset megahercowym procesorem. Ponadto instalator graficzny jest bardzo niewygodny w przypadku instalowania systemu przy użyciu tzw. kickstartu czyli automatyczniej instalacji na podstawie uprzednio przygotowanej konfiguracji. Niemniej jednak nie wykluczamy możliwości powstania graficznego instalatora jako drugiego, równożędnego.

* nie ma jeszcze instalatora więc jak zainstalować PLD ?
Możliwości jest kilka. Najprościej dla początkujących będzie po prostu ręcznie zaktualizować inną dystrybucję (RH, SuSE, Mandrake) do PLD GNU/Linuxa. Sposób ten jest prosty aczkolwiek niezbyt wygodny. Jako pierwsze należy zaktualizować następujące pakiety: filesystem, setup, glibc, rpm. Pozostałe pakiety nie są krytyczne i można je aktualizować stopniowo. Warto w tym momencie pamiętać o kilku opcjach rpm’a przydatnych podczas instalacji: –nodeps (nie będą sprawdzane zależności pomiędzy pakietami), –force (wymusza instalację pakietu nawet gdy pakiet
został już poprzednio zainstalowany), –oldpackage (zainstaluj pakiet nawet gdy w systemie już została zaistalowana starsza wersja pakietu). Na szczególną uwagę należy zwrócić na pakiet rc-scripts (skrypty startowe w PLD). By móc używać rc-scripts należy koniecznie wkompilować w jądro opcję “Kernel/User netlink socket” oraz zainstalować pakiet
iproute2. Można również udać się do znajomego, który już PLD posiada zainstalowane i po prostu przegrać zainstalowaną dystrybucję na własny dysk. Postaramy się wkrótce przygotować alternatywny sposób instalacji nie wymagający innych dystrybucji ani znajomych z zainstalowanym PLD (w formie dyskietki instalacyjnej – http://cvsweb.pld.org.pl/index.cgi/bootdisk/).

* masz jakieś pytania ?
Uruchom przeglądarkę www, załaduj stronę http://faq.pld.org.pl/ i zapytaj. Z pewnością Ci odpowiemy.

5 Na koniec.

Mimo iż dystrybucja PLD jest nadal w rozwoju warto się nią zainteresować. Zapraszamy zarówno do używania jak i tworzenia. Czekamy pod adresem: pld-list@pld.org.pl na pytania oraz sugestie.

6 Co i gdzie ?

* http://www.pld.org.pl/ – podstawowe informacje o PLD. Warto zainteresować się działem technikalia, w którym wyjaśniono sposób pracy z CVS, budowanie pakietów rpm, podstawy IPv6.

* http://www.ipv6.pld.org.pl/ – (dostęp tylko poprzez protokół IPv6).

* http://lists.pld.org.pl/ – archiwa i wyszukiwarka list dyskusyjnych.

* http://faq.pld.org.pl/ – Najczęściej Zadawane Pytania (z możliwością zadawania i odpowiadania na już zadane pytania).

* http://bugs.pld.org.pl/ – baza błędów dostrzeżonych w PLD GNU/Linuxie

* http://cvsweb.pld.org.pl/ – interfejs www do serwera CVS.

* ftp://ftp.pld.org.pl/ – główny serwer FTP (TASK Gdańsk)

* cvs.pld.org.pl – główny serwer CVS (dostępny tylko dla developerów)

* anoncvs.pld.org.pl – serwer CVS dla każdego (dostęp tylko do odczytu)

Listy dyskusyjne w domenie @pld.org.pl:

* pld-list – główna lista (dyskusja o wszystkich aspektach związanych z PLD GNU/Linuxem)

* pld-rc-scripts – dyskusja dotycząca skryptów startowych

* pld-installer – dyskusja dotycząca instalatora

* pld-www – sprawy związane ze stronami www PLD

* pld-cvs-commit – na tą listę automatycznie wysyłane są informacje
o zmianach jakie zaszły w repozytorium CVS.

Na listę można zapisać się wysyłając pusty list na adres: nazwalisty-subscribe@pld.org.pl Osoby niezaznajomione z obsługą listserwerów proszone są o wysłanie pustego listu na adres nazwalisty-help@pld.org.pl.

Tekst (C) 2000 Wydawnictwo Software. Wydrukowany w Linux+.