Life below the fold

O rozdziale kościoła od państwa

Posted on 20 August 2006 by smyru

Ponieważ dostrzegam czasami wśród użytkowników Linuksa nieporozumienia płynące z błędnego rozumienia sztandarowego polecenia FreeBSD make world, w wolnej chwili przygotowałem taki schemat…

Więc tak. W przypadku Debiana* i chyba wszystkich innych dystrybucji Linuksa — całe oprogramowanie instalowane przy pomocy rdzennych narzędzi do zarządzania pakietami traktowane jest jako część tejże dystrybucji. Stąd właściwie brak ścisłego rozróżnienia pomiędzy tym, co jest częścią systemu, a tym, co nią nie jest.

Natomiast we FreeBD rozdział kościoła od państwa jest bardzo wyraźny. I tak. Za FreeBSD uważa się jedynie kernel (jądro) oraz tzw. userland, na który składa się toolkit i inne niezbędne podstawowe oprogramowanie. Ten zestaw z założenia rozprowadzany jest na zmodyfikowanej licencji BSD. W pewnych miejscach są od tego oczywiście wyjątki i to nawet spore, aczkolwiek jedynie w userlandzie i niezmienne jest dążenie, aby wyjątki te eliminować w miarę możliwości projektu. Stało się tak np. z programem tar, który do niedawna był zaimportowanym gtar, obecnie zastąpionym przez parę bsdtar i libarchive.

Takie importowane oprogramowanie, którego podstawowy rozwój odbywa się poza projektem FreeBSD traktowane jest jako tzw. contrib i przechowywane jest w wydzielonych katalogach repozytorium CVS. Poza stadem GNU mieści się tu także sendmail, BIND, tcsh, tcpdump, openssh i inne — przy czym należy powiedzieć, że ze względu na ich licencje — dalece bardziej liberalne niż GPL — nie ma zamierzeń, aby eliminować je z systemu.**

Powyższy zestaw — kernel + userland — składa się właśnie na to, co nazywamy FreeBSD. I jedynie on jest instalowany w czasie podstawowej instalacji systemu.*** On także podlega aktualizacji przy pomocy make kernel (dla jądra) i make world (dla userlandu) po sprowadzeniu nowych źródeł przy pomocy cvsup lub cvs. Taka aktualizacja dotyczy jedynie podstawowego systemu — base systemu FreeBSD.

Jakiekolwiek inne oprogramowanie dostępne na FreeBSD obsługiwane jest poprzez mechanizm portów. Czy to vim, bash, X, GNOME, KDE czy OpenOffice.org. Wszystkie te aplikacje dostępne są na bazie portów. Jest to system do instalacji, zarządzania i usuwania oprogramowania oparty na źródłach. W założeniu porty kompilowane są lokalnie w oparciu o przygotowane łatki, szkielet oparty na BSD make, który pozwala użytkownikowi na wybór opcji konfiguracji i kompilacji, uwierzytelnia sprowadzane źródła, obsługuje zależności, rejestruje zainstalowane pliki wraz z sumami kontrolnymi i wykonuje wszelkie inne operacje, jakich oczekuje się od dobrego systemu zarządzania pakietami. W terminologii FreeBSD za pakiet uważa się skompilowany i zainstalowany lub spakowany do instalacji port. Takie prekompilowane z domyślnymi opcjami pakiety binarne dostępne są na serwerach ftp projektu.

Podczas, gdy kod całego FreeBSD — w tym niezbędnych narzędzi z działu contrib — jest w całości przechowywany w repozytorium CVS, w przypadku aplikacji z portów w CVS znajdują się jedynie przygotowane dla nich szkielety portów — pliki dla make oraz łatki — zaś źródła do kompilacji pobierane są z serwerów autorów oprogramowania w postaci tarballi. Przy czym podobnie jak w Slackware, w portach znajdują się jedynie takie łatki, które są niezbędne do uruchomienia danej aplikacji na FreeBSD. Z założenia oprogramowanie w portach znajduje się w postaci generic takiej, w jakiej publikowane jest przez swego autora. Polityka ta różni się zasadniczo od stosowanej przez większość linuksowych dystrybucji, które znacząco modyfikują dystrybuowane w swych ramach programy.

Podejście FreeBSD do oprogramowania third party różni się od dystrybucji linuksowych także w tym względzie, że porty z założenia mają status current. Oznacza to ni mniej ni więcej, że opiekun portu dba, aby dostępna w nim była najnowsza, stabilna wersja aplikacji. Dla wersji rozwojowych — o ile ma to sens praktyczny — tworzy się porty o sufiksie -devel. Tymczasem w Debianie rozwój właściwego systemu i działających nań aplikacji postępuje jednocześnie i jest publikowany jednocześnie. Natomiast we FreeBSD porty aplikacji dla wszystkich wspieranych obecnie wersji 4.11, 5.5, 6.1 czy rozwojowej 7-CURRENT są identyczne, a instalowane poprzez porty**** aplikacje będą działać na każdej z nich. Można mieć tym samym nowy soft na “starym” FreeBSD 4.11 albo odwrotnie, jeśli nie aktualizuje się portów/pakietów starsze oprogramowanie na świeżo zaktualizowanym FreeBSD 6.1.

Podobnie jak w Debianie i mu podobnym, ale w przeciwieństwie do innych dystrybucji Linuksa, system portów (i zależnych odeń pakietów) jest zcentralizowany. Można natrafić na udostępniane poza projektem pakiety dla FreeBSD, jednak należy to do rzadkości w przeciwieństwie do nieuporządkowanego świata RPM’ów.

Jak już wspomniałem pakiety nie są aktualizowane w trakcie make world. Do zarządzania nimi służą systemowe narzędzia pkg_*. Aktualizacja pakietów przebiega dwuetapowowo. Najpierw przeprowadza się aktualizację bazy portów, tj. znajdującej się w katalogu /usr/ports struktury podkatalogów-kategorii i umieszczonych w nich definicji dla poszczególnych programów. Zaktualizować ją można na kilka sposobów podobnie jak system przy pomocy cvsup lub nowszym, szybszym i wygodniejszym dla szeregowych użytkowników portsnap. Po czym w oparciu o nią i przy pomocy np. portupgrade***** — rozbudowanego wrappera systemowych użytków pkg_* — dokonuje się aktualizacji zainstalowanych paczek, wykonując po prostu: portupgrade –a.

Ta dwuetapowa procedura odpowiada niejako apt-get update i apt-get upgrade z zastrzeżeniem, że w Debianie oznacza ona równocześnie uaktualnienie pakietów, które składają się na podstawowy, niewydzielony system (jądro i okolice). Tymczasem we FreeBSD base system nie jest pakietowany! I tym samym nie może być w ten sposób uaktualniony. Dziwne?

Przypisy

1. Posługuję się tutaj na potrzeby porównania analogiami do Debiana, bowiem jest to najlepiej przeze mnie rozpoznana dystrybucja Linuksa.
2. Jakiś czas temu z base systemu wyeliminowano perla, jednak przyczyną tego były przyczyny organizacyjne wynikające z trudności z jego aktualizacją. Od tamtej pory perl jest instalowany jako pakiet przy pomocy portów, co także moim zdaniem jest rozwiązaniem o wiele bardziej eleganckim i efektywnym.
3. Wyjątek obok wspomnianego wcześniej perla stanowi tu Xwindow, które przestało być uważane za część contrib i na życzenie użytkowika może być zainstalowane w podstawowym procesie instalacji, ale nie jest aktualizowane poprzez make world.
4. Oczywiście udostępniane prekompilowane pakiety binarne sa zależne on wersji systemu. Jednak należy pamiętać, że podstawowym sposobem instalacji i dystrybucji oprogramowania na FreeBSD są porty, zaś pakiety są jedynie ich drugorzędnym uzupełnieniem, a ich kompilowane z domyślnymi opcjami wersje na serwerach ftp zawsze są w pewnym stopniu zapóźnione w stosunku do tych znajdujących się w portach ze względu na czas niezbędny do rekompilacji zaktualizowanych portów na wszystkie wspierane platformy sprzętowe i wersje FreeBSD
5. Portupgrade samo w sobie jest portem i nie jest częścią base systemu. Istnieją także inne narzędzia służące do aktualizacji pakietów. Portupgrade w chwili obecnej jest najpopularniejsze.

Chętnym na dłuższą lekturę po angielsku polecam: BSD for Linux Users.

Categorized As

FreeBSD, GNOME, Internet, Język, Komputery, Kuchnia, Linux, Płock, Rowery, Ta meta, Warszawa, Wrocław, X, Życie