![[OpenBSD]](../../images/smalltitle.gif){kind=small}
[Spis treści] [Sekcja 14 - Konfiguracja dysków]
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.
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:
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.0/packages/`machine -a`/
Przykład 2: pobieranie pakietu z najbliższego mirrora FTP
$ export PKG_PATH=ftp://your.ftp.mirror/pub/OpenBSD/4.0/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.0" "snapshots".
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.
$ sudo pkg_add -v screen-4.0.2 parsing screen-4.0.2 installed /etc/screenrc from /usr/local/share/examples/screen/screenrc | 71% screen-4.0.2: 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.
$ sudo pkg_add -i screen
Ambiguous: screen could be screen-4.0.2 screen-4.0.2-shm screen-4.0.2-static
Choose one package
0: <None>
1: screen-4.0.2
2: screen-4.0.2-shm
3: screen-4.0.2-static
Your choice: 1
screen-4.0.2: 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-6.0p0 ghostscript-fonts-6.0p0: complete You may wish to update your font path for /usr/local/share/ghostscript/fonts --- ghostscript-fonts-6.0p0 ------------------- 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:
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.$ sudo pkg_add -v tin-1.6.2 parsing tin-1.6.2 Dependencies for tin-1.6.2 resolve to: gettext-0.14.5p1, libutf8-0.8, pcre-6.4p1, libiconv-1.9.2p3 (todo: libiconv-1.9.2p3,gettext-0.14.5p1,pcre-6.4p1,libutf8-0.8) tin-1.6.2:parsing libiconv-1.9.2p3 tin-1.6.2:libiconv-1.9.2p3: complete tin-1.6.2:parsing gettext-0.14.5p1 Dependencies for gettext-0.14.5p1 resolve to: expat-1.95.6p1, libiconv-1.9.2p3 (todo: expat-1.95.6p1) tin-1.6.2:parsing expat-1.95.6p1 tin-1.6.2:expat-1.95.6p1: complete tin-1.6.2:gettext-0.14.5p1: complete tin-1.6.2:parsing pcre-6.4p1 tin-1.6.2:pcre-6.4p1: complete tin-1.6.2:parsing libutf8-0.8 tin-1.6.2:libutf8-0.8: complete tin-1.6.2: complete
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.0/packages/`machine -a`/screen-4.0.2.tgz screen-4.0.2: 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):
Czasem możesz spotkać się z błędami jak ten z poniższego przykładu:$ sudo pkg_add -v screen-4.0.2 parsing screen-4.0.2 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.2: complete
$ sudo pkg_add xv-3.10ap4
xv-3.10ap4:jpeg-6bp3: complete
xv-3.10ap4:png-1.2.8: complete
xv-3.10ap4:tiff-3.7.3p0: complete
Can't install xv-3.10ap4: lib not found X11.9.0
Even by looking in the dependency tree:
tiff-3.7.3p0, jpeg-6bp3, png-1.2.8
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.
Aby rozwiązać ten typ problemu, musisz dowiedzieć się co należy zainstalować aby otrzymać wymagane biblioteki w systemie. Istnieje kilka rzeczy do sprawdzenia:
$ pkg_info aterm-0.4.2 color vt102 terminal emulator with transparency support bzip2-1.0.3 block-sorting file compressor, unencumbered expat-1.95.6p1 XML 1.0 parser written in C fluxbox-0.9.14 window manager based on the original Blackbox code gettext-0.14.5p1 GNU gettext imlib2-1.1.2p2 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.4 tools and library routines for working with GIF images libutf8-0.8 provides UTF-8 locale support mutt-1.4.2ip2 tty-based e-mail client pcre-6.4p1 perl-compatible regular expression library png-1.2.8 library for manipulating PNG images screen-4.0.2 multi-screen window manager tcsh-6.14.00p0 extended C-shell with many useful features tiff-3.7.3p0 tools and library routines for working with TIFF images tin-1.6.2 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.
Załóżmy że posiadasz starszą wersję unzip'a zainstalowanego zanim wykonałeś aktualizację swojego systemu z 3.9 do 4.0. Możesz teraz z łatwością zaktualizować ten pakiet do 4.0 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
Wywołanie pkg_add(1) z flagą -u ale beż nazwy pakietu sprawdzi wszystkie zainstalowane pakiety pod kątem nowszych wersji. Gdy pakiet posiada zależności, one również są sprawdzane pod kątem aktualizacji.
Uwaga: Flaga -u opiera się na zmiennej środowiskowej PKG_PATH. Gdy nie jest ona zdefiniowana, pkg_add nie będzie mógł znaleźć aktualizacji.
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.
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.2: 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.2) 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.2: complete Clean shared items: complete --- screen-4.0.2 ------------------- 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.
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.
$ sudo pkg_add screen-4.0.2 screen-4.0.2: complete 7% Adjusting md5 for /usr/local/info/screen.info-3 from 49fb3fe1cc3a3b0057518459811b6dac to 3b9c7811244fb9f8d83bb27d3a0f60d8 /usr/sbin/pkg_add: Installation of screen-4.0.2 failed , partial installation recorded as partial-screen-4.0.2
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ł.
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ć.
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:
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:
| Ź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.0/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.
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ę.
SUDO=/usr/bin/sudo
# chgrp -R wsrc /usr/ports
# find /usr/ports -type d -exec chmod g+w {} \;
Spowoduje to wymuszenie na procedurze budowy by nie "wychodziła" poza dozwolone katalogi, a także uniemożliwi zapisywanie w niedozwolonych miejscach w rezultacie znacznie ograniczając ryzyko uszkodzenia systemu. Zwróć uwagę, że korzystanie z systrace(1) zwiększa o około 20% czas budowy.USE_SYSTRACE=Yes
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:
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.WRKOBJDIR=/usr/obj/ports DISTDIR=/usr/distfiles PKGREPOSITORYBASE=/usr/packages
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.$ 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
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:
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.$ sqlite3 /usr/local/share/sqlports SQLite version 3.3.6 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.1.1p0|clone of S, a powerful math/statistics/graphics language py-probstat-0.912p0|probability and statistics utilities for Python darkstat-3.0.524|network statistics gatherer with graphs pfstat-2.2|packet filter statistics visualization tcpstat-1.4|report network interface statistics wmwave-0.4p2|Window Maker dockapp to display wavelan statistics diffstat-1.43|accumulates and displays statistics from a diff file sqlite>
$ 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.8 - not found ===> Verifying install for rsync-2.6.8 in net/rsync ===> Checking files for rsync-2.6.8 >> rsync-2.6.8.tar.gz doesn't seem to exist on this system. >> Fetch ftp://ftp.samba.org/pub/rsync/old-versions/rsync-2.6.8.tar.gz. 100% |**************************************************| 754 KB 00:31 >> Size matches for /usr/ports/distfiles/rsync-2.6.8.tar.gz >> Checksum OK for rsync-2.6.8.tar.gz. (sha1) ===> Verifying specs: c ===> found c.39.3 ===> Extracting for rsync-2.6.8 ===> Patching for rsync-2.6.8 ===> Configuring for rsync-2.6.8 [...snip...] ===> Building for rsync-2.6.8 [...snip...] ===> Faking installation for rsync-2.6.8 [...snip...] ===> Building package for rsync-2.6.8 Link to /usr/ports/packages/i386/ftp/rsync-2.6.8.tgz Link to /usr/ports/packages/i386/cdrom/rsync-2.6.8.tgz ===> Installing rsync-2.6.8 from /usr/ports/packages/i386/all/rsync-2.6.8.tgz rsync-2.6.8: complete ===> Returning to build of rsnapshot-1.2.9 ===> rsnapshot-1.2.9 depends on: rsync-2.6.8 - 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.8 - 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:
In addition, you can also clean the working directories of all dependencies of the port with this make target:$ make clean ===> Cleaning for rsnapshot-1.2.9
Jeżeli chcesz usunąć źródło(-a) dystrybucyjne portu możesz skorzystać z$ make clean=depends ===> Cleaning for rsync-2.6.8 ===> 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=dist ===> Cleaning for rsnapshot-1.2.9 ===> Dist cleaning for rsnapshot-1.2.9
$ make clean=flavors
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 uninstall ===> Deinstalling for rsnapshot-1.2.9 rsnapshot-1.2.9: complete Clean shared items: complete
Mógłbyś także chcieć pozbyć się pakietów które właśnie zbudowałeś, możesz to zrobić tak jak poniżej:$ 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
Użyj "packages" zamiast "package" aby usunąć także wszystkie podpakiety (zobacz poniżej).$ make clean=package ===> Cleaning for rsnapshot-1.2.9 rm -f /usr/ports/packages/i386/all/rsnapshot-1.2.9.tgz
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.
Każdy smak portu posiada swój własny katalog 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
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. Innymi przykładami są: obszerne zestawy narzędzi dołączonych do programu, oddzielne moduły do obsługi różnych rzeczy, itd.
Podsumowanie: Będziesz korzystał z podpakietów gdy będziesz potrzebował tylko części danej aplikacji, a nie całości. Jednakże, jest bardzo prawdopodobne że subpakiet którego potrzebujesz już istnieje i jest gotowy do pobrania i instalacji z twojego najbliższego serwera FTP.
Aby zobaczyć listę różnych podpakietów dostępnych dla danego portu, użyj
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).$ make show=MULTI_PACKAGES
$ 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.
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.
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.
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.
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.
Dodatkowe odpowiedzi do tego pytania znajdziesz w FAQ 1.
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:
$ 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:
$ mkdir ~/portslogs
$ cd /usr/ports/archivers/unzip
$ make clean install 2>&1 | /usr/ports/infrastructure/build/portslogger \
~/portslogs
Alternatywnie, możesz
[Spis treści] [Sekcja 14 - Konfiguracja dysków]
![[back]](../../images/back.gif){kind=small}
www@openbsd.org