![[OpenBSD]](../../images/smalltitle.gif){kind=small}
[Spis treści] [Sekcja 14 - Konfiguracja dysków]
Dostępna jest całkiem sporo zewnętrznych aplikacji z których niektórzy mogą chcieć korzystać 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 jako snapshoty dla -current.
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.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".
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.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.
$ 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
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, możliwe 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
$ 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.
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.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.
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.
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.
$ 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 problemu 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.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.
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 {} \;
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:
WRKOBJDIR=/usr/obj/ports
DISTDIR=/usr/distfiles
PACKAGE_REPOSITORY=/usr/packages
$ 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:
$ 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>
$ 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:
$ make clean
===> Cleaning for rsnapshot-1.2.9
$ make clean=depends
===> Cleaning for rsync-2.6.9
===> Cleaning for rsnapshot-1.2.9
$ make clean=dist
===> Cleaning for rsnapshot-1.2.9
===> Dist cleaning for rsnapshot-1.2.9
$ make clean=flavors
$ make package BULK=Yes
$ make uninstall
===> Deinstalling for rsnapshot-1.2.9
rsnapshot-1.2.9: complete
Clean shared items: complete
$ 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
$ make clean=packages
===> 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.
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
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
$ 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.
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.
Dla 4.2 wiele pakietów korzystających z libexpat wymusza zainstalowanie xbase42.tgz, nawet jeśli nie posiadają graficznego interfejsu. Zostanie to poprawione w 4.3.
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 umożliwić 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