Cechy pakietów w PLD

Zależności między pakietami

Istotną cechą pakietów RPM jest mechanizm tzw. zależności, dzięki nim w trakcie instalacji pakietu instalowane są automatycznie dodatkowe wymagane pakiety. Niekiedy w ramach zależności wymagana jest funkcjonalność dostarczana przez więcej niż jeden pakiet. W takim wypadku zostaniemy zapytani o to który pakiet ma być zainstalowany. Wynika to z filozofii PLD, która dopuszcza bogaty wybór oprogramowania spełniającego tą samą rolę.

Istnieją zależności wymagające wzajemnego wykluczania się pakietów, tak aby w systemie była zainstalowany był tylko jeden program z pośród kilku dostępnych. Jako przykład można wskazać serwery usług tego samego rodzaju lub pakiety zawierające w nazwie słowa "inetd" oraz "standalone".

Dodatkowo system pakietów pilnuje, aby nie można było mieć zainstalowanych dwóch wersji tego samego pakietu. Próba instalacji pakietu starszego niż ten, który mamy w systemie zakończy się niepowodzeniem, zaś przy instalacji nowszego nastąpi jego aktualizacja.

Menadżery pakietów pozwalają na ignorowanie powyższych zależności, jest to jednak operacja nie zalecana, gdyż powoduje później trudny do ogarnięcia bałagan. Wyjątki od tej zasady powinny być robione jedynie w razie uzasadnionej konieczności, takim przypadkiem jest np. aktualizacja kernela, operacja ta została opisana w tym dokumencie.

Dawniej zależności były budowane na podstawie nazw pakietów, w tej chwili stopniowo wprowadzane są zależności na podstawie plików (programów, bibliotek itd.). Zyskujemy w ten sposób elastyczność kosztem wygody w niektórych, rzadko spotykanych sytuacjach. W przypadku codziennej pracy z pakietami, nie odczujemy większych różnic i nie musimy się tym martwić.

Wymagania (requires) i własności (provides)

Ważnymi elementami mechanizmu zależności są tzw. wymagania i własności. Pierwsza z cech wskazuje listę wymaganych dodatkowo elementów (pakietów, plików) do działania instalowanej aplikacji, druga zaś informuje, które z elementów są dostarczane wraz z pakietem. Aby poznać wymagania pakietu posłużymy się Poldkiem w trybie interaktywnym:

poldek:/all-avail> desc -r logrotate Package: logrotate-3.7-2 PreReqs: /bin/sh, fileutils Requires: /bin/mail, /bin/sh, config(logrotate) = 3.7-2, crondaemon, glibc, libc.so.6, libc.so.6(GLIBC_2.0), libc.so.6(GLIBC_2.1), libc.so.6(GLIBC_2.2), libc.so.6(GLIBC_2.3), libpopt.so.0, libselinux, libselinux.so.1, popt RPMReqs: rpmlib(CompressedFileNames) <= 3.0.4-1, rpmlib(PayloadFilesHavePrefix) <= 4.0-1, rpmlib(PayloadIsBzip2) <= 3.0.5-1

Powyższe polecenie ma zadanie czysto informacyjne, gdyż jak już wspomniano zależnościami zajmie sie menedżer pakietów.

Sprawa nieco komplikuje się w przypadku własności, ponieważ w PLD nierzadko mamy dostępnych wiele pakietów spełniających podobne wymagania. Aby sprawdzić dostarczaną funkcjonalność ponownie użyjemy Poldka:

poldek:/all-avail> desc -p vixie-cron Package: vixie-cron-4.1-7 Provides: config(vixie-cron) = 4.1-7, crondaemon, crontabs >= 1.7, group(crontab)

Analizując powyższe przykłady można dopatrzyć się informacji o dostarczaniu własności crondaemon przez vixie-cron, która z kolei jest wymagana przez logrotate.

Własność crondaemon jest dostarczana przez większą ilość pakietów, możemy samodzielnie wybierać, który z pakietów ma być instalowany lub ustawić automatyczny wybór. O tym decyduje ustawienie opcji choose equivalents manually w konfiguracji Poldka. Jeśli ustawimy opcję na yes (zalecane) to instalacja programu może wyglądać następująco:

poldek:/all-avail> install logrotate Przetwarzanie zależności... Więcej niż jeden pakiet udostępnia właściwość "crondaemon": a) anacron-2.3-22 b) fcron-3.0.0-3 c) hc-cron-0.14-22 d) vixie-cron-4.1-7 Which one do you want to install ('Q' to abort)? [b]

Na powyższym przykładzie widać listę pakietów mogących pełnić funkcję demona zegarowego (crondaemon), dodatkowo podana jest domyślna wartość wyboru, nie zawsze jest to najlepszy wybór dla konkretnej instalacji, dlatego powinniśmy się upewnić, że wybieramy najwłaściwszy pakiet. Więcej informacji o obsłudze i konfiguracji Poldka odnajdziemy w tym dokumencie.

Zawartość pakietów

Pakiety mogą zawierać wiele małych programów i/lub bibliotek albo jeden duży program może być podzielony na kilka pakietów. W PLD najczęściej stosowane jest to drugie rozwiązanie: osobno przechowywane są pliki uruchomieniowe, osobno biblioteki, a jeszcze osobno moduły, wtyczki i dodatki. Ponadto jeśli tylko można to są umieszczane w pojedynczych pakietach, dzięki temu unikamy dużych, zbiorczych paczek. Pozwala to instalować tylko to co jest nam potrzebne. Przykładowo jeśli program ABC wymaga bibliotek programu XYZ to instalujemy tylko pakiet z bibliotekami tego drugiego. Skraca to czas instalacji (zwłaszcza przy pobieraniu plików z Internetu) i pozwala oszczędzać miejsce na dysku.

Nierzadko do osobnych pakietów trafiają elementy aplikacji, które zostały przewidziane przez jej twórców jako kompletna instalacja. Nie należy się tego obawiać, gdyż mechanizm zależności wymusi instalację wszystkich wymaganych dodatkowo pakietów.

Tak silne rozdrobnienie powoduje czasami, że do przy instalacji mechanizm zależności zaznacza sporą ilość dodatkowych pakietów. Potrafi to wprowadzić w konsternację, jednak nie należy się tego obawiać, gdyż są to zazwyczaj małe pakiety i po zainstalowaniu zajmują tyle samo lub mniej niż domyślna instalacja.

Aby ułatwić poruszanie się w tym gąszczu, możemy posłużyć się opisami pakietów:

poldek:/all-avail> desc proftpd-inetd

lub listami plików dostarczanych przez pakiet:

poldek:/all-avail> desc -f proftpd-inetd

Zdarza się, że znamy nazwę pliku, ale nie wiemy w jakim pakiecie się znajduje. Do odnalezienia pakietu posłużymy się poleceniem:

poldek:/all-avail> search -f */sendmail

Dodatkowo możemy korzystać z zamieszczonej dalej tabeli.

Konwencja nazw pakietów w PLD

Nazwy pakietów mają następującą budowę: {$nazwa}-{$wersja}.{$arch}.rpm np.: 0verkill-0.16-3.i686.rpm. Tak wyglądają nazwy pakietów w systemie plików lub na serwerze FTP. W menedżerach pakietów posługujemy się jedynie nazwą lub nazwą i wersją (nie licząc instalacji za pomocą rpm-a).

Nazwa pakietu	Zawartość
program, program-core	główny pakiet programu, zawiera pliki wykonywalne, dokumentację, skrypty startowe w przypadku usług, niekiedy biblioteki
program-common	podstawowe, wspólne pliki; zwykle samodzielny taki pakiet jest bezużyteczny i wymaga zainstalowania dodatkowych pakietów
program-libs	zestaw bibliotek stworzonych na potrzeby danego programu, są niekiedy wymagane przez inne programy
program-tools, program-utils, program-progs	dodatkowe narzędzia, zwykle nie są konieczne do podstawowej pracy programu
program-extras	dodatkowe, rzadziej używane elementy
program-mod, program-plugin, program-applets, program-addon	różnej maści moduły, "wtyczki", applety i dodatki przeważnie nie są konieczne do podstawowej pracy programu
program-skin(s), program-theme(s)	"skórki" i "tematy" modyfikujące wygląd programu
program-driver	sterowniki
program-backend	specjalne interfejsy służące do rozszerzania możliwości programu, łączenia z innymi programami, sprzętem itp.
program-i18n	dodatkowe wersje językowe
program-doc	dokumentacja programu
program-devel	pakiety potrzebne dla programistów i osób które zajmują się własnoręczną kompilacją programów, bądź budowaniem pakietów.
program-static	program skompilowany statycznie - nie wymaga bibliotek
program-debuginfo	informacje dla debuggera - pliki użyteczne tylko dla osób badających problemy z działaniem programu
lib_nazwa_biblioteki	zestaw uniwersalnych bibliotek, nie związanych z żadnym konkretnym programem.
usługa-inetd, usługa-standalone	alternatywne pakiety służące do wyboru trybu pracy niektórych usług. Należy wybrać jeden z nich: uruchamianie przez Inetd lub praca w tle (standalone). Pakiety te wzajemnie się wykluczają na poziomie mechanizmu zależności.
usługa-init	skrypty startowe programu
metapackage-program	metapakiet
program-legacy	starsze wersje programów lub sterowniki do starszych urządzeń
kernel	pakiety okołokernelowe, zostały omówione w tym dokumencie

Metapakiety

Wadą silnego rozdrobnienia pakietów jest pracochłonne zarządzanie, aby temu zaradzić stworzono tzw. metapakiety, zwane również pakietami wirtualnymi. Są to pakiety zawierający jedynie wymagania (requires), nie zawierają żadnych plików, ani własności (provides). Ich zadaniem jest zautomatyzowana instalacja większych grup pakietów oraz utrzymanie wstecznej zgodności w nazwach.

Część metapakietów łatwo odnajdziemy dzięki nazwie, która zawiera słowo metapackage, np. metapackage-gnome. Aby poznać listę wymagań takiego pakietu, użyjemy opisanego nieco wcześniej polecenia desc -r trybu interaktywnego Poldka.

Komunikaty

Prace przy zarządzaniu pakietami niekiedy kończą się komunikatami skierowanymi do administratora, są to dość ważne informacje, dlatego powinniśmy je uważnie czytać. Zazwyczaj dotyczą plików konfiguracji, zarządzania użytkownikami/grupami, modyfikacji systemu rc-skryptów oraz zalecenia dalszego postępowania po instalacji pakietu. Dla przykładu poniżej przedstawiono komunikaty wyświetlane po instalacji Exim-a:

Adding group exim GID=79. Adding user exim UID=79. Run "/etc/rc.d/init.d/exim start" to start exim daemon.

Wpływ pakietów na pracę systemu

Pakiety, oprócz plików programu, zawierają dokumentację, przykładowe pliki konfiguracji, strony podręcznika systemowego (man, info) oraz automatykę. Owa automatyka jest uruchamiana w trakcie instalowania bądź odinstalowania pakietu i wykonuje konieczne prace w systemie, dzięki czemu zmniejsza się nakład pracy administratora do absolutnego minimum. Jest tak skonstruowana, aby nie zaskakiwać administratora w najmniej oczekiwanych momentach oraz zapewnić nieprzerwanie działanie systemu, poniżej przedstawiono kilka przykładów jej działania.

Jeśli instalujemy w systemie jakąś usługę to zostanie zapisana odpowiednia informacja do skryptów startowych i nowe oprogramowanie uruchomi się przy najbliższej zmianie trybu pracy lub restarcie systemu. Jeżeli jakaś usługa jest wyłączona z działania i nastąpi jej aktualizacja, to w dalszym ciągu nie będzie uruchamiana.

Jeśli działa usługa, a my ją zaktualizujemy lub doinstalujemy dodatkowy moduł, to zostanie ona automatycznie zrestartowana lub taka operacja zostanie zasugerowana przez pakiet. Będzie to zależało od ustawienia opcji RPM_SKIP_AUTO_RESTART w konfiguracji rc-skryptu lub globalnie w /etc/sysconfig/rpm - opcja przyjmuje wartość yes/no. Konfigurację rc-skryptów dokładniej omówiono w tym dokumencie.

Wpływ pakietów na pliki konfiguracji

Po aktualizacji pakietu nie są naruszanie istniejące pliki konfiguracji, nowe wersje tych plików są zapisywane z rozszerzeniem ".rpmnew". Przykładowo po zaktualizowaniu pakietu sudo obok pliku /etc/sudoers pojawi się nowy plik o nazwie /etc/sudoers.rpmnew, tak więc zaktualizowany program będzie używał starego pliku konfiguracji. W większości wypadków nie będzie to stanowić problemu, jednak dla pewności należy skonfigurować plik dostarczony z nowszym pakietem na wzór poprzedniej konfiguracji i zmienić mu nazwę poprzez usunięcie omawianego rozszerzenia. Jest to pierwsza rzecz, którą należy sprawdzić w razie problemów z działaniem programu po aktualizacji.

Kiedy odnajdziemy plik *rpmnew to możemy łatwo sprawdzić czym różni się jego zawartość w stosunku do obecnie używanego pliku konfiguracji. Posłużymy się w tym celu programem diff z pakietu diffutils np.:

# diff jakis_plik.conf jakis_plik.conf.rpmnew

W przypadku niektórych programów, po odinstalowaniu pakietu, pozostawiane są jego pliki konfiguracji, posiadają one rozszerzenie ".rpmsave", możemy je zachować lub skasować jeśli uznamy że są nam zbędne.

Osoby chcące trzymać porządek w systemie powinny zajmować się plikami .rpmnew i .rpmsave od razu po pracy z menadżerem pakietów. Pliki łatwo odnajdziemy, gdyż występują zwykle w katalogu /etc, odszukamy je następująco:

$ find /etc -name "*rpmnew" $ find /etc -name "*rpmsave"