Bociek PLD - Pisarz
I. Informacje podstawowe
II. Instalacja
III. Podręcznik użytkownika
IV. Podręcznik administratora
Zarządzanie pakietami
Źródła pakietów
V. Tworzenie PLD - Praktyczny poradnik
VI. O podręczniku
O tej książce
Spis treści
Inne wersje tego dokumentu
PDF
HTML (jeden plik)
TXT
Odnośniki
Tworzymy dokumentację PLD
Strona PLD
Listy dyskusyjne PLD

Źródła pakietów

<- ->
 

W PLD jest kilka grup pakietów (źródeł) w ramach tej samej wersji dystrybucji, różnią się one wersjami pakietów i zastosowaniem. Ich listę uzyskamy za pomocą Poldka:

$ poldek -l

W większości wypadków, będziemy korzystać z głównego źródła (main), jednak od czasu do czasu potrzeba zaktualizować system lub pobrać niestandardowe wersje pakietów, właśnie wtedy z nich skorzystamy. Źródła są oznaczane za pomocą etykiet:

  • main (np. th): główne źródło pakietów (domyślne), zawiera stabilne wersje, od chwili wydania danej wersji dystrybucji, nie są tu dokonywane żadne zmiany

  • obsolete (np. th-obsolete): stare pakiety, usunięte z main w wyniku aktualizacji. Dzięki temu źródłu, możemy wrócić do starszej wersji pakietu, jeśli zajdzie taka konieczność. Źródło wprowadzone w Th.

  • test (np. th-test): trafiają tu pakiety prostu z builderów, bez sprawdzenia czy w ogóle działają i czy są spełnione zależności. Używanie pakietów z tego źródła jest dosyć ryzykownym krokiem, dlatego należy go wykonywać wyłącznie w ostateczności

  • ready (np. th-ready): następny krok w życiu pakietu, jeśli pakiety działają bez zarzutu, to są przenoszone razem z zależnościami do main. Pakiety te są już wstępnie przetestowane, nadal jednak powinniśmy zachować ostrożność instalując pakiety z tego katalogu

  • debuginfo (np. th-debuginfo, th-ready-debuginfo): pakiety zawierające wyłącznie symbole potrzebne przy debugowaniu. Pakiety te są pomocne dla programistów i deweloperów.

  • home: źródło lokalne, pozwala łatwo instalować pakiety z katalogu ~/rpm/RPMS - miejsca domyślnego umieszczania własnoręcznie zbudowanych pakietów.

Multilib

W środowisku x86_64 możemy używać także aplikacji 32 bitowych, aby wygodnie instalować pakiety zostały przygotowane źródła multilib /etc/poldek/repos.d/pld-multilib.conf. Domyślnie są przygotowane dla i686.

Źródła używane w starszych wersjach PLD:

  • updates (np. ac-updates) - aktualizacje, zaleca się regularne sprawdzanie czy nie pojawiają się tu nowe pakiety, źródło stało się zbędne w Th i nie jest używane. W Th w roli updates używa się źródła ready. W Ra istniały dwa niezależne źródła pakietów z aktualizacjami: {$wersja}-updates-security i {$wersja}-updates-general. W Ac nastąpiło ich połączenie i od tej pory źródło nazywa się {$wersja}-updates.

  • supported (np. ac-updates) - nietypowe pakiety, które nie powinny być trzymane w głównym źródle. Są tu umieszczane pakiety rzadko używane lub starsze wersje, podobnie jak updates przestało mieć rację bytu w Th.

Aby wybrać źródło inne niż domyślne należy użyć parametru -n np.:

$ poldek -n th -n th-ready

Należy pamiętać, że użycie każdego źródła będzie możliwe dopiero po pobraniu aktualnych indeksów:

$ poldek -n debuginfo --up

Ścieżki do podstawowych źródeł w konfiguracji Poldka

Poldek jest dostarczany z właściwie skonfigurowanymi etykietami, są one zdefiniowane w plikach /etc/poldek/source.conf i /etc/poldek/repos.d/pld.conf. Adresy oficjalnych serwerów i mirrorów znajdziemy w tym dokumencie. Etykieta źródła rozpoczyna się od przedrostka określającego wersję dystrybucji, zapisaną małymi literami, poniżej przedstawiono ją jako ciąg {$wersja}, który może mieć wartość np. ra, ac lub th. Ciąg {$arch} to architektura pakietów.

  • main: dists/{$wersja}/PLD/{$arch}/PLD/RPMS

  • obsolete: dists/{$wersja}/obsolete/{$arch}/RPMS

  • test: dists/{$wersja}/test/${arch}/

  • ready: dists/{$wersja}/ready/${arch}/

  • home: katalog lokalny: ~/rpm/RPMS

Cykl życia pakietu

Zbudowany pakiet trafia do test gdzie oczekuje na zbudowanie zależności, następnie jest przenoszony przez RM-a do ready. kiedy wszytko jest w porządku trafia w końcu do main/updates. W przypadku bardziej krytycznych pakietów kiedy pojawia się aktualizacja to starsza wersja trafia do obsolete. Proces ten został szerzej opisany w podręczniku dewelopera.

 
<- ->