[OpenBSD]

[Spis treści] [Sekcja 14 - Konfiguracja dysków]

15 - System portów i pakietów OpenBSD


Spis treści

15.1 - Wprowadzenie

Dostępna jest znaczna ilość zewnętrznych aplikacji które niektórzy mogą chcieć wykorzystać w swoim systemie OpenBSD. Aby ułatwić zarządzanie i instalację tego oprogramowania, a także uwzględnić politykę bezpieczeństwa i założenia systemowe OpenBSD, zewnętrzne oprogramowanie jest przenoszone na OpenBSD. Wysiłek w przenoszenie aplikacji związany jest z wieloma rzeczami. Przykładami są: sprawienie by oprogramowanie korzystało ze standardowego układu katalogów OpenBSD (tj. pliki konfiguracyjne trafiają do /etc), dostosowania specyfikacji bibliotek współdzielonych OpenBSD, sprawienie by aplikacja była bezpieczna na tyle na ile to możliwe, itd.

Rezultatem tych działań są gotowe do instalacji binarne pakiety. Celem systemu pakietów jest śledzenie jakie pakiety zostały zainstalowane, tak by mogły być w każdej chwili z łatwością zaktualizowane lub usunięte. W ten sposób, żadne zbędne pliki nie są zostawiane, a użytkownicy utrzymują swoje systemy w porządku. System pakietów pozwala także mieć pewność że nic nie zostanie skasowane przez przypadek, sprawiając że oprogramowanie przestanie działać poprawnie. Dodatwą zaletą jest to że użytkownicy rzadko muszą kompilować programy ze źródeł, ponieważ pakiety zostały już skompilowane, są dostępne i gotowe do użycia w systemie OpenBSD. W kilka minut, duża liczba pakietów może być pobrana i zainstalowana, ze wszystkim we właściwym miejscu.

Pakiety i kolekcja portów NIE przechodzą tego samego audytu bezpieczeństwa który jest wykonywany na bazowym systemie OpenBSD. Aczkolwiek dokładamy wszelkich starań by utrzymać jakość kolekcji pakietów na wysokim poziomie, nie posiadamy wystarczających zasobów ludzkich by zapewnić ten sam poziom świeżości i bezpieczeństwa. Oczywiście aktualizacje bezpieczeństwa dla różnych aplikacji są włączane do drzewa portów tak szybko jak to tylko możliwe, a także wykonywane są odpowiednie aktualizacje bezpieczeństwa pakietów jak to zostało opisane poniżej.

15.2 - Zarządzanie pakietami

15.2.1 - Jak to działa?

Pakiety są pre-kompilowanymi binariami niektórych z najczęściej wykorzystywanych programów. Pakietami można łatwo zarządzać przy pomocy kilku narzędzi, także odnoszących się do narzędzi pkg* (pkg* tools):

W zależności od kolejności uruchomienia, aplikacja X może wymagać by zainstalowane były aplikacje Y i Z. Mówimy wówczas że aplikacja X jest zależna od tych aplikacji, i z tego powodu aplikacje Y i Z są nazywane zależnościami X. Z kolei, Y może wymagać innych aplikacji P i Q, natomiast Z może wymagać do poprawnego działania aplikacji R. W ten sposób tworzone jest całe drzewo zależności.

Pakiety wyglądają jak zwykłe paczki .tgz. W zasadzie są nimi, ale istnieje jedna podstawowa różnica: zawierają dodatkową informację o pakiecie. Informacja ta jest wykorzystywana przez pkg_add(1) do kilku celów:

15.2.2 - Ułatwienia: PKG_PATH

Możesz sprawić by rzeczy były naprawdę proste poprzez użycie zmiennej środowiskowej PKG_PATH Po prostu wskaż twoją ulubioną lokalizację, a pkg_add(1) będzie automatycznie sprawdzał czy znajduje się w niej pakiet który podałeś, a także automatycznie pobierał i instalował niezbędne zależności pakietu.

Lista możliwych lokalizacji do pobierania pakietów jest dostępna w tej sekcji.

Przykład 1: pobieranie pakietu z CDROM, zakładając że jest podmontowany w /mnt/cdrom

$ export PKG_PATH=/mnt/cdrom/4.2/packages/`machine -a`/

Przykład 2: pobieranie pakietu z najbliższego mirrora FTP

$ export PKG_PATH=ftp://twoj.mirror.ftp/pub/OpenBSD/4.2/packages/`machine -a`/

Zazwyczaj bardzo dobrym pomysłem jest dodanie linii podobnych do podanych powyżej do twojego ~/.profile. Podobnie jak w przypadku klasycznych zmiennych PATH, możesz podać wiele lokalizacji, oddzielając je dwukropkami. Jednakże, każda ścieżka w zmiennej PKG_PATH MUSI być zakończona slashem (/). W ten sposób pkg_add(1) może poprawnie rozróżnić ścieżki nawet jeśli zawierają URLe zawierające dwukropki. Jeśli zawiedzie pierwszy wpis w PKG_PATH, zostanie sprawdzony następny, i tak dalej, aż pakiet nie zostanie znaleziony. Jeżeli zawiodą wszystkie wpisy, system zwróci błąd.

Zwróć uwagę na użycie machine(1) w powyższych poleceniach. Spowoduje to automatyczne wstawienie twojej "architektury aplikacyjnej", co zazwyczaj, chociaż nie zawsze, oznacza nazwę twojej platformy. Oczywiście jeżeli korzystasz ze snapshotów, musisz zastąpić "4.2" "snapshots".

15.2.3 - Wyszukiwanie pakietów

Duża kolekcja pakietów dostępna jest dla najbardziej powszechnych architektur. Poszukaj pakietów w jednym z tych miejsc:

Jeżeli posiadasz drzewo portów w twoim systemie, możesz szybko znaleźć pakiet którego szukasz jak zostało to opisane w Przeszukiwanie drzewa portów.

Prawdopodobnie zwróciłeś już uwagę na to, że niektóre pakiety dostępne są w kilku wariacjach, formalnie nazywanych smakami. Inne są kawałkami tej samej aplikacji, które mogą być instalowane osobno. Są one nazywane podpakietami. Bardziej szczegółowo omówimy to później w Korzystanie ze smaków i podpakietów ale smaki oznaczają, że zostały skonfigurowane z różnymi zestawami opcji. Obecnie, wiele pakietów posiada smaki, przykładowo: wsparcie dla baz danych, wsparcie systemów bez X-ów, brak pewnych funkcjonalności sieci takich jak SSL czy IPv6. Każdy smak pakietu ma różny przyrostek w nazwie pakietu. Więcej informacji o nazwach pakietów znajdziesz w packages-specs(7).

Uwaga: Nie wszystkie możliwe pakiety są dostępne na serwerach FTP! Niektóre aplikacje po prostu nie działają na wszystkich architekturach. Niektóre aplikacje nie mogą być rozpowszechniane przez FTP (lub CDROM) ze względu na ograniczenia licencyjne. Może być dostępnych wiele kombinacji portów i pakietów, a projekt OpenBSD nie posiada wystarczających środków by zbudować je wszystkie ze źródeł. Więcej informacji o tym jak można to wykonać znajdziesz w Korzystanie ze smaków i podpakietów w części dotyczącej Portów w tym dokumencie.

15.2.4 - Instalacja nowych pakietów

W procesie instalacji wykorzystywane jest narzędzie pkg_add(1). Jeżeli ułatwiłeś sobie sprawy z portami poprzez ustawienie zmiennej środowiskowej PKG_PATH, możesz po prostu wywołać polecenie pkg_add(1) z nazwą pakietu, tak jak to pokazuje poniższy przykład.
$ sudo pkg_add -v screen-4.0.3p0
parsing screen-4.0.3p0
installed /etc/screenrc from /usr/local/share/examples/screen/screenrc | 71%
screen-4.0.3p0: complete

W tym przykładzie flaga -v została użyta by otrzymać bardziej gadatliwe wyjście. Opcja ta nie jest konieczna, lecz jest użyteczna podczas debugowania i została użyta tutaj aby nieco dokładniej pokazać co właściwie robi pkg_add(1). Zwróć uwagę na wiadomość wspominającą /etc/screenrc. Wprowadzenie większej ilości -v spowoduje wyświetlenie jeszcze bardziej szczegółowego wyjścia.

Korzystanie z interaktywnego trybu pkg_add(1)

Od OpenBSD 3.9, pkg_add(1) posiada tryb interaktywny, uruchamiany poprzez wywołanie z flagą -i, i spowoduje zadawanie ci pytań gdy nie będzie w stanie podjąć decyzji samodzielnie. Przykładowo, jeżeli nie wiesz jakie są dostępne wersje pakietów, możesz spróbować w ten sposób:
$ sudo pkg_add -i screen
Ambiguous: screen could be screen-4.0.3p0 screen-4.0.3p0-shm screen-4.0.3p0-static
Choose one package
         0: <None>
         1: screen-4.0.3p0
         2: screen-4.0.3p0-shm
         3: screen-4.0.3p0-static
Your choice: 1
screen-4.0.3p0: complete

Dla niektórych pakietów, pewne ważne informacje dodatkowe dotyczące konfiguracji lub korzystania zostaną podane podczas instalacji. Ponieważ są ważne, zostaną wyświetlone niezależnie od tego czy użyjesz flagi -v: Rozważmy poniższy przykład:

$ sudo pkg_add ghostscript-fonts-8.11
ghostscript-fonts-8.11: complete
You may wish to update your font path for /usr/local/share/ghostscript/fonts
--- ghostscript-fonts-8.11 -------------------
To install these fonts for X11, just make sure that the fontpath
lists the 75dpi or 100dpi bitmap fonts before the ghostscript fonts,
and make sure you have the string ":unscaled" appended to the bitmap
font's fontpath. This way, the bitmap fonts will be used if they
match, and the Type 1 versions will be used if the font needs to be
scaled. Below is the relevant section from a typical xorg.conf file.

   FontPath   "/usr/X11R6/lib/X11/fonts/misc/"
   FontPath   "/usr/X11R6/lib/X11/fonts/75dpi/:unscaled"
   FontPath   "/usr/X11R6/lib/X11/fonts/100dpi/:unscaled"
   FontPath   "/usr/local/lib/X11/fonts/ghostscript/"
   FontPath   "/usr/X11R6/lib/X11/fonts/Type1/"

Zobaczmy teraz przykład z pakietem który posiada zależności:

$ sudo pkg_add -v tin-1.8.2p0
 parsing tin-1.8.2p0
 Dependencies for tin-1.6.2 resolve to: gettext-0.14.6, libutf8-0.8, pcre-6.4p1, libiconv-1.9.2p3 (todo:
libiconv-1.9.2p3,gettext-0.14.6,pcre-6.4p1,libutf8-0.8)
 tin-1.8.2p0:parsing libiconv-1.9.2p3
 tin-1.8.2p0:libiconv-1.9.2p3: complete
 tin-1.8.2p0:parsing gettext-0.14.6
 Dependencies for gettext-0.14.6 resolve to: expat-2.0.0, libiconv-1.9.2p3 (todo: expat-2.0.0)
 tin-1.8.2p0:parsing expat-2.0.0
 tin-1.8.2p0:expat-2.0.0: complete
 tin-1.8.2p0:gettext-0.14.6: complete
 tin-1.8.2p0:parsing pcre-6.4p1
 tin-1.8.2p0:pcre-6.4p1: complete
 tin-1.8.2p0:parsing libutf8-0.8
 tin-1.8.2p0:libutf8-0.8: complete
 tin-1.8.2p0: complete
Ponownie dodaliśmy flagę -v aby zobaczyć więcej. Po sprawdzeniu informacji o pakiecie, znalezione zostały zależności i są one instalowane najpierw. Możesz także zobaczyć że instalowany jest także pakiet gettext, który zależy od libiconv. Przed instalacją gettext, sprawdzana jest informacja tego pakietu i sprawdzane jest czy libiconv jest już zainstalowany w systemie.

Możliwe jest określenie wielu nazw pakietów w jednej linii, co oznacza że wszystkie zostaną zainstalowane razem, z możliwymi zależnościami.

Jeśli z jakiegoś powodu zdecydowałeś się nie korzystać z PKG_PATH, jest także możliwe podanie absolutnej lokalizacji pakietu w linii poleceń. Ta absolutna lokalizacja może być ścieżką lokalną, lub URLem odnoszącym się do FTP, HTTP, lub lokalizacji SCP. Rozważmy instalację z FTP:

$ sudo pkg_add ftp://ftp.openbsd.org/pub/OpenBSD/4.2/packages/`machine -a`/screen-4.0.3p0.tgz
screen-4.0.3p0: complete

W tym przykładzie pominęliśmy flagę -v, zatem tylko niezbędne wiadomości zostały wyświetlone. Zauważ że została podana pełna nazwa pliku przez dodania rozszerzenia .tgz. Możesz także pominąć rozszerzenie, podobnie jak we wcześniejszych przykładach, ponieważ pkg_add(1) użyje auto-dopełnienia.

Uwaga: Nie wszystkie architektury mają dostępne takie same pakiety. Niektóre porty nie działają na niektórych platformach, a wydajność limituje liczbę pakietów które mogą być zbudowane na innych.

Dla bezpieczeństwa, jeżeli instalujesz pakiet który zainstalowałeś wcześniej (lub w starszej jego wersji) i go usunąłeś, pkg_add(1) nie nadpisze plików konfiguracyjnych które zostały zmodyfikowane. Zamiast tego poinformuje cię o tym jak poniżej (tylko jeżeli użyta została flaga -v):

$ sudo pkg_add -v screen-4.0.3p0
parsing screen-4.0.3p0
The existing file /etc/screenrc has NOT been changed**                 | 71%
It does NOT match the sample file /usr/local/share/examples/screen/screenrc
You may wish to update it manually
screen-4.0.3p0: complete
Czasem możesz spotkać się z błędami jak ten z poniższego przykładu:
$ sudo pkg_add xv-3.10ap4
xv-3.10ap4:jpeg-6bp3: complete
xv-3.10ap4:png-1.2.14p0: complete                                               
xv-3.10ap4:tiff-3.8.2p0: complete                                            
Can't install xv-3.10ap4: lib not found X11.9.0
Even by looking in the dependency tree:
        tiff-3.8.2p0, jpeg-6bp3, png-1.2.14p0
Maybe it's in a dependent package, but not tagged with @lib ?
(check with pkg_info -K -L)
If you are still running 3.6 packages, update them.
pkg_add ładnie instalował zależności gdy nagle przerwał instalację xv. To jest kolejny środek ostrożności który jest dostępny od wersji OpenBSD 3.7. Informacja pakietu zawarta w paczce zawiera także informację o współdzielonych bibliotekach, które pakiet oczekuje że będą zainstalowane, systemowych oraz zewnętrznych. Jeżeli jedna z wymaganych bibliotek nie może być znaleziona, pakiet nie zostanie zainstalowany ponieważ i tak nie będzie działał.

Aby rozwiązać ten typ problemu, musisz dowiedzieć się co należy zainstalować aby otrzymać wymagane biblioteki w systemie. Istnieje kilka rzeczy do sprawdzenia:

15.2.5 - Wyświetlanie zainstalowanych pakietów

Możesz zobaczyć listę zainstalowanych pakietów korzystając z narzędzia pkg_info(1).
$ pkg_info
aterm-0.4.2p1       color vt102 terminal emulator with transparency support
bzip2-1.0.4         block-sorting file compressor, unencumbered
expat-2.0.0         XML 1.0 parser written in C
fluxbox-0.9.15.1p0  window manager based on the original Blackbox code
gettext-0.14.6      GNU gettext
imlib2-1.3.0        image manipulation library
jpeg-6bp3           IJG's JPEG compression utilities
libiconv-1.9.2p3    character set conversion library
libltdl-1.5.22p1    GNU libtool system independent dlopen wrapper
libungif-4.1.4p0    tools and library routines for working with GIF images
libutf8-0.8         provides UTF-8 locale support
mutt-1.4.2.2i       tty-based e-mail client
pcre-6.4p1          perl-compatible regular expression library
png-1.2.14p0        library for manipulating PNG images
screen-4.0.3p0      multi-screen window manager
tcsh-6.14.00p1      extended C-shell with many useful features
tiff-3.8.2p0        tools and library routines for working with TIFF images
tin-1.8.2p0         threaded NNTP and spool based UseNet newsreader

Gdy podasz nazwę zainstalowanego pakietu (lub położenie pakietu który będzie instalowany), pkg_info(1) pokaże ci bardziej szczegółowe informacje dotyczące tego pakietu.

15.2.6 - Aktualizacja zainstalowanych pakietów

Od wersji OpenBSD 3.7, możliwe jest aktualizacja istniejących pakietów przy pomocy flagi -r (= replace) polecenia pkg_add(1). W OpenBSD 3.8 wprowadzono flagę -u dla pkg_add(1), która została włączona do prawdziwego mechanizmu aktualizacji w 3.9.

Załóżmy że posiadasz starszą wersję unzip'a zainstalowanego zanim wykonałeś aktualizację swojego systemu z 4.1 do 4.2. Możesz teraz z łatwością zaktualizować ten pakiet do 4.2 jak poniżej:

$ sudo pkg_add -u unzip
unzip-5.52 (extracting): complete
unzip-5.51 (deleting): complete
unzip-5.52 (installing): complete
Clean shared items: complete

Gdy pakiet posiada zależności, one również są sprawdzane pod kątem aktualizacji. Wywołanie pkg_add(1) z flagą -u ale bez nazwy pakietu sprawdzi wszystkie zainstalowane pakiety pod kątem nowszych wersji.

Uwaga: Flaga -u opiera się na zmiennej środowiskowej PKG_PATH. Gdy nie jest ona zdefiniowana, pkg_add nie będzie mógł znaleźć aktualizacji.

Począwszy od wersji OpenBSD 4.2, posiadanie kilku wpisów PKG_PATH nie oznacza, że wszystkie źródła będą sprawdzane przy aktualizacji. Zamiast tego, pkg_add(1) zatrzyma się na pierwszej ścieżce zawierającej pasujący pakiet.

Jeżeli istnieją pliki konfiguracyjne należące do starszych wersji, które modyfikowałeś, domyślnie zostaną pozostawione bez zmian. Możesz, oczywiście, zastąpić te pliki plikami domyślnymi nowszej wersji, wywołując pkg_add(1) z flagą -c.

15.2.7 - Usuwanie zainstalowanych pakietów

Aby usunąć zainstalowany pakiet, po prostu weź jego pełną nazwę jaką pokazuje pkg_info(1) (zobacz Wyświetlanie zainstalowanych pakietów) i użyj polecenia pkg_delete(1). W poniższym przykładzie usunięty zostanie pakiet screen'a. Zwracamy uwagę że nie niektórych sytuacjach istnieją dodatkowe pozycje które musisz usunąć a których nie usunie za ciebie pkg_delete(1). Podobnie jak w przypadku pkg_add(1), możesz użyć flagi -v aby zobaczyć bardziej szczegółowe wyjście.

$ sudo pkg_delete screen
screen-4.0.3p0: complete
Clean shared items: complete

Uwaga: Często nie ma potrzeby określania numerów wersji i smaku wraz z nazwą pakietu, ponieważ pkg_delete(1) zazwyczaj będzie potrafił znaleźć pełną nazwę samodzielnie. Musisz określić pełną nazwę pakietu (w naszym przypadku jest to screen-4.0.3p0) tylko w sytuacjach niejednoznacznych gdy zainstalowanych jest wiele pakietów z podaną nazwą. W takim przypadku pkg_delete(1) nie wie jaki pakiet usunąć.

Dla bezpieczeństwa, pkg_delete(1) nie usuwa plików konfiguracyjnych jeżeli zostały zmodyfikowane. Zamiast tego informuje cię o takim fakcie jak poniżej:

$ sudo pkg_delete screen
screen-4.0.3p0: complete
Clean shared items: complete
--- screen-4.0.3p0 -------------------
You should also remove /etc/screenrc (which was modified)

Jeżeli chcesz by pliki konfiguracyjne były usuwane automatycznie, możesz tak zrobić korzystając z flagi -c.

15.2.8 - Aktualizacje bezpieczeństwa (pakiety -stable)

W sytuacji gdy wykryty zostanie błąd lub defekt bezpieczeństwa w "zewnętrznych" programach, są one poprawiane w gałęzi -stable drzewa portów i udostępniane są pewne zaktualizowane pakiety binarne.

Prosimy zapoznaj się ze stroną dotyczącą pakietów -stable aby dowiedzieć się więcej na temat aktualizowanych pakietów w gałęzi -stable. Zaktualizowane pakiety dostępne są tylko dla platform i386 i amd64. Dla pozostałych platform, będziesz musiał skorzystać z gałęzi -stable drzewa portów i kompilować ze źródeł.

Jeżeli chcesz otrzymywać zawiadomienia związane z bezpieczeństwem systemu pakietów i portów, możesz subskrybować grupę dyskusyjną ports-security.

Nazwy pakietów zawsze się zmieniają w przypadku aktualizacji, aby uniknąć ryzyka pomyłki pomiędzy pakietem z wydania a poprawionym pakietem (bug-fixed). Nowa nazwa może zawierać wyższy numer wersji lub w przypadku gdy wersja pakietu pozostaje niezmieniona, dodawany jest przyrostek pN, gdzie N+1 oznacza ile razy dany pakiet był patchowany.

15.2.9 - Instalacja lub usuwanie niekompletnych pakietów

W niektórych dziwnych przypadkach, możesz zauważyć że pakiet nie został dodany lub skasowany całkowicie, ponieważ jest w konflikcie z innymi plikami. Niekompletna instalacja jest zwykle oznaczana przez dodanie "partial-" na początku nazwy pakietu. Sytuacje takie mogą się zdarzać np. w przypadku naciśnięcia CTRL+C podczas instalacji:
$ sudo pkg_add screen-4.0.3p0
screen-4.0.3p0: complete                                                      7%
Adjusting md5 for /usr/local/info/screen.info-3 from 49fb3fe1cc3a3b0057518459811b6dac to 3b9c7811244fb9f8d83bb27d3a0f60d8
/usr/sbin/pkg_add: Installation of screen-4.0.3p0 failed , partial installation recorded as partial-screen-4.0.3p0

Zawsze dobrym pomysłem jest usunięcie niekompletnych pakietów z systemu, i naprawienie potencjalnego problemy który może pojawić się w przyszłości. Jest to zawsze wskazówka, że twój system nie jest "czysty" ze wszystkim zainstalowanym z pakietów, lecz prawdopodobnie pakiety wymieszały się z innym oprogramowaniem instalowanym bezpośrednio ze źródeł.

15.3 - Praca z portami

Wspomnieliśmy na początku o tym że pakiety są kompilowane z drzewa portów. W tej części wytłumaczymy jak działają porty, a także kiedy powinieneś z nich korzystać a kiedy nie.

WAŻNA UWAGA: Drzewo portów dotyczy zaawansowanych użytkowników. Zachęcamy wszystkich do korzystania z pre-kompilowanych pakietów binarnych. NIE zadawaj prostych pytań na grupach dyskusyjnych, w stylu "Jak mogę sprawić, że drzewo portów zacznie działać?". Jeżeli masz pytanie związane z drzewem portów, zakładamy że przeczytałeś strony manuala i to FAQ, a zatem jesteś gotów by z nimi pracować.

15.3.1 - Jak to działa?

Drzewo portów, koncepcyjnie zapożyczone z FreeBSD, jest zestawem plików Makefile, dla każdej zewnętrznej aplikacji, kontrolujących

Niezależnie od Makefile, każdy port zawiera także przynajmniej:

Te wszystkie informacje są przechowywane w hierarchii katalogów /usr/ports Hierarchia ta zawiera trzy podkatalogi specjalne:

Pozostałe podkatalogi dotyczą różnych kategorii aplikacji, które zawierają podkatalogi z właściwymi pakietami. Złożone porty mogą być zorganizowane na jeszcze niższym poziomie, na przykład jeżeli zawierają część bazową programu i zestaw rozszerzeń, lub wersję stabilną i snapshot. Każdy katalog portu musi zawierać podkatalog pkg zawierający ewidencję pakietu(-ów) i plik(-i) opisów. Mogą także istnieć podkatalogi patches/ i files, zawierające odpowiednio łatki źródeł i dodatkowe pliki.

Gdy użytkownik wywoła make(1) w podkatalogu właściwego portu, system rekursywnie sprawdzi drzewo zależności, określi czy wymagane są jakieś zależności, zbuduje i zainstaluje wszystkie brakujące zależności, a następnie powróci do właściwego portu. Cały proces budowy portu zachodzi wewnątrz katalogu roboczego który port utworzy. Jest to albo podkatalog głównego katalogu portów, w tym przypadku rozpoznawany jest przez jego przedrostek "w-", albo podkatalog ${WRKOBJDIR}, jeśli zmienna $WRKOBJDIR została ustawiona (zobacz Konfiguracja systemu portów).

Uwaga: Porty nie są nigdy bezpośrednio instalowane w systemie! Korzystają z imitacji katalogu instalacyjnego. Wszystko co do niego trafia, jest pakowane razem w pakiet (który jest przechowywany w podkatalogu packages/ drzewa portów o którym wspominaliśmy wcześniej). Instalacja portu tak na prawdę oznacza: utworzenie pakietu i później zainstalowanie tego pakietu!

Więcej informacji na temat systemu portów możesz znaleźć na tych stronach manuala:

15.3.2 - Pobieranie drzewa portów

Zanim przejdziesz dalej, powinieneś przeczytać sekcję dotyczącą NIE mieszania twojego systemu z systemem portów. Gdy już zdecydujesz jaki smak systemu portów chcesz, możesz pobierać drzewo portów z różnych źródeł. Poniższa tabela zawiera przegląd co możesz znaleźć w różnych smakach i w jakiej formie. 'x' oznacza dostępność, '-' oznacza brak dostępności poprzez dane źródło.

Źródło Forma Smak
-release -stable snapshots -current
CD-ROM .tar.gz x - - -
mirror FTP .tar.gz x - x -
AnonCVS cvs checkout x x - x

Na CD-ROMie i serwerze FTP szukaj pliku nazywającego się ports.tar.gz Musisz rozpakować ten plik do katalogu usr/, co utworzy /usr/ports i wszystkie podkatalogi wewnątrz niego. Przykładowo:

$ cd /tmp
$ ftp ftp://ftp.openbsd.org/pub/OpenBSD/4.2/ports.tar.gz
$ cd /usr
$ sudo tar xzf /tmp/ports.tar.gz

Snapshoty dostępne na serwerach FTP są generowane codziennie z drzewa portów -current. Snapshoty znajdziesz w katalogu pub/OpenBSD/snapshots/. Jeżeli korzystasz ze snapshotów drzewa portów, powinieneś mieć zainstalowany odpowiedni snapshot systemu OpenBSD. Upewnij się że twoje drzewo portów i system OpenBSD są zgodne!

Więcej informacji dotyczących pobierania drzewa portów przez AnonCVS, prosimy zobacz stronę AnonCVS, która zawiera także listę dostępnych serwerów oraz kilka przykładów.

15.3.3 - Konfiguracja systemu portów

UWAGA: Ta sekcja wprowadza pewne dodatkowe globalne ustawienia dla budowy aplikacji z portów. Możesz pominąć tą sekcję, ale wtedy konieczne będzie wykonywanie wszystkich polecen make(1) jako root.

Ponieważ projekt OpenBSD nie posiada wystarczających środków by w pełni przeglądać kod źródłowy oprogramowania zawartego w drzewie portów, możesz skonfigurować system tak by zachowywał kilka dodatkowych środków ostrożności. Infrastruktura portów pozwala na wykonanie wszystkich czynności związanych z budową z poziomu zwykłego użytkownika, i wykonanie jako root tylko tych kroków które wymagają uprawnień superużytkownika. Są to na przykład tworzenie imitacji katalogu instalacyjnego portu oraz instalacja. Nie mniej jednak, ponieważ uprawnienia roota są zawsze wymagane w kilku punktach, system portów nie uchroni cię jeżeli zdecydujesz by zbudować złośliwą aplikację.

Możliwe jest korzystanie z drzewa portów w trybie tylko-do-odczytu, poprzez separację katalogów do których następuje zapis podczas budowy portu:

Mógłbyś, na przykład, dodać poniższe linie do /etc/mk.conf
WRKOBJDIR=/usr/obj/ports
DISTDIR=/usr/distfiles
PACKAGE_REPOSITORY=/usr/packages
Jeżeli sobie życzysz możesz także zmienić uprawnienia do tych katalogów na twojego lokalnego użytkownika i grupę, tak by system portów mógł tworzyć podkatalogi robocze jako zwykły użytkownik.

15.3.4 - Przeszukiwanie drzewa portów

Gdy już masz porty we właściwym miejscu w swoim systemie bardzo łatwe staje się wyszukiwanie programów. Po prostu skorzystaj z make search key="poszukiwanyklucz", jak pokazano na przykładzie poniżej.
$ cd /usr/ports
$ make search key=rsnapshot
Port:   rsnapshot-1.2.9
Path:   net/rsnapshot
Info:   remote filesystem snapshot utility
Maint:  Sigfred Haversen
Index:  net
L-deps: 
B-deps: :net/rsync
R-deps: :net/rsync
Archs:  any
Wynik poszukiwań podaje przyjemne podsumowanie dla każdego programu który został znaleziony: nazwa portu, ścieżka do niego, jedna linia opisu, osoba utrzymująca port, słowa kluczowe z nim związane, zależności bibliotek/budowy/wykonawcze, oraz architektury na których ten port działa.

Mechanizm ten jest bardzo prosty i uruchamia awk(1) na pliku indeksującym porty. W wersji OpenBSD 4.0 dodano nowy port nazwany "sqlports" pozwalający na bardzo dokładne przeszykiwanie w oparciu o SQL. Jest to baza SQLite, jednak można wygenerować dowolny format bazy danych w oparciu o tą infrastrukturę. W sqlports znajdują się skrypty dzieki ktorym można wygenerować bazę danych w innym formacie.

Po prostu dodaj przy pomocy pkg_add(1) pakiet sqlports oraz, w tym przypadku, pakiet sqlite3. Przykładowa sesja może wyglądać tak:

$ sqlite3 /usr/local/share/sqlports
SQLite version 3.3.12
Enter ".help" for instructions
sqlite> SELECT FULLPKGNAME,COMMENT FROM Ports WHERE COMMENT LIKE '%statistics%';
Guppi-0.40.3p1|GNOME-based plot program with statistics capabilities
mailgraph-1.12|a RRDtool frontend for Postfix statistics
R-2.4.1|clone of S, a powerful math/statistics/graphics language
py-probstat-0.912p0|probability and statistics utilities for Python
darkstat-3.0.540p1|network statistics gatherer with graphs
pfstat-2.2p0|packet filter statistics visualization
tcpstat-1.4|report network interface statistics
wmwave-0.4p2|Window Maker dockapp to display wavelan statistics
diffstat-1.43p0|accumulates and displays statistics from a diff file
sqlite>
Powyższy przykład to wciąż bardzo proste zapytanie. Dzięki SQL można wyszukiwać po bardzo wielu kryteriach, łącznie z zależnościami, flagami konfiguracyjnymi, dzielonymi bibliotekami, itp.

15.3.5 - Bezpośrednia instalacja: przykład

Dla jasności, rozważmy prosty przykład: rsnapshot. Zależnością tej aplikacji jest: rsync.
$ cd /usr/ports/net/rsnapshot
$ make install
===>  Checking files for rsnapshot-1.2.9
>> rsnapshot-1.2.9.tar.gz doesn't seem to exist on this system.
>> Fetch http://www.rsnapshot.org/downloads/rsnapshot-1.2.9.tar.gz.
100% |**************************************************|   173 KB    00:02
>> Size matches for /usr/ports/distfiles/rsnapshot-1.2.9.tar.gz
>> Checksum OK for rsnapshot-1.2.9.tar.gz. (sha1)
===>  rsnapshot-1.2.9 depends on: rsync-2.6.9 - not found
===>  Verifying install for rsync-2.6.9 in net/rsync
===>  Checking files for rsync-2.6.9
>> rsync-2.6.9.tar.gz doesn't seem to exist on this system.
>> Fetch ftp://ftp.samba.org/pub/rsync/old-versions/rsync-2.6.9.tar.gz.
100% |**************************************************|   792 KB    00:31
>> Size matches for /usr/ports/distfiles/rsync-2.6.9.tar.gz
>> Checksum OK for rsync-2.6.9.tar.gz. (sha1)
===>  Verifying specs:  c
===>  found c.40.3
===>  Extracting for rsync-2.6.9
===>  Patching for rsync-2.6.9
===>  Configuring for rsync-2.6.9
 [...snip...]
===>  Building for rsync-2.6.9
 [...snip...]
===>  Faking installation for rsync-2.6.9
 [...snip...]
===>  Building package for rsync-2.6.9
Link to /usr/ports/packages/i386/ftp/rsync-2.6.9.tgz
Link to /usr/ports/packages/i386/cdrom/rsync-2.6.9.tgz
===>  Installing rsync-2.6.9 from /usr/ports/packages/i386/all/rsync-2.6.9.tgz
rsync-2.6.9: complete
===> Returning to build of rsnapshot-1.2.9
===>  rsnapshot-1.2.9 depends on: rsync-2.6.9 - found
===>  Extracting for rsnapshot-1.2.9
===>  Patching for rsnapshot-1.2.9
===>  Configuring for rsnapshot-1.2.9
 [...snip...]
===>  Building for rsnapshot-1.2.9
 [...snip...]
===>  Faking installation for rsnapshot-1.2.9
 [...snip...]
===>  Building package for rsnapshot-1.2.9
Link to /usr/ports/packages/i386/ftp/rsnapshot-1.2.9.tgz
Link to /usr/ports/packages/i386/cdrom/rsnapshot-1.2.9.tgz
===>  rsnapshot-1.2.9 depends on: rsync-2.6.9 - found
===>  Installing rsnapshot-1.2.9 from /usr/ports/packages/i386/all/rsnapshot-1.2.9.tgz
rsnapshot-1.2.9: complete

Jak zatem widzimy, system portów wykonuje wiele rzeczy automatycznie. Pobiera, rozpakowuje, nakłada łatki na kod źródłowy, konfiguruje i buduje (kompiluje) kod, instaluje pliki w fałszywym katalogu, tworzy pakiet (zgodny z ewidencją pakietu) i instaluje ten pakiet w twoim systemie (zazwyczaj w /usr/local/). Wykonuje to także rekursywnie dla wszystkich zależności portu. Zwróć uwagę ma linie "===> Verifying install for ..." oraz "===> Returning to build of ..." dla powyższego przykładu, wskazujące na spacer po drzewie zależności.

Jeżeli wcześniejsza wersja aplikacji którą zamierzasz zainstalować, została zainstalowana wcześniej w twoim systemie, możesz użyć polecenia make update zamiast make install. Spowoduje to wywołanie polecenia pkg_add(1) z flagą -r.

Uwaga: Duże aplikacji będą wymagały znacznych zasobów systemowych do budowy. Dobrym przykładem są kompilatory takie jak GCC 4.0 czy Java 2 Software Development Kit. Jeżeli dostaniesz komunikat "out of memory" podczas kompilacji takiego portu, zwykle oznacza to dwie rzeczy:

15.3.6 - Porządki po kompilacji

Prawdopodobnie będziesz chciał posprzątać domyślny katalog roboczy po tym jak skompilujesz i zainstalujesz port.
$ make clean
===>  Cleaning for rsnapshot-1.2.9
In addition, you can also clean the working directories of all dependencies of the port with this make target:
$ make clean=depends
===>  Cleaning for rsync-2.6.9
===>  Cleaning for rsnapshot-1.2.9
Jeżeli chcesz usunąć źródło(-a) dystrybucyjne portu możesz skorzystać z
$ make clean=dist
===>  Cleaning for rsnapshot-1.2.9
===>  Dist cleaning for rsnapshot-1.2.9
W przypadku gdy kompilowałeś wiele smaków tego samego portu, możesz wyczyścić katalog roboczy dla wszystkich smaków jednocześnie korzystając z
$ make clean=flavors
Możesz także czyścić katalogi podczas kompilacji ustawiając specjalną zmienną. Katalogi robocze będą wówczas automatycznie czyszczone po utworzeniu pakietu:
$ make package BULK=Yes

15.3.7 - Usuwanie zainstalowanego pakietu portu

Bardzo łatwo można odinstalować port:
$ make uninstall
===> Deinstalling for rsnapshot-1.2.9
rsnapshot-1.2.9: complete
Clean shared items: complete
Zostanie wywołane polecenie pkg_delete(1) do usunięcia odpowiedniego pakietu z twojego systemu. Jeżeli jest to potrzebne możesz także usunąć i zainstalować ponownie pakiet portu korzystając z
$ make reinstall
===>  Cleaning for rsnapshot-1.2.9
/usr/sbin/pkg_delete rsnapshot-1.2.9
rsnapshot-1.2.9: complete
Clean shared items: complete
===>  Installing rsnapshot-1.2.1 from /usr/ports/packages/i386/all/rsnapshot-1.2.9.tgz
rsnapshot-1.2.9: complete
Jeżeli chcesz pozbyć się pakietów które właśnie zbudowałeś, możesz to zrobić tak jak poniżej:
$ make clean=packages
===>  Cleaning for rsnapshot-1.2.9
rm -f /usr/ports/packages/i386/all/rsnapshot-1.2.9.tgz

15.3.8 - Korzystanie ze smaków i podpakietów

Prosimy przeczytaj stronę manuala ports(7), która powinna dać ci dobre wprowadzenie do tematu. Istnieją dwa mechanizmy kontroli paczek oprogramowania w zależności zgodnie z różnymi potrzebami.

Pierwszy z nich nazywany jest smakami. Smak zazwyczaj oznacza pewien zestaw opcji kompilacji. Przykładowo, niektóre aplikacje posiadają smaki "no_X11" który może być używany w systemach bez X-ów. Niektóre powłoki mają smak "static", które budują statycznie zlinkowaną wersję. Istnieją porty które mają różne smaki do kompilacji z różnymi graficznymi toolkitami. Inne aplikacje zawierają: wsparcie dla różnych baz danych, różne opcje sieciowe (SSL, IPv6, ...), różne rozmiary papieru, itd.

Podsumowując: Najprawdopodobniej będziesz korzystał ze smaków gdy twój pakiet nie został wykonany ze smakiem którego szukasz. W takim przypadku określisz pożądany smak i zbudujesz port samodzielnie.

Większość smaków portu posiada swóje własne katalogi roboczy podczas budowy i aby uniknąć nieporozumień, każdy smak będzie pakowany w odpowiednio nazwany pakiet. Jeżeli chcesz zobaczyć dostępne smaki dla danego portu, możesz zmienić katalog na katalog portu i wykonać

$ make show=FLAVORS
Powinieneś także zobaczyć zawartość plików DESCR dla portów ponieważ powinny zawierać także informacje o dostępnych smakach.

Drugi mechanizm nazywany jest podpakietami: Opiekun portu może podjąć decyzję o utworzeniu subpakietów dla różnych fragmentów tej samej aplikacji, o ile można je logicznie rozdzielić. Bardzo często możesz zobaczyć podpakiety dla części klienta i serwera tego samego programu. Czasem rozległe dokumentacje są pakowane w oddzielne podpakiety ponieważ pozwala to oszczędzić trochę przestrzeni dyskowej. Dodatkowe funkcjonalności, pociągające za soba wiele zależności, będą często dodawane jako osobny pakiet. Opiekun portu zdecyduje także o tym który podpakiet będzie podpakietem podstawowym i będzie instalowany domyślnie. Innymi przykładami są: obszerne zestawy narzędzi dołączonych do programu, oddzielne moduły do obsługi różnych rzeczy, itd.

Podsumowanie: Niektóre porty są podzielone na pakiety. Polecenie make install zainstaluje tylko pakiet podstawowy.

Aby wyświetlić listę pakietów utworzonych z danego portu, użyj polecenia:

$ make show=PACKAGES

Polecenie make install zainstaluje tylko pierwszy podpakiet. Chcąc zainstalować wszystkie użyj polecenia:

$ make install-all

Listę różnych podpakietów dostępnych dla danego portu, możesz zobaczyć korzystając z

$ make show=MULTI_PACKAGES
Możliwe jest wybranie który podpakiet(-y) będzie instalowany wewnątrz drzewa portów. Po kilku testach, procedura ta wywoła pkg_add(1) do zainstalowania porządanego podpakietu(-ów).
$ env SUBPACKAGE="-server" make install

Uwaga: Mechanizm podpakietów dotyczy tylko pakietów, nie modyfikuje żadnych opcji konfiguracyjnych przed budową portu. Do tego celu musisz używać smaków.

15.3.9 - Aktualizacje bezpieczeństwa

Gdy zostaną wykryte poważne błędy lub defekty bezpieczeństwa w zewnętrznym oprogramowaniu, są one naprawianie w gałęzi -stable drzewa portów. Pamiętaj o rocznym cyklu życia: tylko aktualne i ostatnie wydanie są aktualizowane, zgodnie z tym co zostało napisane w FAQ 5 - Wątki OpenBSD.

Oznacza to, że wszystko co musisz zrobić to upewnić się że pobierasz właściwą gałąź drzewa portów, i z niego budujesz poszukiwane programy. Musisz pamiętać o utrzymywaniu aktualnej wersji z CVS, oraz dodatkowo subskrybować grupę dyskusyjną ports-security, aby otrzymywać komunikaty bezpieczeństwa związane z programami znajdującymi się w drzewie portów.

Oczywiście, poprawki bezpieczeństwa wprowadzane są najpierw do portów wersji -current zanim trafią do gałęzi -stable.

15.4 - FAQ

15.4.1 - Dostaję wszystkie rodzaje dziwnych błędów. Po prostu nie widzę by system portów w ogóle działał.

Jest bardzo prawdopodobne że korzystasz z systemu i drzewa portów które nie są zgodne.

Przepraszam?

Innym powszechnym błędem jest pominięcie instalacji X11. Nawet jeżeli port który usiłujesz zbudować nie ma bezpośredniej zależności z X11, jego podpakiet lub jego zależności mogą wymagać nagłówków i bibliotek X11. Budowa portów w systemie bez X11 nie jest wspierana, zatem jeżeli upierasz się by to wykonać, musisz sam wymyśleć jak to zrobić. Jednakże dla wielu portów istnieją "smakowe" pakiety "no_x11", które możesz zainstalować w systemie bez konieczności posiadania X11.

15.4.2 - Najnowsza wersja mojego Ulubionego-Programu jest niedostępna!

Jeżeli używasz wydania lub wersji stabilnej OpenBSD, nie znajdziesz żadnych aktualizacji pakietów, aż do następnego wydania lub aż wyniknie problem bezpieczeństwa uzasadniające aktualizację portu w gałęzi -stable, a także aktualizacja odpowiadającego mu pakietu.

OSTRZEŻENIE: NIE mieszaj wersji Portów i OpenBSD!

Robiąc tak prędzej czy później (prawdopodobnie bardzo szybko) sprawisz sobie ból głowy starając się rozwiązywać problemy wszystkich możliwych błędów!

Ale zaraz, mam wszystko -current!

Kolekcja portów jest projektem wolontariuszy. Czasem projekt po prostu nie ma wystarczających zasobów developerskich by utrzymać wszystko "up-to-date". Developerzy często wybierają to co uważają za interesujące i co mogą przetestować w swoim środowisku. Twoja dotacja może spowodować testowanie portów na większej liczbie platform.

Niektóre pakiety mogą pozostać w tyle za głównymi wersjami z tego powodu. Kolekcja portów może posiadać wersję ze Stycznia, podczas gdy nowa wersja programu została wydana przez developerów w Maju, trzy miesiące temu. Często jest to świadoma decyzja; mogą występować problemy z nową wersją w OpenBSD i opiekun stara się go rozwiązać, lub po prostu zrobiono aplikację gorszą niż stara wersja: OpenBSD może mieć inne założenia niż developerzy innego projektu, co czasem skutkuje w wyborze właściwości i wyborze modelu lub implementacji, które są nieporządane z punktu widzenia developerów OpenBSD. Aktualizacja mogła być odłożona, ponieważ nowa wersja nie była rozważana jako aktualizacja krytyczna.

Jeżeli naprawdę potrzebujesz nowej wersji portu, powinieneś poprosić opiekuna portu o aktualizację (zobacz poniżej jak dowiedzieć się kto jest jego opiekunem). Jeżeli możesz pomóc, tym lepiej.

15.4.3 - Dlaczego nie ma pakietu mojego Ulubionego-Programu?

Istnieje kilka możliwych powodów:

15.4.4 - Dlaczego nie ma portu dla mojego Ulubionego-Programu?

Kolekcja portów jest pracą wolontariuszy. Aktywna praca developerska jest wykonywana przez ograniczoną liczbę osób, w ich wolnym czasie. Ludzie ci zazwyczaj tworzą kilka portów tylko tych programów których bezpośrednio używają lub którymi są zainteresowani.

Możesz pomóc. Rozważ możliwość tworzenia własnego portu. Istnieje dokumentacja dotycząca tego zagadnienia: Tworzenia portu OpenBSD. Przeczytaj ją, a następnie przeczytaj ją jeszcze raz. Szczególnie część dotyczącą opieki nad twoim portem. Później spróbuj stworzyć własny port i przetestuj go dokładnie krok po kroku. Jeżeli w końcu będzie działał DOBRZE dla ciebie, wyślij go na grupę dyskusyjną dotyczą portów na ports@openbsd.org. Istnieją duże szanse że dostaniesz odpowiedź i testy od innych osób. Jeżeli te testy się powiodą, zostanie rozważona możliwość dodania twojego portu do drzewa portów.

15.4.5 - Dlaczego mój Ulubiony-Program nie jest częścią systemu bazowego?

Ponieważ OpenBSD ma być małym samowystarczalnym uniksowym systemem operacyjnym, potrzebne jest wyznaczenie linii dotyczącej tego co jest włączone. Generalnie, aplikacja włączona do systemu bazowego:

Dodatkowe odpowiedzi do tego pytania znajdziesz w FAQ 1.

15.4.6 - Czego powinienem używać: pakietów czy portów?

Generalnie, mocno zalecamy korzystanie z pakietów zamiast budowy aplikacji z portów. Zespół tworzący porty OpenBSD rozważa pakiety jako cel ich pracy z portami, nie porty same w sobie.

Budowa złożonej aplikacji ze źródeł nie jest prosta. Nie tylko aplikacja ma być kompilowana, ale także narzędzia służące jej kompilacji muszą być skompilowane. Niestety, OpenBSD, narzędzia, i aplikacje ciągle są rozwijane, zatem często złożenie wszystkich fragmentów by działały razem jest wyzwaniem. Gdy już wszystko działa, korekta jednej części następnego dnia może spowodować uszkodzenie. Cosześć miesięcy, gdy tworzone jest nowe wydanie OpenBSD, spory wysiłek jest przeznaczany na budowę każdego portu dla każdej platformy, jednak ze względu na cykl developerski, jest bardzo prawdopodobne że niektóre porty będą uszkodzone.

Poza posiadaniem wszystkich fragmentów działających razem, konieczne jest poświęcenie pewnego czasu i zasobów aby skompilować niektóre programy ze źródeł. Prostym przykładem jest CVSup, narzędzie często wykorzystywane do śledzenia drzewa źródeł OpenBSD. Instalacja CVSup na nowoczesnym szybkim komputerze z dobrym łączem Internetowym, może zając ok dziesięciu sekund -- czas potrzebny na pobranie i rozpakowanie pojedynczej paczki 779kB. Przeciwnie, budowa CVSup ze źródeł na tej samej maszynie jest dużym zadaniem, wymagającym wielu narzędzi i załadowania kompilatora, zajmując nawet pół godziny na niektórych komputerach. Inne aplikacjem takie jak Mozilla czy KDE mogą zając godziny i dużą ilość przestrzeni dyskowej i RAMu/swapu. Po co tracić taką ilość czasu i wysiłek, podczas gdy te programy są już skompilowane i znajdują się na twoim CD-ROM lub mirrorze FTP, czekając na użycie?

Oczywiście istnieje kilka dobrych powodów aby, w niektórych sytuacjach, korzystać z portów zamiast z pakietów:

Jednakże, dla większości ludzi i większości aplikacji, korzystanie z pakietów jest znacznie prostsze, i jest to zdecydowanie zalecany sposób dodawania aplikacji do systemu OpenBSD.

15.4.7 - W jaki sposób dostosować te porty i uzyskać maksimum wydajności?

OpenBSD jest o stabilności i bezpieczeństwie. Podobnie jak kernel GENERIC jest domyślnym i jedynym wspieranym kernelem, zespół portów dba by system portów działał i by były one stabilne. Jeżeli chcesz skorzystać z jakichkolwiek opcji kompilatora, jesteś zdany na siebie. Prosimy nie pytaj na grupach mailingowych dlaczego coś nie działa, podczas gdy usiłujesz przestawić kilka ukrytych "opcji" aby sprawić by działało szybciej. W zasadzie jest bardzo prawdopodobne że będzie to strata czasu, dla ciebie, jako użytkownika, a także dla developerów którzy przeczytają o twoich "problemach" podczas gdy tak na prawdę ich nie ma.

15.4.8 - Zgłosiłem nowy port/aktualizację tydzień temu. Dlaczego nie został dodany?

Zespół zajmujący się portami posiada bardzo ograniczone zasoby i żaden opiekun nie zdążył spojrzeć na twój port/aktualizację w tym czasie. Nie ważne jak denerwujące może się to wydawać, zignoruj ten fakt. Zadbaj o swój port, wysyłaj aktualizacje aż ostatecznie ktoś się tym zajmie. Może się tak zdarzyć w czasie gdy któryś opiekun będzie miał trochę wolnego czasu który spędzi nad portami lub swoimi zainteresowaniami w nowych dziedzinach i wtedy twoje stare zgłoszenie stanie się interesujące, jeżeli zostało zapamiętane.

15.5 - Zgłaszanie problemów

Jeżeli masz problem z istniejącym portem, prosimy wysłać e-mail do opiekuna portu. O tym kto jest opiekunem portu dowiesz się wpisując przykładowo:
$ cd /usr/ports/archivers/unzip
$ make show=MAINTAINER

Alternatywnie, jeżeli nie jest podany żaden opiekun, lub nie możesz do niego/niej dotrzeć, wyślij e-mail na grupę mailingową dotyczącą portów ports@openbsd.org. Prosimy NIE używać listy mailingowej misc@openbsd.org do pytań dotyczących portów.

W każdym przypadku dołącz:

W przypadku portów które nie kompilują się poprawnie, podanie kompletnej transkrypcji kompilacji jest prawie zawsze wymagane. Możesz użyć do tego skryptu portslogger, znajdującego się w /usr/ports/infrastructure/build. Przykładowe uruchomienie portsloggera może być takie:
$ mkdir ~/portslogs
$ cd /usr/ports/archivers/unzip
$ make clean install 2>&1 | /usr/ports/infrastructure/build/portslogger \
           ~/portslogs
Po tym, powinieneś uzyskać plik logu budowy w twoim katalogu ~/portslogs, który możesz wysłać do opiekuna portu. Ponadto powinieneś upewnić się, że nie korzystasz z żadnych specjalnych opcji w twojej kompilacji, przykładowo w /etc/mk.conf.

Alternatywnie, możesz

15.6 - Jak nam pomóc?

Jest kilka sposobów w jaki możesz pomóc. Wylistowane zostały poniżej, zgodnie z wzrostem stopnia trudności. UWAGA: Dla wszystkich nowo tworzonych portów oraz dalszych testów, lub dla testów aktualizacji portów, musisz pracować na systemie -current! Generalnie nie jest to szczególnie porządane środowisko ze względu na jego ciągły rozwój, zatem kontynuuj tylko jeżeli jesteś przekonany o swojej chęci do podążania za -current.

[Spis treści] [Sekcja 14 - Konfiguracja dysków]


[back] www@openbsd.org
$OpenBSD$