W tym rozdziale omówimy skrótowo przygotowanie własnej aplikacji do rozpowszechniania, tworzenie źródłowych i binarnych pakietów dystrybucyjnych oraz sposób reakcji na błędy dostrzeżone przez użytkowników. Będziemy więc:
q poznawać instalator pakietów RPM,
q korzystać z poleceń autoconf i configure przy tworzeniu plików makefile specyficznych dla danej instalacji,
q opisywać proces tworzenia pakietu RPM,
q omawiać tworzenie i dystrybucję łatek,
q poznawać śledzenie błędów zauważonych po wydaniu aplikacji.
Pisanie programów dla systemu Microsoft DOS jest bardzo proste, ponieważ program działający na jednej maszynie będzie prawdopodobnie działał także na innych. Windows wprowadza pewne ograniczenia, ponieważ trzeba pamiętać o różnych odmianach, takich jak CE (we wszelkiego rodzaju komputerkach podręcznych), NT, 9x i 2000. Pomimo tego, trzeba program skompilować dla każdej z tych platform i dostarczyć binarny plik wykonywalny.
Oprogramowanie o otwartych źródłach dostarcza nowych wyzwań, gdy dochodzi do dystrybucji ukończonych aplikacji. Ogólnie mówiąc, należy sprostać wymaganiom znacznie większej liczby platform sprzętowych i procesorów. Oprócz tego, po podjęciu decyzji o rozpowszechnianiu aplikacji jako wolnego oprogramowania należy udostępnić kod źródłowy.
Programując w systemie Linux, należy pamiętać o tym, że użytkownicy będą próbowali kompilować aplikacje na innych maszynach z systemami typu UNIX, np. FreeBSD, Solaris, HP-UX itp. Każdy z tych systemów czymś się różni od pozostałych. Często te różnice są tak duże, że uniemożliwiają skompilowanie dostarczonej aplikacji. Nawet różne dystrybucje Linuksa mają swoje pułapki, w które może wpaść nieuważny programista. Wystarczy powiedzieć, że Linux próbuje trafić na rynek i dlatego musi być adaptowany, używany i poszerzany przez innych. Dlatego właśnie należy dołożyć wszelkich starań, aby instalacja i aktualizacja utworzonej aplikacji przebiegała możliwie bez zakłóceń.
Jednym ze sposobów realizacji tego celu jest dostarczanie pakietów w postaci skompilowanej, które dają się łatwo zainstalować. Jeżeli dodatkowo dostarczony będzie pakiet źródłowy, to zainteresowani mogą przejrzeć i zmodyfikować kod. Wielu użytkowników Linuksa zna taki sposób dystrybucji oprogramowania w postaci pakietów. Jako przykład omówimy jedną z najpopularniejszych metod, a mianowicie pakiety RPM autorstwa firmy Red Hat. Przeanalizujemy te pakiety zarówno z punktu widzenia użytkownika, jak i z punktu widzenia programisty, który je musi utworzyć.
Możliwe, że opracowywana aplikacja jest budowana w sposób zależny od innych programów, na które programista nie ma wpływu. Na przykład interfejs graficzny dla debugera GDB będzie użyteczny tylko wtedy, gdy sam debuger zostanie zainstalowany. Nie tylko o to tutaj chodzi: może także wystąpić zależność od specyficznej wersji debugera.
Zamiast dołączać kopię GDB do swojej aplikacji, należy wprowadzić taką jawną zależność do pakietu binarnego. Dzięki temu użytkownik instalujący aplikację zostanie ostrzeżony, jeśli w jego systemie nie jest zainstalowany GDB lub jego wersja jest niedopasowana. W dalszej części tego rozdziału pokażemy, w jaki sposób rozwiązywane są takie zależności w pakietach RPM.
Instalowanie dostarczonej aplikacji może być tak proste i polegać np. na wstawieniu pliku binarnego do katalogu /usr/local/bin lub /opt. Musimy jednak pamiętać, że trzeba także uruchomić program konfiguracyjny, zainicjować bazę danych lub wykonać pewne czynności porządkujące przy instalacji pakietu lub przy jego usuwaniu. Pakiety w formacie RPM umożliwiają zautomatyzowanie tych wszystkich niezbędnych operacji.
Można nawet utworzyć własną dystrybucję systemu Linux, zbudowaną tak, aby pasowała i obsługiwała tylko rozpowszechnianą aplikację. Takie rozwiązanie spotyka się w praktyce w specjalistycznych aplikacjach, np. w serwerach komunikacyjnych.
Ponieważ spodziewamy się, że aplikacja rozprowadzana jako otwarte oprogramowanie będzie ulepszana przez społeczność użytkowników, to należy zastanowić się, jak wprowadzać takie modyfikacje, aby były zgodne z niezależnymi od producentów międzynarodowymi standardami, jak np. POSIX. Obsługa skomplikowanych wymagań narzucanych przez różnorodne platformy sprzętowe jest wspomagana przez dodatkowe narzędzia, dzięki którym program może działać na różnych maszynach — pokażemy tu więc zastosowanie poleceń configure i autoconf. Oczywiście, przestrzeganie standardów także może w tym wszystkim bardzo pomóc.
Istnieją wolne programy dla systemu Linux, które charakteryzują się nadzwyczaj wysoką jakością i z nimi należy konkurować. W rozdziale 2. przedstawiliśmy system CVS, który może być zastosowany w sieci do udostępniania kodu źródłowego. W tym rozdziale zapoznamy się z programem pomocniczym o nazwie patch, który może być użyty do dystrybucji poprawek kodu, zarówno niewielkich, jak i bardzo obszernych.
Popularne programy mogą budzić wielkie zainteresowanie objawiające się licznymi komentarzami na tematy ogólne, sugestiami ulepszeń i sygnalizowaniem kłopotów. Omówimy więc tu bardzo skrótowo system śledzenia błędów rozpowszechniany na zasadach GNU i noszący nazwę GNATS, wspomagający komunikację z użytkownikami.
Pierwszy raz te pakiety zastosowano w dystrybucji Linuksa przygotowanej przez firmę Red Hat. Format RPM (skrót od Red Hat Package Manager) jest obecnie stosowany na szeroką skalę jako sposób rozprowadzania aplikacji, które mają być instalowane w systemie. RPM jest dostępny w różnych dystrybucjach, takich jak Red Hat (to oczywiste!), Mandrake (dystrybucja wywodząca się z Red Hat) i SuSE (dystrybucja niezależna). Ponieważ format RPM stał się znany i ma status wolnego oprogramowania, to można się spodziewać, że pewnego dnia będzie on obsługiwany w wielu innych dystrybucjach systemów Linux i UNIX.
Istnieją także pakiety o innych formatach, w szczególności należy tu wymienić pakiety DEB używane w dystrybucjach wywodzących się z dystrybucji Debian. Wiele z podanych w tym rozdziale reguł można odnieść także do pakietów DEB. W systemach korzystających z dystrybucji Debian należy wiec zapoznać się z dokumentacją programów dpkg i dselect. Jeżeli potrzeba, narzędzia RPM można także uruchomić w dystrybucji Debian.
Użytkownik Linuksa zazwyczaj spotyka się po raz pierwszy z pakietami RPM podczas instalacji systemu. Zarówno dystrybucja Red Hat, jak i SuSE rozpowszechniane są na płytach CD-ROM wypełnionych prawie całkowicie plikami w formacie RPM. Program instalacyjny zazwyczaj wyświetla menu z nazwami dostępnych pakietów (lub ich zbiorów) i instaluje wybrane z nich. Instalację pakietów RPM wykonuje program o nazwie rpm.
Po zakończeniu instalacji w wielu dystrybucjach można znaleźć graficzny instalator pakietów. W tej książce będziemy omawiać podstawowy instalator pakietów RPM, ponieważ można go stosować jeszcze przed instalacją i uruchomieniem X Window.
Program rpm jest stosowany wówczas, gdy trzeba zmodyfikować zainstalowany system, czyli w następujących okolicznościach:
q usuwanie zbędnych pakietów,
q dodawanie tych pakietów z dystrybucji, które nie były początkowo zainstalowane,
q aktualizacja zainstalowanego pakietu (instalacja nowszej wersji),
q dodawanie nowego pakietu pochodzącego z innych źródeł.
Powyższe zadania nie są na ogół skomplikowane, lecz wymagają posiadania uprawnień superużytkownika, ponieważ podczas instalacji trzeba korzystać z obszarów systemowych w systemie plików (wyjaśnimy to za chwilę). Istnieją jednak operacje, które może wykonać zwykły użytkownik korzystający z rpm i od nich właśnie rozpoczniemy.
Program rpm może na pierwszy rzut oka onieśmielać. Po wpisaniu polecenia:
$ rpm --help
pojawi się dwustronicowa lista wszystkich opcji tego programu, przeznaczonych zarówno dla użytkownika instalującego gotowe pakiety RPM, jak i dla programisty tworzącego dystrybucyjne pakiety źródłowe lub binarne. Opiszemy tu kilka prostszych opcji, które pomagają zrealizować najczęściej spotykane zadania.
Program rpm może być uruchomiony w kilku trybach, zależnie od potrzeb użytkownika. Są to:
q tryb zapytań,
q tryb instalacji i aktualizacji pakietów,
q tryb budowania pakietów.
Do wyboru pakietu, który będzie używany jako przykład pokazujący instalację i aktualizację, użyjemy pierwszego z tych trybów. Tryb zapytań jest wywoływany za pomocą opcji -q.
Aby uzyskać listę wszystkich pakietów zainstalowanych przez program rpm, trzeba wywołać go w trybie zapytań z dodatkową opcją -a oznaczającą wszystkie pakiety:
$ rpm -q -a
aaa_base-99.11.11-2
aaa_dir-99.11.12-0
base-99.11.2-1
bash-2.03-26
bdflush-1.5-101
cpio-2.4.2-99
...
gnuchess-4.0.pl80-5
xboard-4.0.0-68
dia-0.81-1
pg_datab-6.5-21
pg_ifa-6.5.1-18
pg_iface-6.5.1-15
postgres-6.5.1-18
$
W dobrze wyposażonym systemie SuSE uzyskuje się w ten sposób listę zawierającą nazwy ponad tysiąca pakietów, które są zainstalowane. Kilka ostatnich podanych wyżej pozycji informuje, że baza danych PostgreSQL jest zainstalowana w najnowszej dostępnej wersji.
Nazwy pakietów mają następującą postać:
<nazwa_pakietu>-<wersja_pakietu>-<numer_wydania>
Nazwa pakietu jest zwykle nazwą głównej biblioteki lub programu zawartych w pakiecie. Wersja pakietu oznacza numer wersji aplikacji zawartej w tym pakiecie. Numer wydania jest powiększany za każdym razem przy budowie znowelizowanego pakietu RPM przeznaczonego do dystrybucji. Na przykład pakiet zawierający bazę danych PostgreSQL ma nazwę postgres-6.5.1-18. i jest osiemnastym kolejnym pakietem zawierającym bazę PostgreSQL w wersji 6.5.1.
Pakiety są przebudowywane z wielu powodów. Przeważnie decyduje o tym konieczność zmiany miejsca instalacji lub skryptów uruchamianych automatycznie podczas instalacji. Nowy pakiet zawierający nową wersję aplikacji zawsze ma numer wydania równy 1, tak jak w przykładowym pakiecie dia-0.81-1 na powyższej liście.
Program rpm utrzymuje swoją bazę danych zawierającą informacje o pakietach, plikach znajdujących się w tych pakietach i ich wzajemnych zależnościach, aby zachować ślad wszystkich instalacji pakietów w systemie Linux. Baza ta jest na ogół przechowywana w katalogu /var/lib/rpm. Prawie wszystkie pliki w tym katalogu są plikami bazy danych (jest to baza typu dbm używana w systemach UNIX). Program rpm umożliwia obsługę tej bazy w różny sposób.
Na tym etapie wystarczy, aby Czytelnik zdawał sobie sprawę z tego, że każde dodanie, aktualizacja lub usunięcie pakietu powoduje aktualizację bazy danych.
Kolejną informacją, którą może podać program rpm, jest lista plików zawartych w danym pakiecie. Użyjemy dwóch pakietów z podanej wcześniej listy: gnuchess i xboard (są to odpowiednio: program szachowy i jego interfejs graficzny).
$ rpm -q xboard gnuchess
Listę plików zawartych w pakiecie uzyskujemy, podając dodatkowo opcję -l:
$ rpm -q -l gnuchess
/usr/bin/game
/usr/bin/gnuan
/usr/bin/gnuchess
/usr/bin/gnuchessc
/usr/bin/gnuchessn
/usr/bin/gnuchessr
/usr/bin/gnuchessx
/usr/bin/postprint
/usr/lib/eco.pgn
/usr/lib/gnuchess.data
/usr/lib/gnuchess.eco
/usr/lib/gnuchess.lang
/usr/man/man6/game.6.gz
/usr/man/man6/gnuan.6.gz
/usr/man/man6/gnuchess.6.gz
/usr/man/man6/postprint.6.gz
Do wyszukania pakietu, w którym jest zawarty dany plik, należy w trybie zapytań użyć dodatkowej opcji -f:
$ rpm -q -f /usr/X11R6/bin/xboard
W zapytaniu można podać dowolną liczbę szukanych plików i wówczas rpm wyświetli listę wszystkich pakietów, w których są one użyte. Więcej informacji na temat użycia tych opcji można znaleźć na stronach podręcznika systemowego dotyczących programu rpm.
Zmiany w instalacji systemu Linux może wprowadzać tylko superużytkownik. Korzystając z programu rpm jako superużytkownik, trzeba zachować wyjątkową ostrożność, ponieważ można bardzo łatwo zniszczyć działający system, usuwając przypadkowo jakiś pakiet. Przykładowo usuniemy więc program o mniejszym znaczeniu, czyli interfejs do programu szachowego o nazwie xboard.
Można podjąć próbę usunięcia pakietu, podając opcję -e (od słowa erase) w wywołaniu programu rpm i nazwę usuwanego pakietu. Długie nazwy pakietów RPM są często skracane i tutaj również należy podać tylko jej pierwszy człon, czyli samą nazwę bez numerów wersji i wydania. Można tak postąpić, ponieważ w systemie zazwyczaj nie mogą współistnieć dwie wersje tego samego pakietu. Takie skrócone nazwy były także używane w poprzednich przykładach pokazujących pracę w trybie zapytań.
$ su -
Password:
# rpm -e xboard
#
Przy próbie sprawdzenia obecności pakietu pojawi się komunikat, że nie jest on zainstalowany:
# rpm -q xboard
package xboard is not installed
Teraz spróbujemy usunąć sam program szachowy gnuchess:
# rpm -e gnuchess
error: removing these packages would break dependencies:
gnuchess is needed by glchess-0.10d-67
Komunikat wyświetlony w odpowiedzi oznacza, że istnieje jeszcze jeden zainstalowany pakiet o nazwie glchess, którego działanie zależy od obecności programu gnuchess. Możemy dokładnie sprawdzić, co to za pakiet.
Informacje o pakiecie można uzyskać, podając w wywołaniu programu rpm w trybie zapytań dodatkową opcję -i (od słowa information):
$ rpm -q -i glchess
Name : glchess Relocation: (not relocateable)
Version : 0.10d Vendor: SuSE GmbH, Nuernburg, Germany
Release : 67 Build Date: Sat 13 Nov 1999 16:13:38 GMT
Install date: Sun 02 Jan 2000 17:50:14 GMT Build Host: stott.suse.de
Group : unsorted Source RPM: glchess-0.10d-67.src.rpm
Size : 171581 License: GPL
Packager : feedback@suse.de
Summary : 3D fronted for gnuchess
Description:
glchess is a fine 3D mesa fronted for gnuchess
Authors:
-------
Tomi.Sarvela@iki.fi
Widać więc, że pakiet glchess jest kolejnym interfejsem graficznym programu gnuchess wyświetlającym trójwymiarowy obraz. Przestanie on działać, jeśli usunęliśmy program gnuchess. Jeżeli trzeba usunąć z komputera wszystkie programy umożliwiające grę w szachy, to wśród nich musi się znaleźć także program glchess:
# rpm -e glchess gnuchess
Tym razem nie ma żadnych problemów. Przy jednym wywołaniu programu rpm usunięto jednocześnie dwa pakiety, podając ich nazwy w jednym poleceniu i nie spowodowało to wyświetlenia komunikatu o zakłóceniu zależności glchess od gnuchess.
Zagadnienie zależności między pakietami omówimy szerzej w dalszych częściach rozdziału.
Jeżeli istnieje plik z pakietem RPM, który trzeba zainstalować, to należy użyć opcji -i (od słowa install) w wywołaniu programu rpm. W przypadku pakietów z dystrybucji Linuksa trzeba będzie zapewne znaleźć ten plik na płycie CD-ROM. Niestety, baza danych programu rpm...
bmx_flat