![[OpenBSD]](../../images/smalltitle.gif){kind=small}
[FAQ Index] [Naar Sectie 14 - Inrichting van de Schijf]
Er zijn veel externe toepassingen beschikbaar die men misschien wil gebruiken op een OpenBSD systeem. Om deze software gemakkelijker te installeren en te beheren, en om ze te helpen laten voldoen aan OpenBSD's beleid en doelstellingen, wordt de externe software geported naar OpenBSD. Met dit port-werk kunnen vele verschillende dingen gepaard gaan. Voorbeelden zijn: de software de standaard OpenBSD directorystructuur laten gebruiken (bv. configuratiebestanden worden in /etc geplaatst), voldoen aan OpenBSD's "shared library" specificaties, de software veiliger maken indien mogelijk, enz.
Het eindresultaat van het port-werk zijn binaire packages die klaar zijn om te installeren. De bedoeling van het package-systeem is bij te houden welke software geïnstalleerd wordt, zodat deze gelijk wanneer heel gemakkelijk kan geüpdatet of verwijderd worden. Op die manier blijven er geen onnodige bestanden achter, en kunnen gebruikers hun systemen zuiver houden. Het package-systeem helpt er ook voor te zorgen dat niets per ongeluk verwijderd wordt, wat ertoe kan leiden dat software ophoudt naar behoren te functioneren. Nog een voordeel is dat gebruikers zelden software hoeven te compileren vanaf broncode, aangezien packages reeds gecompileerd werden, beschikbaar zijn en klaar om op een OpenBSD systeem gebruikt te worden. In luttele minuten kan een groot aantal packages afgehaald en geïnstalleerd worden, met alles op de juiste plaats.
De packages en ports verzameling ondergaat NIET dezelfde uitvoerige veiligheidsaudit die op het OpenBSD basissysteem wordt uitgevoerd. Alhoewel we ernaar streven om de kwaliteit van de packages hoog te houden, hebben we gewoonweg niet genoeg mankracht om hetzelfde niveau van robuustheid en veiligheid te garanderen. Natuurlijk worden beveiligingsupdates voor verscheidene toepassingen zo snel mogelijk gecommit in de ports tree, en worden de overeenkomstige package-beveiligingsupdates beschikbaar gemaakt als snapshots voor -current.
Packages zijn de vooraf gecompileerde binaries van een aantal van de meest gebruikte externe software. Packages kunnen gemakkelijk beheerd worden met behulp van verscheidene utilities, ook gekend als de pkg* tools:
Om naar behoren te draaien, kan een toepassing X vereisen dat andere toepassingen Y en Z geïnstalleerd zijn. Toepassing X is met name afhankelijk van deze andere toepassingen, daarom worden Y en Z "dependencies" van X genoemd. Op zijn beurt kan Y andere toepassingen P en Q vereisen, en Z kan toepassing R vereisen om naar behoren te werken. Op deze manier wordt een hele "dependency tree" gevormd.
Packages zien eruit als eenvoudige .tgz archieven. Eigenlijk zijn ze dat ook, maar er is één cruciaal verschil: ze bevatten wat extra packing-informatie. Deze informatie wordt door pkg_add(1) gebruikt voor verschillende doeleinden:
U kan de dingen erg gemakkelijk maken door de PKG_PATH omgevingsvariabele te gebruiken. Laat hem gewoon naar uw favoriete locatie wijzen, en pkg_add(1) zal daar automatisch gaan zoeken naar elke package die u specificeert, en ook automatisch de noodzakelijke dependencies van deze package afhalen en installeren.
Een lijst met mogelijke locaties om packages vandaan te halen wordt gegeven in de volgende sectie.
Voorbeeld 1: afhalen van uw CDROM, in de veronderstelling dat u deze hebt gemount op /mnt/cdrom
$ export PKG_PATH=/mnt/cdrom/4.2/packages/`machine -a`/
Voorbeeld 2: afhalen van een nabije FTP mirror
$ export PKG_PATH=ftp://your.ftp.mirror/pub/OpenBSD/4.2/packages/`machine -a`/
Het is gewoonlijk een goed idee om een lijn gelijkaardig aan de bovenstaande voorbeelden toe te voegen aan uw ~/.profile. Zoals bij de klassieke PATH variabele, kan u meerdere locaties specificeren, gescheiden door dubbele punten. MAAR elk pad in de PKG_PATH variabele MOET eindigen op een schuine streep (/). Op die manier kan pkg_add(1) het pad correct splitsen zelfs als er URL schema's in zitten die dubbele punten bevatten. Als de eerste entry in PKG_PATH faalt, zal de volgende geprobeerd worden, enzoverder, tot de package gevonden wordt. Als alle entries falen, krijgt u een foutmelding.
Bemerk het gebruik van machine(1) in de bovenstaande commandoregels. Dit vervangt automatisch de "toepassingsarchitectuur" van uw geïnstalleerde OpenBSD, welke gewoonlijk, maar niet altijd, de naam van uw platform is. Indien u snapshots gebruikt, zal u natuurlijk "4.2" door "snapshots" vervangen.
Als u de ports tree op uw systeem hebt, kan u snel de package vinden die u zoekt zoals uitgelegd in Doorzoeken van de ports tree.
U zal merken dat bepaalde packages beschikbaar zijn in enkele verschillende varianten, formeel "flavors" genoemd. Andere zijn onderdelen van dezelfde toepassing die afzonderlijk kunnen geïnstalleerd worden. Deze worden "subpackages" genoemd. Dit wordt in meer detail besproken in Gebruik van flavors en subpackages maar flavor betekent eigenlijk dat ze geconfigureerd worden met verschillende sets van opties. Momenteel hebben vele packages flavors, bijvoorbeeld: databankondersteuning, ondersteuning voor systemen zonder X, of netwerktoevoegingen zoals SSL en IPv6. Elke flavor van een package zal een verschillend suffix hebben in zijn package-naam. Raadpleeg voor gedetailleerde informatie over package-namen alstublieft packages-specs(7).
Opmerking: Niet alle mogelijke packages zijn noodzakelijk beschikbaar op de FTP servers! Sommige toepassingen werken gewoon niet op alle architecturen. Sommige toepassingen mogen niet gedistribueerd worden via FTP (of CD-ROM) om licentieredenen. Er kunnen ook vele mogelijke combinaties van flavors van een port zijn, en het OpenBSD project heeft gewoon niet de middelen om ze allemaal te bouwen. Indien u een combinatie nodig hebt die niet beschikbaar is, zal u de port vanaf broncode moeten bouwen. Lees voor meer informatie daarover Gebruik van flavors en subpackages in de Ports sectie van dit document.
$ sudo pkg_add -v screen-4.0.3p0
parsing screen-4.0.3p03p03p0
installed /etc/screenrc from /usr/local/share/examples/screen/screenrc | 71%
screen-4.0.3p0: complete
In dit voorbeeld werd de -v vlag gebruikt om meer uitgebreide uitvoer te geven. Deze optie is niet nodig maar ze is nuttig om te debuggen en werd hier gebruikt om een beetje meer inzicht te bieden in wat pkg_add(1) eigenlijk aan het doen is. Bemerk de boodschap die /etc/screenrc vermeldt. Het specificeren van meerdere -v vlaggen zal nog meer uitgebreide uitvoer produceren.
$ 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
Voor sommige packages zal er belangrijke bijkomende informatie gegeven worden over de configuratie of het gebruik van de toepassing op een OpenBSD systeem. Aangezien ze belangrijk is, zal ze getoond worden ongeacht het gebruik van de -v vlag. Beschouw het volgende voorbeeld:
$ 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/"
Laat ons nu verder gaan met een voorbeeld van een package die dependencies heeft:
$ 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
Het is mogelijk om op één lijn meerdere package-namen te specificeren, die dan allemaal ineens geïnstalleerd worden, samen met mogelijke dependencies.
Als u om één of andere reden beslist om PKG_PATH niet te gebruiken, is het ook mogelijk om de absolute locatie van een package op de commandoregel te specificeren. Deze absolute locatie kan een lokaal pad zijn, of een URL die verwijst naar FTP, HTTP of SCP locaties. Laten we een installatie vie FTP beschouwen in het volgende voorbeeld:
$ sudo pkg_add ftp://ftp.openbsd.org/pub/OpenBSD/4.2/packages/`machine -a`/screen-4.0.3p0.tgz
screen-4.0.3p0: complete
In dit voorbeeld werd de -v vlag niet gebruikt, dus worden enkel noodzakelijke boodschappen getoond. Merk op dat de volledige bestandsnaam ingegeven werd door een .tgz suffix toe te voegen. U kan dit suffix ook overslaan zoals in de vorige voorbeelden aangezien het automatisch wordt aangevuld door pkg_add(1).
Opmerking: Niet alle architecturen hebben dezelfde packages beschikbaar. Sommige ports werken niet op bepaalde architecturen, en prestatie beperkt het aantal packages dat op andere kan gebouwd worden.
Voor de veiligheid zal pkg_add(1), indien u een package installeert die u eerder al geïnstalleerd had (of een oudere versie ervan) en weer verwijderd, configuratiebestanden die gewijzigd werden niet overschrijven. In plaats daarvan zal het u hierover informeren als volgt (echter alleen bij gebruik van de -v vlag!):
$ 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.
Om dit type van conflict op te lossen, moet u te weten komen wat u moet installeren om de vereiste libraries op uw systeem te krijgen. Er zijn verscheidene dingen die u kan controleren:
$ 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
Wanneer u een naam van een geïnstalleerde package (of een locatie van een package die geïnstalleerd moet worden), zal pkg_info(1) meer gedetailleerde informatie tonen over die specifieke package.
Stel dat u een oudere versie van unzip geïnstalleerd had alvorens deze doos te upgraden van OpenBSD 4.1 naar 4.2. Nu kan u gemakkelijk upgraden naar de nieuwere 4.2 package als volgt:
$ sudo pkg_add -u unzip
unzip-5.52 (extracting): complete
unzip-5.51 (deleting): complete
unzip-5.52 (installing): complete
Clean shared items: complete
Wanneer een package dependencies heeft, worden die ook onderzocht op updates. Het aanroepen van pkg_add(1) met de -u vlag en zonder package-naam zal alle geïnstalleerde packages proberen te updaten.
Opmerking: De -u optie steunt op de PKG_PATH omgevingsvariabele. Als die niet ingesteld is, zal pkg_add(1) geen updates kunnen vinden.
Vanaf OpenBSD 4.2 betekent het hebben van meerdere entries in PKG_PATH niet langer dat alle entries zullen geprobeerd worden voor update operaties. In plaats daarvan zal pkg_add(1) stoppen bij het eerste path met overeenstemmende kandidaten.
Als u een configuratiebestand had dat toebehoorde aan de oude versie en dat u gewijzigd hebt, zal dit standaard onaangeroerd blijven. U kan het echter vervangen door het standaard configuratiebestand van de nieuwe versie door pkg_add(1) aan te roepen met de -c vlag.
Om een package te verwijderen, neemt u gewoon de juiste naam van de package zoals getoond door pkg_info(1) (zie Opsommen van geïnstalleerde packages hierboven) en gebruikt u pkg_delete(1) om de package te verwijderen. In het onderstaande voorbeeld wordt de screen package verwijderd. Bemerk dat er soms instructies zijn van extra dingen die verwijderd moeten worden en die pkg_delete(1) niet voor u verwijderd heeft. Zoals bij de pkg_add(1) utility kan u de -v vlag gebruiken om meer uitgebreide uitvoer te krijgen.
$ sudo pkg_delete screen
screen-4.0.3p0: complete
Clean shared items: complete
Opmerking: Het is vaak niet nodig om de versienummers en flavors bij de package-naam te specificeren, aangezien pkg_delete(1) gewoonlijk zelf de volledige naam zal kunnen vinden. U moet de volledige package-naam specificeren (in het voorbeeld is dat screen-4.0.3p0) alleen als er dubbelzinnigheid mogelijk is wegens meerdere geïnstalleerde packages met de gespecificeerde naam. In dat geval kan pkg_delete(1) niet weten welke package het moet verwijderen.
Voor de veiligheid zal pkg_delete(1) geen configuratiebestanden verwijderen als ze gewijzigd werden. In plaats daarvan zal het u hierover inlichten als volgt:
$ 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)
Als u die configuratiebestanden liever automatisch verwijderd wil zien, kan u dat doen door de -c vlag te gebruiken.
$ 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
Het is altijd een goed idee om gedeeltelijke packages van uw systeem te verwijderen, en mogelijke problemen op te lossen die tot dit falen leidden. Het wijst er vaak op dat u geen zuiver systeem hebt waarbij alles via packages geïnstalleerd werd, maar waar mogelijk packages vermengd zijn met andere software die rechtstreeks vanaf broncode geïnstalleerd werd.
BELANGRIJKE OPMERKING: De ports tree is bedoeld voor gevorderde gebruikers. Iedereen wordt aangeraden de vooraf gecompileerde binaire packages te gebruiken. Stel GEEN beginnersvragen op de mailinglijsten zoals "Hoe kan ik de ports tree werkend krijgen?". Indien u vragen hebt over de ports tree, wordt verondersteld dat u de manual pagina's en deze FAQ gelezen hebt, en dat u in staat bent er mee te werken.
Naast de Makefile bevat iedere port ook tenminste het volgende:
Al deze informatie wordt bijgehouden in een directory-hiërarchie onder /usr/ports. Deze hiërarchie bevat drie speciale subdirectories:
Wanneer een gebruiker make(1) uitvoert in de subdirectory van een specifieke port, zal het systeem recursief de "dependency tree" aflopen, controleren of de vereiste dependencies geïnstalleerd zijn, ontbrekende dependencies bouwen en installeren, en vervolgens verder gaan met het bouwen van de gewenste port. Al het bouwen gebeurt binnen de werkdirectory die de port aanmaakt. Dit is ofwel een subdirectory van de hoofddirectory van de port, in welk geval hij herkend wordt door zijn voorvoegsel "w-", of een subdirectory van ${WRKOBJDIR}, indien de WRKOBJDIR variabele ingesteld is (zie Configuratie van het ports systeem).
Opmerking: Ports worden nooit rechtstreeks op uw systeem geïnstalleerd! Ze gebruiken een valse ("fake") installatiedirectory. Al wat daar geïnstalleerd wordt, wordt samengebundeld in een package (die opgeslagen wordt in de packages/ subdirectory van de ports tree zoals eerder vermeld). Het installeren van een port betekent werkelijk: een package aanmaken, en vervolgens die package installeren!
Meer informatie over het ports systeem vindt u terug in deze manual pagina's:
| Bron | Form | "Flavor" | |||
| -release | -stable | snapshots | -current | ||
| CD-ROM | .tar.gz | x | - | - | - |
| FTP mirrors | .tar.gz | x | - | x | - |
| AnonCVS | cvs checkout | x | x | - | x |
Zoek op de CD-ROM en FTP mirrors naar een bestand met de naam ports.tar.gz. U wil dit bestand untarren in de /usr directory, wat /usr/ports zal aanmaken, en alle directories daaronder. Bijvoorbeeld:
$ cd /tmp
$ ftp ftp://ftp.openbsd.org/pub/OpenBSD/4.2/ports.tar.gz
$ cd /usr
$ sudo tar xzf /tmp/ports.tar.gz
De snapshots beschikbaar op de FTP mirrors worden dagelijks gegenereerd vanaf de -current ports tree. U zal de snapshots terugvinden in de pub/OpenBSD/snapshots/ directory. Indien u een snapshot van de ports tree gebruikt, moet u een overeenstemmende snapshot van OpenBSD geïnstalleerd hebben. Let erop dat u uw ports tree en uw OpenBSD systeem synchroon houdt!
Lees voor meer informatie over het bekomen van de ports tree via AnonCVS alstublieft de AnonCVS pagina die een lijst van beschikbare servers en een aantal voorbeelden bevat.
OPMERKING: Deze sectie introduceert enkele bijkomende globale instellingen om toepassingen vanuit ports te bouwen. U kan deze sectie overslaan, maar dan zal u veel van de make(1) opdrachten in de voorbeelden als root moeten uitvoeren.
Omdat het OpenBSD project niet de middelen heeft om de broncode van alle software in de ports tree na te kijken, kan u het ports systeem configureren om een aantal veiligheidsmaatregelen te nemen. De ports infrastructuur kan al het bouwen als een gewone gebruiker uitvoeren, en alleen die stappen die supergebruiker-privileges vereisen, als root uitvoeren. Voorbeelden zijn de fake en install make targets. Omdat root-privileges echter steeds vereist zijn op een bepaald ogenblik, zal het ports systeem u niet redden wanneer u beslist een kwaadwillige toepassing te bouwen.
SUDO=/usr/bin/sudo
# chgrp -R wsrc /usr/ports
# find /usr/ports -type d -exec chmod g+w {} \;
USE_SYSTRACE=Yes
Het is mogelijk om een "read-only" ports tree te gebruiken door de directories waarnaar geschreven wordt tijdens het bouwen van ports, af te zonderen:
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
Dit mechanisme is echter vrij eenvoudig, het draait gewoon awk(1) op het ports indexbestand. Sinds OpenBSD 4.0 werd een nieuwe port, "sqlports" genaamd, aangemaakt, die toelaat heel nauwkeurig te zoeken met behulp van SQL. Het is een SQLite database, maar eigenlijk kan eender welk databaseformaat aangemaakt worden met de ports infrastructuur. De sqlports port bevat een script om de database te genereren, dat zou gebruikt kunnen worden als basis om databases in verschillende formaten te genereren.
Voeg gewoon de sqlports package toe met pkg_add(1), en in dit geval, de sqlite3 package om van start te gaan. Een voorbeeldsessie zou er als volgt kunnen uitzien:
$ 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.6p0 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
Zoals u kan zien, doet het ports systeem vele dingen automatisch. Het zal de broncode afhalen, uitpakken en patchen, de broncode configureren en bouwen (compileren), de bestanden in een valse ("fake") directory installeren, een package aanmaken (in overeenstemming met de inpaklijst) en deze package installeren op uw systeem (gewoonlijk onder /usr/local/). En het doet dit recursief voor alle dependencies van de port. Let gewoon op de "===> Verifying install for ..." en "===> Returning to build of ..." lijnen in de bovenstaande uitvoer, die het aflopen van de "dependency tree" aangeven.
Indien een vorige versie van de toepassing die u wil installeren, reeds geïnstalleerd was op uw systeem, kan u make update gebruiken in plaats van make install. Dit zal pkg_add(1) aanroepen met de -r vlag.
Opmerking: Het bouwen van grote toepassingen zal veel systeemmiddelen vergen. Goede voorbeelden zijn compilers zoals GCC 4.0 of de Java 2 Software Development Kit. Indien u "out of memory" of gelijkaardige fouten krijgt bij het bouwen van zulke ports, heeft dit gewoonlijk één van deze twee redenen:
$ 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.9 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
Het eerste mechanisme heet flavors. Een flavor geeft gewoonlijk een bepaalde verzameling compilatie-opties aan. Sommige toepassingen hebben bijvoorbeeld een "no_x11" flavor die gebruikt kan worden op systemen zonder X. Sommige shells hebben een "static" flavor, die een statisch gelinkte versie zal bouwen. Er zijn ports die verschillende flavors hebben om ze te bouwen met verschillende grafische toolkits. Andere voorbeelden zijn: ondersteuning voor verschillende databankformaten, verschillende netwerkopties (SSL, IPv6, ...), verschillende papiergroottes, enz.
Samenvatting: Heel waarschijnlijk zal u flavors gebruiken wanneer een package niet beschikbaar gemaakt werd voor de flavor die u zoekt. In dit geval zal u de gewenste flavor specificeren en zelf de port bouwen.
De meeste port flavors zullen hun eigen werkdirectory hebben tijdens het bouwen en elke flavor zal gebundeld worden in een package met overeenstemmende naam om verwarring te vermijden. Om de verschillende flavors van een bepaalde port te zien, kan u in zijn subdirectory gaan staan en dit uitvoeren:
$ make show=FLAVORS
Het tweede mechanisme heet subpackages. Een porter kan beslissen om subpackages aan te maken voor verschillende onderdelen van dezelfde toepassing, indien ze logisch gescheiden kunnen worden. U zal vaak subpackages zien voor het clientgedeelte en het servergedeelte van een programma. Soms wordt uitgebreide documentatie gebundeld in een afzonderlijke subpackage omdat ze nogal veel schijfruimte inneemt. Extra functionaliteit die zware dependencies met zich meebrengt zal vaak afzonderlijk verpakt worden. De porter zal ook beslissen welke subpackage de hoofdpackage is die standaard zal geïnstalleerd worden. Andere voorbeelden zijn: uitgebreide testpakketten die bij de software zitten, afzonderlijke modules met ondersteuning voor verschillende dingen, enz.
Samenvatting: Sommige ports worden in verschillende packages verdeeld. make install zal alleen de hoofdpackage installeren.
Om de verschillende packages te tonen die gebouwd worden door een port, gebruikt u $ make show=PACKAGES
make install zal slechts de eerste subpackage installeren.
Om ze allemaal te installeren, gebruikt u
$ make install-all
Om de verschillende subpackages op te sommen die beschikbaar zijn voor een port, gebruikt u
$ make show=MULTI_PACKAGES
$ env SUBPACKAGE="-server" make install
Opmerking: Het subpackages mechanisme behandelt alleen packages, het wijzigt geen configuratie-opties vóór het bouwen van de port. Voor dat doel moet u flavors gebruiken.
Het is zeer waarschijnlijk dat u een systeem en ports tree gebruikt die niet synchroon zijn.
Excuseer?
Een andere veel voorkomende fout is een ontbrekende X11 installatie. Zelfs als de port die u probeert te bouwen niet rechtstreeks afhangt van X11, kan een subpackage ervan of kunnen de dependencies ervan X11 headers en libraries vereisen. Ports bouwen op systemen zonder X11 wordt niet ondersteund, dus als u er op aandringt om dit toch te doen, moet u zelf maar uitzoeken hoe het werkt. Voor heel wat ports zijn er echter "no_x11" ge-"flavor"de packages beschikbaar, die u kan installeren zonder dat u X11 nodig hebt op uw systeem.
Voor 4.2 vereisen nu vele packages die libexpat gebruiken dat xbase42.tgz geïnstalleerd is, zelfs al hebben ze geen grafische functionaliteit. Dit zal opgelost worden voor 4.3.
WAARSCHUWING: Meng GEEN versies van Ports en OpenBSD!
Dit toch doen zal u vroeg of laat (waarschijnlijk zelfs erg vroeg) hoofdpijn bezorgen wanneer u allerlei fouten probeert op te lossen!
Maar hey, ik ben hier helemaal -current!
De ports verzameling is een vrijwilligersproject. Soms heeft het project gewoon niet de mankracht wat betreft ontwikkelaars om alles up-to-date te houden. Ontwikkelaars pikken eigenlijk gewoon op wat ze interessant vinden en kunnen testen in hun omgeving. Uw schenkingen kunnen een verschil maken voor het testen van ports op meer platformen.
Sommige ports kunnen hierom achterop lopen op de hoofdversies. De ports verzameling kan een versie bevatten van een programma uit januari terwijl een nieuwe versie van het programma al door de ontwikkelaars ervan uitgebracht werd in mei drie maanden geleden. Vaak is dit een bewuste beslissing; de nieuwe versie kan problemen hebben op OpenBSD die de maintainer probeert op te lossen, of die de toepassing gewoon slechter gemaakt hebben dan de oude versie: OpenBSD kan verschillende doelstellingen hebben dan de hoofdontwikkelaars in andere projecten, wat soms leidt tot functionaliteiten of implementatiekeuzes die niet wenselijk zijn vanuit het standpunt van OpenBSD ontwikkelaars. De update kan ook uitgesteld worden omdat de nieuwe versie niet beschouwd wordt als een cruciale update.
Als u echt een nieuwe versie van een port nodig hebt, kan u best aan de maintainer van de port vragen de port te updaten (zie hieronder om te weten te komen wie de maintainer is). Als u hierbij kan helpen, des te beter.
U kan helpen. Overweeg uw eigen port te creëren. Er is hierover wat documentatie beschikbaar: Een OpenBSD Port bouwen. Lees ze, en lees ze opnieuw. Vooral het gedeelte over het onderhouden van uw port. Probeer vervolgens een nieuwe port te maken, en test hem zorgvuldig en stap voor stap. Als hij uiteindelijk goed werkt voor u, dien hem dan in op de ports mailinglijst op ports@openbsd.org. Er is een goede kans dat u van andere mensen wat feedback en tests zal krijgen. Als het testen succesvol gebeurt, zal het in overweging genomen worden om uw port op te nemen in de ports tree.
Verdere antwoorden op deze vraag vindt u ook in FAQ 1.
Een complexe toepassing vanaf broncode bouwen is niet triviaal. Niet alleen moet de toepassing gecompileerd worden, maar de tools die gebruikt worden om ze te bouwen, moeten ook gebouwd worden. Jammer genoeg zijn OpenBSD, de tools en de toepassing allemaal bezig te evolueren, en vaak is het een uitdaging om alle stukken te laten samenwerken. Zodra alles werkt, kan een herziening in gelijk welk onderdeel de volgende dag er voor zorgen dat het niet meer werkt. Iedere zes maanden, wanneer een nieuwe uitgave van OpenBSD gemaakt wordt, wordt er moeite gedaan om het bouwen van elke port op elk platform te testen, maar tijdens de ontwikkelingscyclus is het waarschijnlijk dat er enkele ports zullen breken.
Bovenop het laten samenwerken van alle onderdelen, is er nog de kwestie van tijd en middelen die vereist zijn om bepaalde toepassingen vanaf broncode te bouwen. Een goed voorbeeld is CVSup, een tool die veel gebruikt wordt om de OpenBSD source tree te volgen. CVSup installeren op een systeem van gemiddelde snelheid met een goede Internetverbinding kan slechts tien seconden vergen -- de tijd die vereist is om een enkel 779kB package bestand te downloaden en uit te pakken. Daarentegen is het bouwen van CVSup vanaf broncode op dezelfde machine een enorme taak, die vele tools en het bootstrappen van een compiler vereist, wat op dezelfde machine bijna een half uur duurt. Andere toepassingen, zoals Mozilla of KDE kunnen uren tijd en enorme hoeveelheden schijfruimte en RAM/swap vergen om te bouwen. Waarom zoveel tijd en moeite besteden, wanneer programma's reeds gecompileerd zijn en klaar zitten op uw CD-ROM of FTP mirror, wachtend om gebruikt te worden?
Natuurlijk zijn er enkele goede redenen om in sommige gevallen toch ports te gebruiken en niet packages:
$ cd /usr/ports/archivers/unzip
$ make show=MAINTAINER
Anders, als er geen maintainer is, of als u hem/haar niet kan bereiken, zend dan een e-mail naar de OpenBSD ports mailinglijst, ports@openbsd.org. Gebruik alstublieft NIET de misc@openbsd.org mailinglijst voor vragen over ports.
Geef in elk geval alstublieft:
$ mkdir ~/portslogs
$ cd /usr/ports/archivers/unzip
$ make clean install 2>&1 | /usr/ports/infrastructure/build/portslogger \
~/portslogs
Anders kan u ook
[FAQ Index] [Naar Sectie 14 - Inrichting van de Schijf]
![[terug]](../../images/back.gif){kind=small}
www@openbsd.org