diff --git a/documentation/content/de/books/handbook/bsdinstall/_index.adoc b/documentation/content/de/books/handbook/bsdinstall/_index.adoc index 642107ce91..fab875854e 100644 --- a/documentation/content/de/books/handbook/bsdinstall/_index.adoc +++ b/documentation/content/de/books/handbook/bsdinstall/_index.adoc @@ -1,1062 +1,1062 @@ --- title: Kapitel 2. FreeBSD installieren part: Teil I. Erste Schritte prev: books/handbook/introduction next: books/handbook/basics --- [[bsdinstall]] = FreeBSD installieren :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :skip-front-matter: :table-caption: Tabelle :figure-caption: Abbildung :example-caption: Beispiel :xrefstyle: basic :relfileprefix: ../ :outfilesuffix: :sectnumoffset: 2 ifeval::["{backend}" == "html5"] :imagesdir: ../../../../images/books/handbook/bsdinstall/ endif::[] ifeval::["{backend}" == "pdf"] :imagesdir: ../../../../static/images/books/handbook/bsdinstall/ endif::[] ifeval::["{backend}" == "epub3"] :imagesdir: ../../../../static/images/books/handbook/bsdinstall/ endif::[] include::shared/authors.adoc[] include::shared/releases.adoc[] include::shared/de/mailing-lists.adoc[] include::shared/de/teams.adoc[] include::shared/de/urls.adoc[] toc::[] [[bsdinstall-synopsis]] == Übersicht Es gibt verschiedene Möglichkeiten, FreeBSD zu installieren, abhängig von der Einsatzumgebung. Dazu gehören: -* Abbilder von virtuellen Maschinen, die Sie herunterladen und in einer virtuellen Umgebung einsetzen können. Diese Abbilder können von der https://www.freebsd.org/where.html[FreeBSD Downloadseite] heruntergeladen werden. Es gibt Abbilder für KVM ("qcow2"), VMWare ("vmdk"), Hyper-V ("vhd"), sowie Raw-Device Abbilder, die durchgängig unterstützt werden. Dies sind keine Installationsabbilder, sondern vorkonfigurierte ("bereits installierte") Instanzen, die sofort gestartet und konfiguriert werden können. +* Abbilder von virtuellen Maschinen, die Sie herunterladen und in einer virtuellen Umgebung einsetzen können. Diese Abbilder können von der https://www.freebsd.org/where/[FreeBSD Downloadseite] heruntergeladen werden. Es gibt Abbilder für KVM ("qcow2"), VMWare ("vmdk"), Hyper-V ("vhd"), sowie Raw-Device Abbilder, die durchgängig unterstützt werden. Dies sind keine Installationsabbilder, sondern vorkonfigurierte ("bereits installierte") Instanzen, die sofort gestartet und konfiguriert werden können. * Abbilder von virtuellen Maschinen, die auf Amazon's https://aws.amazon.com/marketplace/pp/B07L6QV354[AWS Marketplace], https://azuremarketplace.microsoft.com/en-us/marketplace/apps?search=freebsd&page=1[Microsoft Azure Marketplace] und https://console.cloud.google.com/launcher/details/freebsd-cloud/freebsd-12[Google Cloud Platform] verfügbar sind, um auf den jeweiligen Hosting-Diensten ausgeführt zu werden. Weitere Informationen zur Bereitstellung von FreeBSD auf Azure finden Sie im entsprechenden Kapitel der https://docs.microsoft.com/en-us/azure/virtual-machines/linux/freebsd-intro-on-azure[ Azure Dokumentation]. -* SD-Karten Abbilder für eingebettete Systeme wie den Raspberry Pi oder BeagleBone Black. Diese Abbilder können von der https://www.freebsd.org/where.html[ FreeBSD Downloadseite] heruntergeladen werden. Die Dateien müssen unkomprimiert und als Raw-Image auf eine SD-Karte geschrieben werden, von der das System dann booten wird. +* SD-Karten Abbilder für eingebettete Systeme wie den Raspberry Pi oder BeagleBone Black. Diese Abbilder können von der https://www.freebsd.org/where/[ FreeBSD Downloadseite] heruntergeladen werden. Die Dateien müssen unkomprimiert und als Raw-Image auf eine SD-Karte geschrieben werden, von der das System dann booten wird. * Installationsabbilder, um FreeBSD auf einer Festplatte für die üblichen Desktop-, Laptop- oder Serversysteme zu installieren. Der Rest dieses Kapitels beschreibt den vierten Fall und erklärt, wie man FreeBSD mit dem textbasierten Installationsprogramm bsdinstall installiert. Die Installationsanweisungen in diesem Kapitel gelten für die i386(TM)- und AMD64-Architekturen. Gegebenenfalls werden spezifische Anweisungen für andere Plattformen erwähnt. Möglicherweise gibt es auch geringfügige Unterschiede zwischen dem Installationsprogramm und dem, was hier gezeigt wird. Sie sollten dieses Kapitel daher als eine Art Wegweiser und nicht als exakte Anleitung betrachten. [NOTE] ==== Benutzer, die es vorziehen, FreeBSD mit einem graphischen Installationsprogramm zu installieren, sind vielleicht an https://www.furybsd.org[FuryBSD], https://ghostbsd.org[GhostBSD] oder https://www.midnightbsd.org[MidnightBSD] interessiert. ==== Nachdem Sie dieses Kapitel gelesen haben, werden Sie wissen: * welche Mindestanforderungen an die Hardware gestellt werden und welche Architekturen FreeBSD unterstützt. * wie man FreeBSD Installationsmedien erstellt. * wie man bsdinstall startet. * welche Fragen bsdinstall stellt, was sie bedeuten und wie man diese beantwortet. * wie Sie Fehler bei der Installation beheben. * wie Sie eine Live-Version von FreeBSD ausprobieren können, bevor Sie die Installation starten. Bevor Sie dieses Kapitel lesen, sollten Sie: * Die Liste von unterstützter Hardware lesen, die mit der zu installierenden Version von FreeBSD ausgeliefert wird, um sicherzustellen, dass die Hardware auch unterstützt wird. [[bsdinstall-hardware]] == Minimale Hardwareanforderungen Die Hardwareanforderungen zur Installation von FreeBSD variieren mit der Architektur. Hardwarearchitekturen und von FreeBSD unterstützte Geräte sind auf der Seite link:https://www.FreeBSD.org/releases/[FreeBSD Release Informationen] aufgelistet. Die link:https://www.FreeBSD.org/where/[FreeBSD Download Seite] enthält Informationen zur Auswahl des richtigen Abbilds für verschiedene Architekturen. Für die Installation von FreeBSD sind mindestens 96 MB RAM und 1.5 GB freier Festplattenspeicher erforderlich. Allerdings ist eine solch geringe Menge an Arbeitsspeicher und Speicherplatz nur für spezifische Anwendungen ausreichend, beispielsweise für Embedded-Geräte. Desktop-Systeme benötigen weitaus mehr Ressourcen. 2-4 GB RAM und mindestens 8 GB Speicherplatz sind ein guter Anfang. Dies sind die Anforderungen an den Prozessor für jede Architektur: amd64:: Dies ist die gängigste Art von Prozessor für Desktop- und Laptop-Systeme. Andere Anbieter nennen diese Architektur auch x86-64. + Beispiele für amd64-kompatible Prozessoren umfassen: AMD Athlon(TM)64, AMD Opteron(TM), multi-core Intel(R) Xeon(TM) und Intel(R) Core(TM) 2 sowie neuere Prozessoren. i386:: Ältere Desktop- und Laptop-Systeme verwenden oft die 32-Bit x86-Architektur. + Fast alle i386-kompatiblen Prozessoren mit einer Floating-Point-Einheit werden unterstützt. Alle Intel(R)-Prozessoren 486 oder neuer werden unterstützt. + FreeBSD nutzt die Physical Adress Extensions (PAE), falls die CPU diese Funktion unterstützt. Wenn PAE im Kernel aktiviert ist, wird Speicher über 4 GB vom Kernel erkannt und kann von System verwendet werden. PAE schränkt allerdings auch die Gerätetreiber und anderen Komponenten von FreeBSD ein. powerpc:: Alle New Word ROM Apple(R) Mac(R)-Systeme mit integriertem USB werden unterstützt. SMP wird auf Maschinen mit mehreren CPUs unterstützt. + Ein 32-Bit Kernel kann jedoch nur die ersten 2 GB RAM verwenden. sparc64:: Systeme, die von FreeBSD/sparc64 unterstützt werden, sind auf der link:https://www.FreeBSD.org/platforms/sparc/[FreeBSD/sparc64-Projektseite] aufgelistet. + SMP wird auf allen Systemen mit mehr als einem Prozessor unterstützt. Eine dedizierte Platte wird benötigt, da es nicht möglich ist, eine Platte mit einem anderen Betriebssystem zur gleichen Zeit zu teilen. [[bsdinstall-pre]] == Vor der Installation Wenn das System die Mindestanforderungen für die Installation von FreeBSD erfüllt, sollte die Installationsdatei heruntergeladen und die Installationsmedien vorbereitet werden. Bevor Sie dies tun, prüfen Sie mit Hilfe dieser Checkliste, ob das System für die Installation bereit ist: [.procedure] . *Sichern Sie wichtige Daten* + Erstellen Sie _immer_ eine Sicherung aller wichtigen Daten, _bevor_ Sie ein Betriebssystem installieren. Speichern Sie die Daten jedoch nicht auf dem System, auf dem das Betriebssystem installiert wird, sondern nutzen Sie einen Wechseldatenträger, wie beispielsweise ein USB-Laufwerk, oder sichern Sie auf einem anderen System im Netzwerk, oder nutzen einen Online-Backup-Dienst. Überprüfen Sie die Sicherungen, bevor Sie mit der Installation beginnen. Sobald das Installationsprogramm die Festplatte des Systems formatiert, gehen alle gespeicherten Daten unwiderruflich verloren. . *Den Installationsort von FreeBSD festlegen* + Falls FreeBSD das einzige installierte Betriebssystem sein wird, kann dieser Schritt übersprungen werden. Sollte FreeBSD allerdings die Platte mit anderen Betriebssystemen teilen, müssen Sie entscheiden, welche Platte oder Partition für FreeBSD verwendet werden soll. + Für die Architekturen i386 und amd64 können die Platten in mehrere Partitionen aufgeteilt werden. Dazu stehen Ihnen zwei Partitionsschemas zur Verfügung. Traditionell enthält ein _Master Boot Record_ (MBR) eine Partitionstabelle, welche bis zu vier _primäre Partitionen_ aufnehmen kann. Aus historischen Gründen werden diese primären Partitionen in FreeBSD _slices_ genannt. Eine Begrenzung von nur vier Partitionen ist für große Platten sehr beschränkt, so dass eine dieser primären Partitionen als _erweiterte Partition_ eingesetzt wird. Mehrere _logische Partitionen_ können dann innerhalb der erweiterten Partition angelegt werden. Die _GUID-Partitionstabelle_ (GPT) ist eine neuere und einfachere Methode zur Partition einer Festplatte. Geläufige GPT-Implementierungen erlauben bis zu 128 Partitionen pro Platte, was die Notwendigkeit von logischen Partitionen eliminiert. + FreeBSDs Standard-Bootloader benötigt entweder eine primäre oder eine GPT-Partition. Wenn alle primären oder GPT-Partitionen bereits in Verwendung sind, muss eine davon für FreeBSD zur Verfügung gestellt werden. Benutzen Sie ein Werkzeug zur Veränderung der Partitionsgrößen, wenn Sie eine Partition erstellen möchten, ohne dabei vorhandene Daten zu löschen. Den freigegebenen Platz können Sie dann für die Installation verwenden. + Eine Vielzahl freier und kommerzieller Werkzeuge zur Veränderung der Partitionsgrößen finden Sie unter http://en.wikipedia.org/wiki/List_of_disk_partitioning_software[ http://en.wikipedia.org/wiki/List_of_disk_partitioning_software]. GParted Live (http://gparted.sourceforge.net/livecd.php[http://gparted.sourceforge.net/livecd.php]) ist eine freie Live-CD, die den GParted-Partitionseditor enthält. GParted ist auch in einer Vielzahl von anderen Linux Live-CD Distributionen enthalten. + [WARNING] ==== Bei richtiger Anwendung können Werkzeuge zur Veränderung von Partitionsgrößen auf sichere Art und Weise Platz für eine neue Partition schaffen. Erstellen Sie trotzdem eine Vollsicherung und überprüfen Sie deren Integrität bevor Sie die Partitionen auf der Platte verändern. ==== + Festplattenpartitionen, die unterschiedliche Betriebssysteme enthalten, ermöglichen es, jeweils eines dieser Systeme zu verwenden. Eine alternative Möglichkeit, mehrere Betriebssysteme gleichzeitig einzusetzen, ohne dabei Partitionen ändern zu müssen, wird im crossref:virtualization[virtualization,Virtualisierung] behandelt. . *Netzwerkparameter ermitteln* + Manche FreeBSD Installationsarten benötigen eine Netzwerkverbindung, um Installationsdateien herunter zu laden. Nach jeder Installation bietet das Installationsprogramm die Möglichkeit, die Netzwerkschnittstellen des Systems zu konfigurieren. + Steht im Netzwerk ein DHCP-Server zur Verfügung, wird dieser im Allgemeinen verwendet, um automatisch Netzwerkeinstellungen vorzunehmen. Falls DHCP nicht verfügbar ist, müssen die folgenden Netzwerkeinstellungen beim lokalen Netzwerkadministrator oder Provider erfragt werden: [[bsdinstall-collect-network-information]] .. IP-Adresse .. Subnetz-Maske .. IP-Adresse des Default-Gateway .. Domänenname des Netzwerks .. IP-Adressen der DNS-Server im Netzwerk . *Lesen Sie die FreeBSD-Errata* + Obwohl das FreeBSD Projekt sich bemüht, jede veröffentlichte Version von FreeBSD so stabil wie möglich zu machen, können sich doch gelegentlich Fehler in den Veröffentlichungsprozess einschleichen. In sehr seltenen Fällen betreffen diese Fehler den Installationsvorgang. Wenn diese Probleme entdeckt und behoben sind, werden dazu Hinweise in der FreeBSD Errata (link:https://www.FreeBSD.org/releases/{rel121-current}r/errata/[https://www.freebsd.org/releases/{rel121-current}r/errata/]) auf der FreeBSD Webseite veröffentlicht. Prüfen Sie die Errata vor der Installation, um sicherzustellen, dass es keine Probleme gibt, welche die Installation betreffen. + Informationen und Errata für all diese Veröffentlichungen finden Sie unter den Release Informationen auf der FreeBSD Webseite (link:https://www.FreeBSD.org/releases/[https://www.freebsd.org/releases/]). [[bsdinstall-installation-media]] === Die Installationsmedien vorbereiten Das FreeBSD-Installationsprogramm ist keine Anwendung, das aus einem anderen Betriebssystem heraus gestartet werden kann. Laden Sie stattdessen eine Installationsdatei für FreeBSD herunter und brennen Sie den Dateityp auf einen entsprechenden Datenträger (CD, DVD, oder USB). Starten Sie dann das System mit diesem Datenträger. -Die FreeBSD-Installationsmedien sind unter link:https://www.FreeBSD.org/where/#download[www.freebsd.org/where/] verfügbar. Der Name der Installationsdatei enthält die Version von FreeBSD, die Architektur sowie den Dateityp. Wenn Sie beispielsweise FreeBSD 12.1 auf einem amd64-System von DVD installieren wollen, laden Sie [.filename]#FreeBSD-12.1-RELEASE-amd64-dvd1.iso# und brennen Sie die Datei auf eine DVD. Starten Sie dann das System mit dieser DVD. +Die FreeBSD-Installationsmedien sind unter link:https://www.FreeBSD.org/where/[www.freebsd.org/where/] verfügbar. Der Name der Installationsdatei enthält die Version von FreeBSD, die Architektur sowie den Dateityp. Wenn Sie beispielsweise FreeBSD 12.1 auf einem amd64-System von DVD installieren wollen, laden Sie [.filename]#FreeBSD-12.1-RELEASE-amd64-dvd1.iso# und brennen Sie die Datei auf eine DVD. Starten Sie dann das System mit dieser DVD. Die Installationsdateien stehen in verschiedenen Formaten zur Verfügung und variieren je nach Rechnerarchitektur und Medientyp. [[bsdinstall-installation-media-uefi]] Für Rechner, die mit UEFI (Unified Extensible Firmware Interface) booten, stehen zusätzliche Installationsdateien zur Verfügung. Die Namen dieser Dateien enthalten die Zeichenkette [.filename]#uefi#. Dateitypen: * `-bootonly.iso`: Dies ist die kleinste Installation, die lediglich das Installationsprogramm enthält. Hierzu ist während der Installation eine funktionierende Internetverbindung erforderlich, da das Installationsprogramm die benötigen Dateien für die FreeBSD-Installation herunter laden muss. Diese Datei sollte mit einem CD-Brennprogramm auf CD gebrannt werden. * `-disc1.iso`: Diese Datei enthält alle benötigten Dateien für eine FreeBSD-Installation, den Quellcode und die Ports-Sammlung. Die Datei sollte mit einem CD-Brennprogramm auf CD gebrannt werden. * `-dvd1.iso`: Diese Datei enthält alle benötigen Dateien für eine FreeBSD-Installation, den Quellcode und die Ports-Sammlung. Darüber hinaus enthält sie eine Reihe von beliebten Binärpaketen zur Installation eines Window-Managers, sodass Sie ein komplettes System installieren können, ohne dass Sie eine Verbindung zum Internet benötigen. Die Datei sollte mit einem DVD-Brennprogramm auf eine DVD gebrannt werden. * `-memstick.img`: Diese Datei enthält alle benötigten Dateien für eine FreeBSD-Installation, den Quellcode und die Ports-Sammlung. Die Datei sollte mit den nachstehenden Anweisungen auf einen USB-Stick geschrieben werden. * `-mini-memstick.img`: Diese Datei enthält, wie `-bootonly.iso`, keine Installationsdateien, sondern lädt diese bei Bedarf nach. Während der Installation wird eine funktionierende Internetverbindung benötigt. Schreiben Sie die Datei, wie in <> beschrieben, auf einen USB-Stick. Nachdem Sie die Datei heruntergeladen haben, laden Sie [.filename]#CHECKSUM.SHA256# aus dem gleichen Verzeichnis herunter. Berechnen Sie dann die _Prüfsumme_ für die Datei. FreeBSD bietet hierfür man:sha256[1], das Sie als `sha256 _Dateiname_` aufrufen können. Andere Betriebssysteme haben ähnliche Programme. Vergleichen Sie die berechnete Prüfsumme mit der in [.filename]#CHECKSUM.SHA256#. Die beiden Prüfsummen müssen übereinstimmen, ansonsten ist die Datei beschädigt und muss erneut heruntergeladen werden. [[bsdinstall-usb]] ==== Eine Installationsdatei auf einen USB-Stick schreiben Die [.filename]#\*.img#-Datei ist ein komplettes _Abbild_ (engl. Image) des späteren USB-Sticks. Die Datei kann _nicht_ auf das Zielgerät kopiert werden. Es existieren jedoch mehrere Programme, mit denen die [.filename]#*.img#-Datei auf einen USB-Stick geschrieben werden kann. In diesem Abschnitt werden zwei dieser Programme vorgestellt. [IMPORTANT] ==== Bevor Sie fortfahren, machen Sie Sicherungskopien der Daten auf dem USB-Stick. Diese Prozedur wird alle Daten auf dem Stick löschen. ==== [[bsdinstall-usb-dd]] [.procedure] **** *Procedure: Das Image mit `dd` auf einen USB-Stick schreiben* [WARNING] ==== Dieses Beispiel verwendet [.filename]#/dev/da0# als das Zielgerät, auf welches das Image geschrieben werden soll. Seien Sie _sehr vorsichtig_, dass das richtige Gerät benutzt wird, da das Kommando alle vorhandenen Daten auf dem Zielgerät zerstört. ==== . Das Werkzeug man:dd[1] steht unter BSD, Linux(R) und Mac OS(R)-Systemen zur Verfügung. Um das Image zu brennen, verbinden Sie den USB-Stick mit dem System und bestimmen Sie dessen Gerätenamen. Geben Sie dann den Namen der Installationsdatei und den Gerätenamen des USB-Sticks an. Dieses Beispiel schreibt die Installation für amd64 auf das erste USB-Gerät im FreeBSD-System. + [source,shell] .... # dd if=FreeBSD-12.1-RELEASE-amd64-memstick.img of=/dev/da0 bs=1M conv=sync .... + Wenn dieser Befehl fehlschlägt, stellen Sie sicher, dass der USB-Stick nicht eingehangen ist und prüfen Sie den Gerätenamen. Auf einigen Systemen muss der Befehl vielleicht mit Hilfe von man:sudo[8] ausgeführt werden. Die Syntax von man:dd[1] variiert leicht zwischen verschiedenen Plattformen. Zum Beispiel erfordert Mac OS(R) ein kleingeschriebenes `bs=1m`. Einige Systeme wie Linux(R) verwenden vielleicht einen Puffer. Verwenden Sie dann man:sync[8], um die Daten zu schreiben. **** [.procedure] **** *Procedure: Das Image unter Windows(R) schreiben* [WARNING] ==== Versichern Sie sich, dass Sie den korrekten Laufwerksbuchstaben angeben, da die bestehenden Daten des Laufwerks überschrieben und zerstört werden. ==== . Image Writer für Windows(R) herunterladen + Image Writer für Windows(R) ist eine frei verfügbare Anwendung, welche eine Imagedatei korrekt auf einen USB-Stick schreiben kann. Laden Sie diese von https://sourceforge.net/projects/win32diskimager/[ https://sourceforge.net/projects/win32diskimager/] herunter und entpacken Sie sie in ein Verzeichnis. . Das Image mit Image Writer auf den USB-Stick schreiben + Klicken Sie doppelt auf das Win32DiskImager-Icon, um das Programm zu starten. Prüfen Sie dabei, dass der Laufwerksbuchstabe unter `Device` dem Gerät entspricht, in dem sich der USB-Stick befindet. Klicken Sie auf das Ordnersymbol und wählen Sie das Image aus, welches auf den USB-Stick geschrieben werden soll. Um den Image-Dateinamen zu akzeptieren, klicken Sie auf btn:[Save]. Überprüfen Sie erneut, ob alles stimmt und dass keine Ordner auf dem USB-Stick in anderen Fenstern geöffnet sind. Sobald alles bereit ist, klicken Sie auf btn:[Write], um die Imagedatei auf den USB-Stick zu schreiben. **** Sie sind jetzt dazu bereit, mit der Installation von FreeBSD zu beginnen. [[bsdinstall-start]] == Die Installation starten [IMPORTANT] ==== Es werden bei Installation so lange keine Änderungen an den Festplatten durchgeführt, bis die folgende Meldung erscheint: [.programlisting] .... Your changes will now be written to disk. If you have chosen to overwrite existing data, it will be PERMANENTLY ERASED. Are you sure you want to commit your changes? .... Die Installation kann vor dieser Warnung zu jeder Zeit abgebrochen werden. Falls Zweifel bestehen, dass etwas falsch konfiguriert wurde, schalten Sie einfach den Computer vor diesem Punkt aus und es werden keine Änderungen an der Festplatte vorgenommen. ==== Dieser Abschnitt beschreibt, wie das System vom Installationsmedium, das nach den Anweisungen in <> erstellt wurde, gebootet wird. Wenn Sie einen bootfähigen USB-Stick einsetzen, verbinden Sie diesen mit dem System, bevor Sie den Computer einschalten. Falls die Installation von einer CD startet, müssen Sie den Computer einschalten und die CD so bald wie möglich einlegen. Wie das System konfiguriert werden muss, um von dem verwendeten Installationsmedium zu booten, hängt von der Architektur ab. [[bsdinstall-starting-i386]] === Systemstart von i386(TM) und amd64 Diese Architekturen beinhalten ein BIOS-Menü zur Auswahl des Boot-Gerätes. Abhängig von dem verwendeten Installationsmedium können Sie CD/DVD oder USB als erstes Boot-Gerät auswählen. Die meisten Systeme erlauben es auch, das Boot-Gerät während des Startvorgangs zu wählen, typischerweise durch drücken von kbd:[F10], kbd:[F11], kbd:[F12] oder kbd:[Esc]. Falls der Computer wie normal startet und das bestehende Betriebssystem lädt, befolgen Sie einen der hier aufgeführten Schritte: . Das Installationsmedium wurde während des Startvorgangs nicht früh genug eingelegt. Lassen Sie das Medium eingelegt und versuchen Sie, den Rechner neu zu starten. . Die Änderungen am BIOS waren nicht richtig oder wurden nicht gespeichert. Überprüfen Sie, dass das richtige Boot-Gerät als erstes Boot-Gerät ausgewählt ist. . Das verwendete System ist zu alt und unterstützt das starten vom gewählten Medium nicht. In diesem Fall kann der Plop Boot Manager (http://www.plop.at/de/bootmanagers.html[]) verwendet werden, um ältere Computer von CD oder USB-Medien zu starten. === Systemstart beim PowerPC(R) Auf den meisten Maschinen können Sie kbd:[C] auf der Tastatur gedrückt halten, um von der CD zu starten. Andernfalls, halten Sie kbd:[Command+Option+O+F], oder kbd:[Windows+Alt+O+F] auf nicht-Apple(R) Tastaturen gedrückt. Geben Sie an der `0 >`-Eingabeaufforderung folgendes ein: [source,shell] .... boot cd:,\ppc\loader cd:0 .... [[bsdinstall-view-probe]] === FreeBSD Bootmenü Wenn das System vom Installationsmedium gestartet wird, erscheint folgendes Menü auf dem Bildschirm: [[bsdinstall-newboot-loader-menu]] .FreeBSD Boot Loader Menü image::bsdinstall-newboot-loader-menu.png[] In der Voreinstellung wird das Menü zehn Sekunden auf Benutzereingaben warten, bevor das Installationsprogramm gestartet wird. Drücken Sie die Leertaste, um den Timer anzuhalten. Um eine Option auszuwählen, drücken Sie die entsprechende Nummer bzw. Buchstaben. Die folgenden Optionen stehen zur Verfügung. * `Boot Multi User`: Dies wird den Boot-Prozess von FreeBSD fortsetzen. Wenn der Timer angehalten wurde, drücken Sie entweder die kbd:[1], kbd:[B], oder kbd:[Enter]. * `Boot Single User`: Dieser Modus kann verwendet werden, um eine bestehende FreeBSD-Installation zu reparieren. Dies wird in crossref:boot[boot-singleuser,“Der Single-User Modus”] beschrieben. Drücken Sie die kbd:[2] oder kbd:[S] um in diesen Modus zu gelangen. * `Escape to loader prompt`: Dieser Modus startet einen Prompt, welcher nur eine begrenzte Anzahl an Low-Level-Befehlen enthält. Dies wird in crossref:boot[boot-loader,“Phase Drei”] beschrieben. Drücken Sie die kbd:[3] oder kbd:[Esc] um in diesen Modus zu gelangen. * `Reboot`: Startet das System neu. * `Kernel`: Lädt einen anderen Kernel. * `Configure Boot Options`: Öffnet das Menü, welches in <> beschrieben ist. [[bsdinstall-boot-options-menu]] .FreeBSD Boot-Optionen Menü image::bsdinstall-boot-options-menu.png[] Das Boot-Optionen Menü ist in zwei Abschnitte unterteilt. Der erste Abschnitt wird verwendet, um zurück zum Hauptmenü zu gelangen, oder um Optionen zurück auf die Standardwerte zu setzen. Im zweiten Abschnitt können verschiedene Optionen auf `On` oder `Off` gesetzt werden. Das System wird bei einem Neustart immer mit den Einstellungen für diese Optionen booten: * `ACPI Support`: Wenn das System während des Bootens hängt, setzen Sie diese Option auf `Off`. * `Safe Mode`: Wenn das System trotz deaktiviertem `ACPI Support` immer noch hängt, setzen Sie diese Option auf `On`. * `Single User`: Setzen Sie die Option auf `On`, um eine bestehende FreeBSD-Installation zu reparieren. Dieser Prozess wird in crossref:boot[boot-singleuser,“Der Single-User Modus”] beschrieben. Sobald das Problem behoben ist, setzen Sie die Option wieder auf `Off`. * `Verbose`: Wenn Sie während des Bootens ausführliche Meldungen sehen möchten, zum Beispiel für die Fehlersuche bei Hardwareproblemen, setzen Sie diese Option auf `On`. Nachdem Sie die benötigten Auswahlen getroffen haben, drücken Sie die kbd:[1] oder die Rücktaste, um zum Hauptmenü zurückzukehren. Drücken Sie dann kbd:[Enter] um den FreeBSD Bootprozess fortzusetzen. Eine Reihe von Boot-Meldungen werden nun im Rahmen der Geräteerkennung von FreeBSD angezeigt. Sobald dieser Prozess abgeschlossen ist, erscheint das Menü aus <>. [[bsdinstall-choose-mode]] .Willkommen-Menü image::bsdinstall-choose-mode.png[] Wählen Sie hier btn:[Install] und drücken Sie kbd:[Enter], um in das Installationsprogramm zu gelangen. Der Rest dieses Kapitels beschreibt das Installationsprogramm. Andernfalls verwenden Sie die Pfeiltasten um einen anderen Menüpunkt auszuwählen. btn:[Shell] kann verwendet werden, um eine Shell zu starten und Zugriff auf die Kommandozeilenprogramme zu erhalten, damit beispielsweise die Platten vor der Installation vorbereitet werden können. btn:[Live CD] kann verwendet werden um FreeBSD vor der Installation auszuprobieren. Die Live-Version wird in <> beschrieben. [TIP] ==== Um sich die Boot-Meldungen und die Ergebnisse der Geräteerkennung erneut anzeigen zu lassen, drücken Sie kbd:[S] gefolgt von kbd:[Enter]. Dadurch wird eine Shell gestartet, in der Sie die Ereignisse seitenweise mit `more /var/run/dmesg.boot` lesen können. Geben Sie `exit` ein, um zum Willkommen-Menü zurückzukehren. ==== [[using-bsdinstall]] == Verwendung von bsdinstall Dieser Abschnitt zeigt die Reihenfolge der Menüs von bsdinstall sowie die Informationen, die während der Installation abgefragt werden. Benutzen Sie die Pfeiltasten zur Navigation und die Leertaste, um einen Menüpunkt zu aktivieren oder zu deaktivieren. Wenn Sie fertig sind, drücken Sie kbd:[Enter], um die Auswahl zu speichern und zum nächsten Bildschirm zu gelangen. [[bsdinstall-keymap]] === Die Tastaturbelegung auswählen Bevor die Installation gestartet wird, lädt bsdinstall die Tastaturbelegung, wie in <> gezeigt. [[bsdinstall-keymap-loading]] .Laden der Tastaturbelegung image::bsdinstall-keymap-loading.png[] Nachdem die Tastaturbelegung geladen wurde, zeigt bsdinstall das Menü aus <> an. Wählen Sie die Tastenbelegung, die der am System angeschlossenen Tastatur am nächsten kommt, indem Sie die Pfeiltasten Hoch/Runter verwenden und anschließend kbd:[Enter] drücken. [[bsdinstall-keymap-10]] .Bildschirm zur Auswahl der Tastaturbelegung image::bsdinstall-keymap-10.png[] [NOTE] ==== Durch drücken von kbd:[Esc] wird das Menü verlassen und die Standardbelegung eingestellt. [.guimenuitem]#United States of America ISO-8859-1# ist eine sichere Option, falls Sie sich unsicher sind, welche Auswahl Sie treffen sollen. ==== [[bsdinstall-keymap-testing]] .Bildschirm zum Testen der Tastaturbelegung image::bsdinstall-keymap-testing.png[] [[bsdinstall-hostname]] === Den Rechnernamen festlegen Das nächste bsdinstall-Menü konfiguriert den Rechnernamen, der für das neu zu installierende System verwendet werden soll. [[bsdinstall-config-hostname]] .Festlegen des Rechnernamens image::bsdinstall-config-hostname.png[] Geben Sie einen für das Netzwerk eindeutigen Rechnernamen an. Der eingegebene Rechnername sollte ein voll-qualifizierter Rechnername sein, so wie z.B. `machine3.example.com`. [[bsdinstall-components]] === Auswahl der zu installierenden Komponenten Im nächsten Schritt fragt Sie bsdinstall, die optionalen Komponenten für die Installation auszuwählen. [[bsdinstall-config-components]] .Komponenten für die Installation auswählen image::bsdinstall-config-components.png[] Die Entscheidung, welche Komponenten auszuwählen sind, hängt größtenteils davon ab, für was das System künftig eingesetzt werden soll und der zur Verfügung stehende Plattenplatz. Der FreeBSD-Kernel und die Systemprogramme (zusammengenommen auch als _Basissystem_ bezeichnet) werden immer installiert. Abhängig vom Typ der Installation, werden manche dieser Komponenten nicht erscheinen. * `base-dbg` - Basiswerkzeuge wie cat, ls und vielte weitere mit aktiviertem Debugging. * `kernel-dbg` - Kernel und Module mit aktiviertem Debugging. * `lib32-dbg` - Kompatibilitäts-Bibliotheken mit aktiviertem Debugging, für die Ausführung von 32-bit-Anwendungen auf einer 64-bit-Version von FreeBSD. * `lib32` - Kompatibilitäts-Bibliotheken, um 32-bit-Anwendungen auf der 64-bit Version von FreeBSD laufen zu lassen. * `ports` - Die FreeBSD Ports-Sammlung ist eine Sammlung von Dateien, die das herunterladen, erstellen und installieren von Drittanbietersoftware automatisiert. crossref:ports[ports,Installieren von Anwendungen: Pakete und Ports] behandelt die Verwendung der Ports-Sammlung. + [WARNING] ==== Das Installationsprogramm prüft nicht, ob genügend Plattenplatz zur Verfügung steht. Wählen Sie diese Option nur, wenn die Festplatte über ausreichend Speicher verfügt. Die Ports-Sammlung nimmt etwa {ports-size} Plattenplatz ein. ==== * `src` - Der vollständige FreeBSD Quellcode für den Kernel und die Systemprogramme. Obwohl dies für die meisten Anwendungen nicht benötigt wird, kann es doch für manche Gerätetreiber, Kernelmodule und einigen Anwendungen aus der Ports-Sammlung erforderlich sein. Der Quellcode wird auch benötigt um an FreeBSD selbst mitzuentwickeln. Der komplette Quellcodebaum benötigt 1 GB Plattenplatz und um das gesamte Betriebssystem neu zu erstellen, werden zusätzliche 5 GB Platz benötigt. * `tests` - FreeBSD Test-Suite. [[bsdinstall-netinstall]] === Installation aus dem Netzwerk Das Menü in <> erscheint nur bei der Installation von einer [.filename]#-bootonly.iso#-CD, da dieses Installationsmedium keine Kopien der Installationsdateien enthält. Da die Installationsdateien über eine Netzwerkverbindung abgerufen werden müssen, weist dieses Menü darauf hin, dass zunächst die Netzwerkschnittstelle konfiguriert werden muss. Falls dieses Menü während der Installation angezeigt wird, befolgen Sie die Anweisungen in <>. [[bsdinstall-netinstall-notify]] .Installation über das Netzwerk image::bsdinstall-netinstall-files.png[] [[bsdinstall-partitioning]] == Plattenplatz bereitstellen Im nächsten Menü wird die Methode bestimmt, um den Plattenplatz zuzuweisen. [[bsdinstall-zfs-partmenu]] .Partitionierung unter FreeBSD image::bsdinstall-zfs-partmenu.png[] bsdinstall bietet dem Benutzer vier Methoden zur Zuweisung von Plattenplatz: * `Auto (UFS)` richtet die Partitionen automatisch mit dem `UFS`-Dateisystems ein. * `Manual` ermöglicht es fortgeschrittenen Benutzern, angepasste Partitionen über Menüoptionen zu erstellen. * `Shell` öffnet eine Eingabeaufforderung, in der fortgeschrittene Benutzer angepasste Partitionen mit Werkzeugen wie man:gpart[8], man:fdisk[8] und man:bsdlabel[8] erstellen können. * `Auto (ZFS)` erzeugt ein root-on-ZFS-System mit optionaler GELI-Verschlüsselung für Boot Environments. Dieser Abschnitt beschreibt, was bei der Partitionierung der Platten zu beachten ist und wie die einzelnen Methoden zur Partitionierung angewendet werden. [[configtuning-initial]] === Ein Partitionslayout entwerfen Wenn Sie Dateisysteme anlegen, sollten Sie beachten, dass Festplatten auf Daten in den äußeren Spuren schneller zugreifen können als auf Daten in den inneren Spuren. Daher sollten die kleineren und oft benutzten Dateisysteme an den äußeren Rand der Platte gelegt werden. Die größeren Partitionen wie [.filename]#/usr# sollten in die inneren Bereiche gelegt werden. Es empfiehlt sich, die Partitionen in folgender Reihenfolge anzulegen: [.filename]#/#, swap, [.filename]#/var# und [.filename]#/usr#. Die Größe der [.filename]#/var#-Partition ist abhängig vom Zweck der Maschine. Diese Partition enthält hauptsächlich Postfächer, Logdateien und Druckwarteschlangen. Abhängig von der Anzahl an Systembenutzern und der Aufbewahrungszeit für Logdateien, können Postfächer und Logdateien unerwartete Größen annehmen. Die meisten Benutzer benötigen nur selten mehr als ein Gigabyte für [.filename]#/var#. [NOTE] ==== Ein paar Mal wird es vorkommen, dass viel Festplattenspeicher in [.filename]#/var/tmp# benötigt wird. Wenn neue Software mit man:pkg_add[1] installiert wird, extrahieren die Paketwerkzeuge eine vorübergehende Kopie der Pakete unter [.filename]#/var/tmp#. Die Installation großer Softwarepakete wie Firefox oder LibreOffice kann sich wegen zu wenig Speicherplatz in [.filename]#/var/tmp# als trickreich herausstellen. ==== Die [.filename]#/usr# Partition enthält viele der Hauptbestandteile des Systems, einschließlich der FreeBSD Ports-Sammlung und den Quellcode des Systems. Für diese Partition werden mindestens zwei Gigabyte empfohlen. Behalten Sie bei der Auswahl der Partitionsgrößen den Platzbedarf im Auge. Wenn Sie den Platz auf einer Partition vollständig aufgebraucht haben, eine andere Partition aber kaum benutzen, kann die Handhabung des Systems schwierig werden. Als Daumenregel sollten Sie doppelt soviel Speicher für die Swap-Partition vorsehen, als Sie Hauptspeicher haben, da die VM-Paging-Algorithmen im Kernel so eingestellt sind, dass sie am besten laufen, wenn die Swap-Partition mindestens doppelt so groß wie der Hauptspeicher ist. Zu wenig Swap kann zu einer Leistungsverminderung im VM page scanning Code führen, sowie Probleme verursachen, wenn später mehr Speicher in die Maschine eingebaut wird. Auf größeren Systemen mit mehreren SCSI-, oder IDE-Laufwerken an unterschiedlichen Controllern, wird empfohlen, Swap-Bereiche auf bis zu vier Laufwerken einzurichten. Diese Swap-Partitionen sollten ungefähr dieselbe Größe haben. Der Kernel kann zwar mit beliebigen Größen umgehen, aber die internen Datenstrukturen skalieren bis zur vierfachen Größe der größten Partition. Ungefähr gleich große Swap-Partitionen erlauben es dem Kernel, den Swap-Bereich optimal über die Laufwerke zu verteilen. Große Swap-Bereiche, auch wenn sie nicht oft gebraucht werden, sind nützlich, da sich ein speicherfressendes Programm unter Umständen auch ohne einen Neustart des Systems beenden lässt. Indem Sie ein System richtig partitionieren, verhindern Sie, dass eine Fragmentierung in den häufig beschriebenen Partitionen auf die meist nur gelesenen Partitionen übergreift. Wenn Sie die häufig beschriebenen Partitionen an den Rand der Platte legen, dann wird die I/O-Leistung dieser Partitionen steigen. Die I/O-Leistung ist natürlich auch für große Partitionen wichtig, doch erzielen Sie eine größere Leistungssteigerung, wenn Sie [.filename]#/var# an den Rand der Platte legen. [[bsdinstall-part-guided]] === Geführte Partitionierung für UFS Bei dieser Methode wird ein Menü die verfügbaren Platten anzeigen. Sollten mehrere Platten angeschlossen sein, wählen Sie diejenige aus, auf der FreeBSD installiert werden soll. [[bsdinstall-part-guided-disk]] .Aus mehreren Platten eine auswählen image::bsdinstall-part-guided-disk.png[] Nachdem Sie die Platte ausgewählt haben, fordert das nächste Menü dazu auf, entweder die gesamte Festplatte für die Installation zu nutzen oder eine Partition aus unbenutzten Speicherplatz zu erstellen. Ein allgemeines Partitionslayout, das die gesamte Platte einnimmt wird erstellt, wenn btn:[Entire Disk] ausgewählt wird. Durch die Wahl von btn:[Partition] wird ein Partitionslayout aus dem unbenutzten Speicherplatz der Platte erstellt. [[bsdinstall-part-entire-part]] .Auswahl der gesamten Platte oder einer Partition image::bsdinstall-part-entire-part.png[] Wenn btn:[Entire Disk] gewählt wurde, weist bsdinstall darauf hin, dass die Festplatte gelöscht wird. [[bsdinstall-ufs-warning]] .Bestätigung image::bsdinstall-ufs-warning.png[] Das nächste Menü zeigt eine Liste der verfügbaren Partitionsschemas. GPT ist ist normalerweise die geeignetste Wahl für amd64-Rechner. Ältere Rechner, die nicht mit GPT kompatibel sind, sollten MBR benutzen. Die anderen Partitionsschemas werden im Allgemeinen für ungewöhnliche oder ältere Rechner benutzt. Weitere Informationen finden Sie in <>. [[bsdinstall-ufs-scheme]] image::bsdinstall-part-manual-partscheme.png[] Nachdem das Partitionslayout nun erstellt wurde, sollten Sie es überprüfen, um sicherzustellen, dass es die Bedürfnisse der Installation erfüllt. Durch die Auswahl von btn:[Revert] können die Partitionen wieder auf den ursprünglichen Wert zurückgesetzt werden und durch btn:[Auto] werden die automatischen FreeBSD Partitionen wiederhergestellt. Partitionen können auch manuell erstellt, geändert oder gelöscht werden. Sollte die Partitionierung richtig sein, wählen Sie btn:[Finish] aus, um mit der Installation fortzufahren. [[bsdinstall-part-review]] .Überprüfen der erstellten Partitionen image::bsdinstall-part-review.png[] Sobald die Festplatten konfiguriert sind, bietet das nächste Menü die letzte Möglichkeit, Änderungen vorzunehmen, bevor die ausgewählten Laufwerke formatiert werden. Wenn Änderungen vorgenommen werden müssen, wählen Sie btn:[Back], um zum Hauptmenü zurückzukehren. Mit btn:[Revert & Exit] wird das Installationsprogramm beendet, ohne Änderungen am Laufwerk vorzunehmen. Wählen Sie btn:[Commit], um die Installation zu starten. [[bsdinstall-ufs-final-confirmation]] .Abschließende Konfiguration image::bsdinstall-final-confirmation.png[] Um mit der Installation fortzufahren, gehen Sie zu <>. [[bsdinstall-part-manual]] === Manuelle Partitionierung Diese Methode öffnet den Partitionseditor: [[bsdinstall-part-manual-create]] .Partitionen manuell erstellen image::bsdinstall-part-manual-create.png[] Durch hervorheben einer Platte (in diesem Fall [.filename]#ada0#) und die Auswahl von btn:[Create], wird ein Menü mit den verfügbaren Partitionierungsschemas angezeigt. [[bsdinstall-part-manual-partscheme]] .Partitionen manuell anlegen image::bsdinstall-part-manual-partscheme.png[] GPT ist normalerweise die beste Wahl für amd64-Computer. Ältere Computer, die nicht mit GPT kompatibel sind, sollten MBR verwenden. Die anderen Partitionsschemas werden für gewöhnlich für ältere Computersysteme benutzt. [[partition-schemes]] .Partitionierungsschemas [cols="1,1", frame="none", options="header"] |=== <| Abkürzung <| Beschreibung |APM |Apple Partition Map, verwendet von PowerPC(R). |BSD |BSD-Labels ohne einen MBR, manchmal auch "dangerously dedicated mode" genannt, da nicht-BSD Festplatten-Werkzeuge dies vielleicht nicht erkennen können. |GPT |GUID Partition Table (http://de.wikipedia.org/wiki/GUID_Partition_Table[http://en.wikipedia.org/wiki/GUID_Partition_Table]). |MBR |Master Boot Record (http://de.wikipedia.org/wiki/Master_Boot_Record[http://en.wikipedia.org/wiki/Master_boot_record]). |VTOC8 |Volume Table Of Contents, von Sun SPARC64 und UltraSPARC Computern verwendet. |=== Nachdem das Partitionierungsschema ausgewählt und erstellt wurde, werden durch erneute Auswahl von btn:[Create] die Partitionen erzeugt. Mit der kbd:[Tab]-Taste können Sie den Cursor zwischen den Feldern bewegen. [[bsdinstall-part-manual-addpart]] .Partitionen manuell erzeugen image::bsdinstall-part-manual-addpart.png[] Eine FreeBSD-Standardinstallation mit GPT legt mindestens die folgenden drei Partitionen an: * `freebsd-boot` - Enthält den FreeBSD-Bootcode. * `freebsd-ufs` - Ein FreeBSD UFS-Dateisystem. * `freebsd-zfs` - Ein FreeBSD ZFS-Dateisystem. Weitere Informationen finden Sie in crossref:zfs[zfs,Das Z-Dateisystem (ZFS)]. * `freebsd-swap` - FreeBSD Auslagerungsbereich (swap space). Die einzelnen GPT-Partitionstypen sind in man:gpart[8] dokumentiert. Es können mehrere Dateisystempartitionen erzeugt werden und manche Leute ziehen es vor, ein traditionelles Layout mit getrennten Partitionen für die Dateisysteme [.filename]#/#, [.filename]#/var#, [.filename]#/tmp# und [.filename]#/usr# zu erstellen. Lesen Sie dazu <>, um ein Beispiel zu erhalten. Größenangaben (`Size`) können mit gängigen Abkürzungen eingegeben werden: _K_ für Kilobytes, _M_ für Megabytes oder _G_ für Gigabytes. [TIP] ==== Korrekte Sektorausrichtung ermöglicht größtmögliche Geschwindigkeit und das Anlegen von Partitionsgrößen als vielfaches von 4K-Bytes hilft, die passende Ausrichtung auf Platten mit entweder 512-Bytes oder 4K-Bytes Sektorgrößen, festzulegen. Generell sollte die Verwendung von Partitionsgrößen, die sogar vielfache von 1M oder 1G sind, den einfachsten Weg darstellen, um sicher zu stellen, dass jede Partition an einem vielfachen von 4K beginnt. Eine Ausnahme gibt es: momentan sollte die _freebsd-boot_-Partition aufgrund von Beschränkungen im Bootcode nicht größer sein als 512K. ==== Ein Einhägepunkt (`Mountpoint`) wird benötigt, falls diese Partition ein Dateisystem enthält. Falls nur eine einzelne UFS-Partition erstellt wird, sollte der Einhängepunkt [.filename]#/# lauten. Ein `label` ist ein Name, durch den diese Partition angesprochen wird. Festplattennamen oder -nummern können sich ändern, falls die Platte einmal an einem anderen Controller oder Port angeschlossen sein sollte, doch das Partitionslabel ändert sich dadurch nicht. Anstatt auf Plattennamen und Partitionsnummern in Dateien wie [.filename]#/etc/fstab# zu verweisen, sorgen Labels dafür, dass das System Hardwareänderungen eher toleriert. GPT-Labels erscheinen in [.filename]#/dev/gpt/#, wenn eine Platte angeschlossen wird. Andere Partitionierungsschemas besitzen unterschiedliche Fähigkeiten, Labels zu verwenden und diese erscheinen in anderen [.filename]#/dev/#-Verzeichnissen. [TIP] ==== Vergeben Sie ein einzigartiges Label für jede Partition, um Konflikte mit identischen Labels zu verhindern. Ein paar Buchstaben des Computernamens, dessen Verwendungszweck oder Ortes kann dem Label hinzugefügt werden. Beispielsweise `labroot` oder `rootfslab` für die UFS Root-Partition auf einem Laborrechner namens `lab`. ==== [[bsdinstall-part-manual-splitfs]] .Ein traditionelles, partitioniertes Dateisystem erstellen [example] ==== Für ein traditionelles Partitionslayout, in dem sich [.filename]#/#, [.filename]#/var#, [.filename]#/tmp# und [.filename]#/usr# in getrennten Partitionen befinden sollen, erstellen Sie ein GPT-Partitionsschema und anschließend die Partitionen selbst. Die gezeigten Partitionsgrößen sind typisch für eine Festplatte von 20 G. Falls mehr Platz verfügbar ist, sind größere Swap oder [.filename]#/var#-Partitionen nützlich. Den hier gezeigten Beschreibungen sind `bsp` für "Beispiel" vorangestellt, jedoch sollten Sie andere, einzigartige Beschreibungen verwenden, wie oben beschrieben. Standardmäßig erwartet FreeBSDs [.filename]#gptboot#, dass die erste UFS-Partition die [.filename]#/#-Partition ist. [.informaltable] [cols="1,1,1,1", frame="none", options="header"] |=== | Partitionstyp | Grösse | Eingehängt als | Beschreibung |`freebsd-boot` |`512K` |`freebsd-ufs` |`2G` |[.filename]#/# |`bsprootfs` |`freebsd-swap` |`4G` |`bspswap` |`freebsd-ufs` |`2G` |[.filename]#/var# |`bspvarfs` |`freebsd-ufs` |`1G` |[.filename]#/tmp# |`bsptmpfs` |`freebsd-ufs` |Akzeptieren Sie die Standardeinstellungen (Rest der Platte) |[.filename]#/usr# |`bspusrfs` |=== ==== Nachdem die Partitionen erzeugt wurden, wählen Sie btn:[Finish], um die Installation mit <> fortzusetzen. [[bsdinstall-part-zfs]] === Geführte Partitionierung mit Root-on-ZFS Dieser Modus funktioniert nur mit ganzen Laufwerken und wird alle vorhandenen Daten auf der Platte löschen. Das Konfigurationsmenü für ZFS bietet einige Optionen, um die Erstellung des Pools zu beeinflussen. [[bsdinstall-zfs-menu]] .ZFS Konfigurationsmenü image::bsdinstall-zfs-menu.png[] Hier eine Zusammenfassung der Optionen, die in diesem Menü benutzt werden können: * `Install` - Setzt die Installation mit den ausgewählten Optionen fort. * `Pool Type/Disks` - Erlaubt die Konfiguration des `Pool Type` und der Festplatte(n), die den Pool bilden werden. Das ZFS-Installationsprogramm unterstützt derzeit nur die Erstellung eines einzelnen Top-Level-Vdev, außer im Stripe-Modus. Um komplexere Pools zu erstellen, folgen Sie den Anweisungen in <>, um den Pool zu erstellen. * `Rescan Devices` - Aktualisiert die Liste der verfügbaren Festplatten. * `Disk Info` - Dieses Menü wird verwendet, um Datenträger zu inspizieren, einschließlich ihrer Partitionstabelle und weitere Informationen wie die Modell- und Seriennummer des Geräts. * `Pool Name` - Legt den Namen des Pools fest. Der Standard ist _zroot_. * `Force 4K Sectors?` - Erzwingt die Verwendung von 4K-Sektoren. Im Standard erstellt die Installation automatisch Partitionen, die an 4K-Grenzen ausgerichtet sind. Bei ZFS wird die Verwendung von 4K-Sektoren erzwungen. Dies ist selbst bei Festplatten mit 512-Byte-Sektoren sicher und hat den zusätzlichen Vorteil, dass Pools, die auf solchen Festplatten mit erstellt werden, auch in Zukunft 4K-Sektoren haben können, entweder als zusätzlicher Speicherplatz oder als Ersatz für ausgefallene Platten. Drücken Sie kbd:[Enter], um die Verwendung von 4K-Sektoren zu konfigurieren. * `Encrypt Disks?` - Das Verschlüsseln der Datenträger mit GELI. Weitere Informationen zur Datenträgerverschlüsselung finden Sie in crossref:disks[disks-encrypting-geli,“Plattenverschlüsselung mit geli”]. Drücken Sie kbd:[Enter] um eine Auswahl zu treffen. * `Partition Scheme` - Erlaubt die Auswahl des Partitionsschemas. GPT ist die empfohlene Option. Drücken Sie kbd:[Enter], um zwischen den verschiedenen Optionen zu wählen. * `Swap Size` - Legt die Größe des Swap-Speichers fest. * `Mirror Swap?` - Erlaubt es, den Swap-Speicher zwischen den Platten zu spiegeln. Beachten Sie jedoch, dass die Aktivierung dazu führt, dass Crash Dumps nicht mehr funktionieren. Drücken Sie kbd:[Enter], um diese Option zu aktivieren/deaktivieren. * `Encrypt Swap?` - Erlaubt es, den Swap-Speicher zu verschlüsseln. Der Swap-Speicher wird bei jedem Systemstart mit einem temporären Schlüssel verschlüsselt, der bei einem Neustart des Systems verworfen wird. Drücken Sie kbd:[Enter], diese Option zu aktivieren/deaktivieren. Weitere Informationen zur Verschlüsselung des Swap-Speichers finden Sie in crossref:disks[swap-encrypting,“Den Auslagerungsspeicher verschlüsseln”]. Wählen Sie kbd:[T] um den Pool Typ und die Festplatte(n) zu konfigurieren, die den Pool bilden werden. [[bsdinstall-zfs-vdev_type]] .ZFS Pool Typen image::bsdinstall-zfs-vdev_type.png[] Hier eine Zusammenfassung der Pool-Typen, die in diesem Menü ausgewählt werden können: * `stripe` - Striping bietet maximalen Speicherplatz für alle angeschlossenen Geräte, aber keine Redundanz. Fällt eine Platte aus, sind die Daten im Pool unwiderruflich verloren. * `mirror` - Bei der Spiegelung wird eine vollständige Kopie aller Daten auf jeder Platte gespeichert. Die Spiegelung bietet eine gute Leistung beim Lesen, da die Daten von allen Platten parallel gelesen werden. Die Leistung beim Schreiben ist langsamer, da die Daten auf alle Platten im Pool geschrieben werden müssen. Hiermit können alle Platten bis auf eine ausfallen. Diese Option erfordert mindestens zwei Platten. * `raid10` - Striped Mirrors. Bieten die beste Leistung, aber den geringsten Speicherplatz. Diese Option erfordert mindestens eine gerade Anzahl von Platten und mindestens vier Platten. * `raidz1` - Einzelnes redundantes RAID. Ermöglicht den Ausfall einer Platte. Für diese Option sind mindestens drei Festplatten erforderlich. * `raidz2` - Doppeltes redundantes RAID. Ermöglicht den Ausfall von zwei Platten. Für diese Option sind mindestens vier Festplatten erforderlich. * `raidz3` - Dreifaches redundantes RAID. Ermöglicht den Ausfall von drei Platten. Für diese Option sind mindestens fünf Festplatten erforderlich. Sobald ein Pool-Typ (`Pool Type`) ausgewählt wurde, wird eine Liste der verfügbaren Laufwerke angezeigt und der Benutzer wird aufgefordert, eine oder mehrere Laufwerke für die Erstellung des Pools auszuwählen. Anschließend wie die Konfiguration geprüft um zu gewährleisten, dass genug Laufwerke ausgewählt wurden. Wählen Sie btn:[] um zur Auswahl der Laufwerke zurückzukehren, oder btn:[] um den `Pool Type` zu ändern. [[bsdinstall-zfs-disk_select]] .Auswahl der Laufwerke image::bsdinstall-zfs-disk_select.png[] [[bsdinstall-zfs-vdev_invalid]] .Ungültige Auswahl image::bsdinstall-zfs-vdev_invalid.png[] Wenn eine oder mehrere Platten in der Liste fehlen, oder wenn Festplatten angebunden wurden, nachdem das Installationsprogramm gestartet wurde, wählen Sie btn:[- Rescan Devices] um die Laufwerke nochmals zu suchen und anzuzeigen. [[bsdinstall-zfs-rescan-devices]] .Rescan Devices image::bsdinstall-zfs-rescan-devices.png[] Um zu vermeiden, dass versehentlich die falsche Platte gelöscht wird, können Sie das btn:[- Disk-Info]-Menü verwenden. Dieses Menü zeigt verschiedene Informationen, einschließlich der Partitionstabelle, der Modellnummer und der Seriennummer, falls verfügbar. [[bsdinstall-zfs-disk_info]] .Informationen zum Laufwerk image::bsdinstall-zfs-disk_info.png[] Wählen Sie kbd:[N], um den Pool-Namen zu konfigurieren. Geben Sie den gewünschten Namen ein und wählen Sie dann btn:[OK], um den Namen zu speichern, oder btn:[], um zum Hauptmenü zurückzukehren und den Standard zu belassen. [[bsdinstall-zfs-pool-name]] .Pool-Name image::bsdinstall-zfs-pool-name.png[] Wählen Sie kbd:[S], um die Größe des Swap-Speichers festzulegen. Geben Sie die gewünschte Größe ein und wählen Sie dann btn:[OK], um die Einstellung zu speichern, oder btn:[], um zum Hauptmenü zurückzukehren und den Standard zu belassen. [[bsdinstall-zfs-swap-amount]] .Größe des Swap-Speichers image::bsdinstall-zfs-swap-amount.png[] Wenn alle Optionen wie gewünscht konfiguriert sind, wählen Sie oben im Menü die Option btn:[>>> Install]. Das Installationsprogramm bietet dann eine letzte Chance zum Abbrechen, bevor der Inhalt der ausgewählten Laufwerke zerstört wird, um den ZFS-Pool zu erstellen. [[bsdinstall-zfs-warning]] .Letzte Chance! image::bsdinstall-zfs-warning.png[] Wenn die GELI Plattenverschlüsselung aktiviert wurde, fordert das Installationsprogramm zweimal zur Eingabe der Passphrase auf. Anschließend beginnt die Initialisierung der Verschlüsselung. [[bsdinstall-zfs-geli_password]] .Passwort für die Verschlüsselung der Platte image::bsdinstall-zfs-geli_password.png[] [[bsdinstall-zfs-init-encryption]] .Initialisierung der Verschlüsselung image::bsdinstall-zfs-init-encription.png[] Danach wird die Installation normal weitergeführt. Um mit der Installation fortzufahren, lesen Sie <>. [[bsdinstall-part-shell]] === Shell Partitionierung bsdinstall bietet bei fortgeschrittenen Installationen womöglich nicht die benötigte Flexibilität. Erfahrene Benutzer können die Option btn:[Shell] im Menü auswählen, um die Laufwerke manuell zu partitionieren, Dateisysteme zu erstellen, [.filename]#/tmp/bsdinstall_etc/fstab# zu befüllen und Dateisysteme unter [.filename]#/mnt# einzuhängen. Geben Sie anschließend `exit` ein, um zu bsdinstall zurückzukehren und die Installation fortzusetzen. [[bsdinstall-fetching-distribution]] == Abrufen der Distributionen Die Installationsdauer hängt von den gewählten Distributionen, dem Installationsmedium und der Geschwindigkeit des Computers ab. Eine Reihe von Nachrichten werden angezeigt, um den Fortschritt darzustellen. Zunächst formatiert das Installationsprogramm die ausgewählten Platten und initialisiert die Partitionen. Bei `bootonly media` oder `mini memstick` werden als nächstes die benötigten Komponenten heruntergeladen: [[bsdinstall-distfile-fetching]] .Herunterladen der Distributionsdateien image::bsdinstall-distfile-fetching.png[] Als nächstes wird die Integrität der Distributionsdateien überprüft, um sicherzustellen, dass diese während des Ladevorgangs nicht beschädigt oder unsauber vom Installationsmedium gelesen wurden: [[bsdinstall-distfile-verify]] .Überprüfen der Distributionsdateien image::bsdinstall-distfile-verifying.png[] Zum Schluss werden die überprüften Distributionsdateien auf die Festplatte entpackt: [[bsdinstall-distfile-extract]] .Entpacken der Distributionsdateien image::bsdinstall-distfile-extracting.png[] Sobald alle benötigten Distributionsdateien entpackt wurden, wird bsdinstall das erste Menü für die Arbeiten nach der Installation anzeigen. Die zur Verfügung stehenden Konfigurationsoptionen werden im nächsten Abschnitt beschrieben. [[bsdinstall-post]] == Benutzerkonten, Zeitzone, Dienste und Sicherheitsoptionen [[bsdinstall-post-root]] === Setzen des `root`-Passworts Zuerst muss das `root`-Passwort gesetzt werden. Die eingegebenen Zeichen werden dabei nicht auf dem Bildschirm angezeigt. Nachdem das Passwort eingegeben wurde, muss es zur Bestätigung erneut eingetippt werden. Damit werden auch Tippfehler verhindert. [[bsdinstall-post-set-root-passwd]] .Das `root`-Passwort setzen image::bsdinstall-post-root-passwd.png[] [[bsdinstall-timezone]] === Setzen der Zeitzone Die nächsten Menüs werden verwendet, um die korrekte Ortszeit zu ermitteln. Dazu muss die gewünschte geographische Region, das Land und die Zeitzone ausgewählt werden. Das Setzen der Zeitzone erlaubt es dem System automatische Korrekturen vorzunehmen, beispielsweise beim Wechsel von Sommer- auf Winterzeit. Das hier gezeigte Beispiel bezieht sich auf einen Rechner in der Zeitzone des spanischen Festlands. Die Auswahl ist je nach geographischer Lage unterschiedlich. [[bsdinstall-timezone-region]] .Auswahl der geographischen Region image::bsdinstall-timezone-region.png[] [[bsdinstall-timezone-country]] .Das Land auswählen image::bsdinstall-timezone-country.png[] Wählen Sie das zutreffende Land mit den Pfeiltasten und durch anschließendes drücken von kbd:[Enter] aus. [[bsdinstall-timezone-zone]] .Wählen einer Zeitzone image::bsdinstall-timezone-zone.png[] Die passende Zeitzone wird durch die Pfeiltasten und anschließendes drücken von kbd:[Enter] ausgewählt. [[bsdinstall-timezone-confirmation]] .Bestätigen der Zeitzone image::bsdinstall-timezone-confirm.png[] Bestätigen Sie, dass die Abkürzung für die Zeitzone korrekt ist. [[bsdinstall-timezone-date]] .Datum auswählen image::bsdinstall-timezone-date.png[] Das entsprechende Datum wird mit den Pfeiltasten und das anschließende Drücken von btn:[Set Date] gewählt. Andernfalls kann die Auswahl durch Drücken von btn:[Skip] übersprungen werden. [[bsdinstall-timezone-time]] .Uhrzeit auswählen image::bsdinstall-timezone-time.png[] Die entsprechende Uhrzeit wird mit den Pfeiltasten und das anschließende Drücken von btn:[Set Time] gewählt. Andernfalls kann die Auswahl durch Drücken von btn:[Skip] übersprungen werden. [[bsdinstall-sysconf]] === Dienste aktivieren Zusätzliche Systemdienste, die zur Startzeit aktiviert werden sollen, können im folgenden Menü eingeschaltet werden. All diese Dienste sind optional. Starten Sie nur die Dienste, die zur korrekten Funktion des Systems benötigt werden. [[bsdinstall-config-serv]] .Auswahl zusätzlicher Dienste image::bsdinstall-config-services.png[] Die folgenden Dienste können über dieses Menü aktiviert werden: * `local_unbound` - Aktiviert den lokalen unbound DNS-Cache. Bedenken Sie, dass dies der Unbound des Basissystems ist und nur als lokaler Cache-Forwarding-Resolver gedacht ist. Möchten Sie einen DNS-Server für das gesamte Netzwerk einrichten, installieren Sie bitte package:dns/unbound[]. * `sshd` - Der Secure Shell (SSH)-Daemon für Fernzugriff über eine verschlüsselte Verbindung. Aktivieren Sie diesen Dienst nur dann, wenn das System für Fernzugriff zur Verfügung stehen soll. * `moused` - Aktivieren Sie diesen Dienst, wenn Sie Mausunterstützung auf der Systemkonsole benötigen. * `ntpdate` - Aktiviert die automatische Synchronisation der Uhrzeit beim booten. Diese Funktionalität ist ebenfalls im man:ntpd[8]-Daemon verfügbar. In naher Zukunft soll das Programm man:ntpdate[8] entfernt werden. * `ntpd` - Der Network Time Protocol (NTP)-Daemon zur automatischen Uhrzeitsynchronisation. Aktivieren Sie diesen Dienst, wenn es im Netzwerk einen Windows(R)-, Kerberos- oder LDAP-Server gibt. * `powerd` - Systemwerkzeug zur Leistungsregelung und für Stromsparfunktionen. * `dumpdev` - Aktiviert die Absturzaufzeichnung, welche sehr nützlich sein kann, um Systemfehler aufzuspüren. Daher wird Anwendern empfohlen, diese Option zu aktivieren. [[bsdinstall-hardening]] === Aktivieren von Sicherheitsoptionen Im nächsten Menü können Sicherheitsoptionen aktiviert werden. Alle diese Optionen sind optional. Es wird jedoch empfohlen, sie zu aktivieren. [[bsdinstall-hardening-options]] .Auswahl der Sicherheitsoptionen image::bsdinstall-hardening.png[] Folgende Optionen können in diesem Menü aktiviert werden: * `hide_uids` - Versteckt die Prozesse von anderen Benutzern, um zu verhindern, dass unprivilegierte Benutzer laufende Prozesse von anderen Benutzern (UID) sehen können. * `hide_gids` - Versteckt die Prozesse anderer Gruppen, um zu verhindern, dass unprivilegierte Benutzer laufende Prozesse von anderen Gruppen (GID) sehen können. * `hide_jails` - Versteckt Jail-Prozesse, um zu verhindern, dass unprivilegierte Benutzer die in den Jails laufenden Prozesse sehen können. * `read_msgbuf` - Deaktiviert den Lesezugriff auf den Nachrichtenpuffer des Kernels für nicht privilegierte Benutzer. Dadurch wird verhindert, dass man:dmesg[8] zum Anzeigen von Nachrichten aus dem Nachrichtenpuffer des Kernels verwendet wird. * `proc_debug` - Die Deaktivierung von Prozess-Debugging-Funktionen für unprivilegierte Benutzer deaktiviert einige IPC-Dienste und procfs-Funktionen, ptrace() und ktrace(). Beachten Sie, dass dadurch auch die Nutzung von Werkzeugen wie man:lldb[1], man:truss[1], man:procstat[1] und einige Debugging-Funktionen von Skriptsprachen wie PHP, für unprivilegierte Benutzer unterbunden wird. * `random_pid` - Zufällig generierte PID für neu erstellte Prozesse. * `clear_tmp` - Bereinigt das Verzeichnis [.filename]#/tmp# beim Systemstart. * `disable_syslogd` - Diese Option verhindert, dass syslogd einen Netzwerk-Socket öffnet. In der Voreinstellung startet FreeBSD syslogd auf sichere Weise mit `-s`. Das verhindert, dass der Daemon auf Port 514 auf UDP-Anfragen lauscht. Wenn diese Option aktiviert ist, läuft syslogd mit dem Schalter `-ss`, dass syslogd daran hindert, einen Port zu öffnen. Weitere Informationen finden Sie in man:syslogd[8]. * `disable_sendmail` - Deaktiviert den sendmail MTA. * `secure_console` - Wenn diese Option aktiviert ist, fragt das System im Single-User-Modus nach dem `root"`-Passwort. * `disable_ddtrace` - DTrace kann in einem Modus laufen, der sich tatsächlich auf den laufenden Kernel auswirkt. Destruktive Aktionen dürfen nicht benutzt werden, es sei denn, sie wurden explizit aktiviert. Um diese Option bei der Verwendung von DTrace zu aktivieren, benutzen Sie `-w`. Weitere Informationen finden Sie in man:dtrace[1]. [[bsdinstall-addusers]] === Benutzer hinzufügen Das nächste Menü fordert Sie dazu auf, mindestens ein Benutzerkonto zu erstellen. Es wird empfohlen, sich als normaler Benutzer am System anzumelden und nicht als `root`-Benutzer. Wenn man als `root` angemeldet ist, gibt es so gut wie keine Beschränkungen oder Schutz vor dem, was man tun kann. Die Anmeldung als normaler Benutzer ist daher sicherer und bietet mehr Schutz. Wählen Sie btn:[Yes], um neue Benutzer hinzuzufügen. [[bsdinstall-add-user1]] .Benutzerkonten hinzufügen image::bsdinstall-adduser1.png[] Folgen Sie den Anweisungen und geben Sie die angeforderten Informationen für das Benutzerkonto ein. Das Beispiel in <> erstellt ein Konto für den Benutzer `asample`. [[bsdinstall-add-user2]] .Benutzerinformationen eingeben image::bsdinstall-adduser2.png[] Die folgenden Informationen müssen eingegeben werden: * `Username` - Der Name des Benutzers, den man zur Anmeldung eingeben muss. Es ist üblich, den ersten Buchstaben des Vornamens zusammen mit dem Nachnamen zu kombinieren. Jeder Benutzername ist möglich, solange er für das System einzigartig ist. Es wird zwischen Groß- und Kleinschreibung unterschieden und der Benutzername sollte keine Leerzeichen enthalten. * `Full name` - Der volle Name des Benutzers. Dieser darf auch Leerzeichen enthalten und dient als Beschreibung für das Benutzerkonto. * `Uid` - User ID. Normalerweise wird dieses Feld leer gelassen, so dass das System einen Wert vergibt. * `Login group` - Die Benutzergruppe. Normalerweise bleibt dieses Feld leer, um die Standardgruppe zu akzeptieren. * `Invite _user_ into other groups?` - Zusätzliche Gruppen zu denen der Benutzer als Mitglied hinzugefügt werden soll. Falls der Benutzer administrativen Zugriff benötigt, tragen Sie hier `wheel` ein. * `Login class` - In der Regel bleibt dieses Feld leer. * `Shell` - Die interaktive Shell für diesen Benutzer. Tragen Sie hier eine der aufgeführten Shells ein. Weitere Informationen über Shells finden Sie im crossref:basics[shells,“Shells”]. * `Home directory` - Das Heimatverzeichnis des Benutzers. Die Vorgabe ist für gewöhnlich richtig. * `Home directory permissions` - Zugriffsrechte auf das Heimatverzeichnis des Benutzers. Die Vorgabe ist normalerweise die passende. * `Use password-based authentication?` - Normalerweise `yes`, damit der Benutzer bei der Anmeldung sein Passwort eingeben muss. * `Use an empty password?` - Normalerweise `no`, da ein leeres Passwort unsicher ist. * `Use a random password?` - Normalerweise `no`, damit der Benutzer sein Passwort am nächsten Prompt selber vergeben kann. * `Enter password` - Das Passwort für diesen Benutzer. Eingegebene Zeichen werden nicht am Bildschirm angezeigt. * `Enter password again` - Das Passwort muss zur Überprüfung erneut eingegeben werden. * `Lock out the account after creation?` - Normalerweise `no`, damit sich der Benutzer anmelden kann. Nachdem alles eingegeben wurde, wird eine Zusammenfassung angezeigt und das System fragt Sie, dies so korrekt ist. Falls ein Eingabefehler gemacht wurde, geben Sie `no` ein und versuchen es erneut. Falls alles in Ordnung ist, geben Sie `yes` ein, um den neuen Benutzer anzulegen. [[bsdinstall-add-user3]] .Verlassen der Benutzer- und Gruppenverwaltung image::bsdinstall-adduser3.png[] Falls es mehr Benutzer hinzuzufügen gibt, beantworten Sie die Frage `Add another user?` mit `yes`. Geben Sie `no` ein, wird das hinzufügen von Benutzern beendet und die Installation fortgesetzt. Für weitere Informationen zum hinzufügen von Benutzern und deren Verwaltung, lesen Sie crossref:basics[users-synopsis,“Benutzer und grundlegende Account-Verwaltung”]. [[bsdinstall-final-conf]] === Letzte Konfigurationsschritte Nachdem alles installiert und konfiguriert wurde, bekommen Sie noch eine letzte Chance, um Einstellungen zu verändern. [[bsdinstall-final-config]] .Letzte Schritte der Konfiguration image::bsdinstall-finalconfiguration.png[] Verwenden Sie dieses Menü, um noch letzte Änderungen oder zusätzliche Konfigurationen vor dem Abschließen der Installation zu tätigen. * `Add User` - Beschrieben in <>. * `Root Password` - Beschrieben in <>. * `Hostname` - Beschrieben in <>. * `Network` - Beschrieben in <>. * `Services` - Beschrieben in <>. * `Time Zone` - Beschrieben in <>. * `Handbook` - Herunterladen und installieren des FreeBSD Handbuchs. Nachdem die letzten Konfigurationsschritte beendet sind, wählen Sie btn:[Exit]. [[bsdinstall-final-modification-shell]] .Manuelle Konfiguration image::bsdinstall-final-modification-shell.png[] bsdinstall wird nach zusätzlichen Konfigurationen, die noch zu tätigen sind, fragen, bevor in das neue System gebootet wird. Wählen Sie btn:[Yes], um in eine Shell innerhalb des neuen Systems zu wechseln oder btn:[No], um mit dem letzten Schritt der Installation zu beginnen. [[bsdinstall-final-main]] .Die Installation vervollständigen image::bsdinstall-mainexit.png[] Wenn weitere Konfigurationen oder besondere Einstellungen benötigt werden, wählen Sie btn:[Live CD], um das Installationsmedium im Live-CD Modus zu starten. Wenn die Installation vollständig ist, wählen Sie btn:[Reboot], um den Computer neu zu starten und das neu installierte FreeBSD-System zu booten. Vergessen Sie nicht, das FreeBSD Installationsmedium zu entfernen, oder der Computer wird erneut davon starten. Wenn FreeBSD startet, werden viele Informationsmeldungen ausgegeben. Nachdem das System den Startvorgang abgeschlossen hat, wird eine Anmeldeaufforderung angezeigt. Geben Sie am `login:` den Benutzernamen ein, den Sie während der Installation hinzugefügt haben. Vermeiden Sie es, sich als `root` anzumelden. Lesen Sie crossref:basics[users-superuser,“Der Superuser-Account”], wenn Sie administrativen Zugriff benötigen. Um Nachrichten, die während des Bootens angezeigt wurden, zu sehen, aktivieren Sie durch drücken von kbd:[Scroll-Lock] den _scroll-back buffer_. Die Tasten kbd:[PgUp], kbd:[PgDn] und die Pfeiltasten dienen zur Navigation durch die Nachrichten. Durch erneutes drücken von kbd:[Scroll-Lock] wird der Bildschirm wieder entsperrt und kehrt zur normalen Anzeige zurück. Mit `less /var/run/dmesg.boot` können Sie sich diese Nachrichten im laufenden Betrieb ansehen. Durch drücken von kbd:[q] kehren Sie wieder zur Kommandozeile zurück. Wenn sshd in <> aktiviert wurde, ist der erste Start ein bisschen langsamer, weil das System die RSA- und DSA-Schlüssel erzeugen muss. Die nachfolgenden Startvorgänge werden dann wieder schneller sein. Wie in diesem Beispiel zu sehen ist, werden die Fingerabdrücke der Schlüssel am Bildschirm ausgegeben: [source,shell] .... Generating public/private rsa1 key pair. Your identification has been saved in /etc/ssh/ssh_host_key. Your public key has been saved in /etc/ssh/ssh_host_key.pub. The key fingerprint is: 10:a0:f5:af:93:ae:a3:1a:b2:bb:3c:35:d9:5a:b3:f3 root@machine3.example.com The key's randomart image is: +--[RSA1 1024]----+ | o.. | | o . . | | . o | | o | | o S | | + + o | |o . + * | |o+ ..+ . | |==o..o+E | +-----------------+ Generating public/private dsa key pair. Your identification has been saved in /etc/ssh/ssh_host_dsa_key. Your public key has been saved in /etc/ssh/ssh_host_dsa_key.pub. The key fingerprint is: 7e:1c:ce:dc:8a:3a:18:13:5b:34:b5:cf:d9:d1:47:b2 root@machine3.example.com The key's randomart image is: +--[ DSA 1024]----+ | .. . .| | o . . + | | . .. . E .| | . . o o . . | | + S = . | | + . = o | | + . * . | | . . o . | | .o. . | +-----------------+ Starting sshd. .... Lesen Sie crossref:security[openssh,"OpenSSH"] für weitere Informationen zu Fingerabdrücken und SSH. FreeBSD installiert standardmäßig keine graphische Umgebung. crossref:x11[x11,Das X-Window-System] enthält Informationen zur Installation und Konfiguration eines graphischen Window Managers. Das korrekte herunterfahren eines FreeBSD-Computers hilft, beugt dem Datenverlust vor und schützt sogar die Hardware vor Schäden. _Schalten Sie nicht den Strom ab, bevor das System ordnungsgemäß heruntergefahren wurde!_ Wenn der Benutzer ein Mitglied der `wheel`-Gruppe ist, können Sie zum Superuser durch die Eingabe von `su` und der anschließenden Eingabe des Passworts von `root` werden. Geben Sie dann `shutdown -p now` ein. Das System wird jetzt sauber heruntergefahren und, falls die Hardware es unterstützt, den Rechner ausschalten. [[bsdinstall-network]] == Netzwerkschnittstellen [[bsdinstall-config-network-dev]] === Die Netzwerkschnittstelle konfigurieren Als nächstes wird eine Liste der gefundenen Netzwerkschnittstellen gezeigt. Wählen Sie die Schnittstelle aus, die Sie konfigurieren möchten. [[bsdinstall-configure-net-interface]] .Eine zu konfigurierende Netzwerkschnittstelle auswählen image::bsdinstall-configure-network-interface.png[] Wenn Sie eine Ethernet-Schnittstelle ausgewählt haben, fährt das Installationsprogramm mit dem Menü aus <> fort. Wenn Sie eine drahtlose Netzwerkschnittstelle ausgewählt haben, wird das System nach drahtlosen Zugriffspunkten (Access Points) suchen: [[bsdinstall-wireless-scan]] .Nach drahtlosen Access Points scannen image::bsdinstall-configure-wireless-scan.png[] Drahtlose Netzwerke werden durch einen Service Set Identifier (SSID) identifiziert. Der SSID ist ein kurzer, eindeutiger Name, der für jedes Netzwerk vergeben wird. SSIDs, die während des Scans gefunden wurden, werden aufgelistet, gefolgt von einer Beschreibung der Verschlüsselungsarten, die für dieses Netzwerk verfügbar sind. Falls die gewünschte SSID nicht in der Liste auftaucht, wählen Sie btn:[Rescan], um erneut einen Scanvorgang durchzuführen. Falls dann das gewünschte Netzwerk immer noch nicht erscheint, überprüfen Sie die Antenne auf Verbindungsprobleme oder versuchen Sie, näher an den Access point zu gelangen. Scannen Sie erneut nach jeder vorgenommenen Änderung. [[bsdinstall-wireless-accesspoints]] .Ein drahtloses Netzwerk auswählen image::bsdinstall-configure-wireless-accesspoints.png[] Geben Sie nun die Verschlüsselungsinformationen ein, um sich mit dem drahtlosen Netzwerk zu verbinden. WPA2 wird als Verschlüsselung dringend empfohlen, da ältere Verschlüsselungsmethoden, wie WEP, nur wenig Sicherheit bieten. Wenn das Netzwerk WPA2 verwendet, geben Sie das Passwort (auch bekannt als Pre-Shared Key PSK) ein. Aus Sicherheitsgründen werden die in das Eingabefeld eingegeben Zeichen nur als Sternchen angezeigt. [[bsdinstall-wireless-wpa2]] .Verbindungsaufbau mit WPA2 image::bsdinstall-configure-wireless-wpa2setup.png[] Wählen Sie, ob eine IPv4-Adresse auf der Ethernet-Schnittstelle oder der drahtlosen Schnittstelle konfiguriert werden soll. [[bsdinstall-configure-net-ipv4]] .Auswahl von IPv4 image::bsdinstall-configure-network-interface-ipv4.png[] Es gibt zwei Arten, ein IPv4-Netzwerk zu konfigurieren. DHCP wird automatisch die Netzwerkschnittstelle richtig konfigurieren und sollte verwendet werden, wenn das Netzwerk über einen DHCP-Server verfügt. Eine _statische_ IP-Konfiguration erfordert die manuelle Eingabe von Netzwerkinformationen. [NOTE] ==== Geben Sie keine zufällig gewählten Netzwerkinformationen ein, da dies nicht funktionieren wird. Holen Sie sich die in <> gezeigten Informationen vom Netzwerkadministrator oder Serviceprovider, falls kein DHCP-Server verfügbar ist. ==== Falls ein DHCP-Server zur Verfügung steht, wählen Sie im nächsten Menü btn:[Yes], um die Netzwerkschnittstelle automatisch einrichten zu lassen. Dieser Vorgang kann einige Sekunden dauern. [[bsdinstall-net-ipv4-dhcp]] .Auswählen der IPv4-Konfiguration über DHCP image::bsdinstall-configure-network-interface-ipv4-dhcp.png[] Wenn kein DHCP-Server zur Verfügung steht, wählen Sie btn:[No] und tragen Sie die folgenden Informationen in das Menü ein: [[bsdinstall-net-ipv4-static]] .Statische IPv4-Konfiguration image::bsdinstall-configure-network-interface-ipv4-static.png[] * `IP Address` - Die IPv4-Adresse, welche diesem Computer zugewiesen werden soll. Diese Adresse muss eindeutig sein und darf nicht bereits von einem anderen Gerät im lokalen Netzwerk verwendet werden. * `Subnet Mask` - Die Subnetzmaske des Netzwerks. * `Default Router` - Die IP-Adresse des Defaultrouters im Netzwerk. Das nächste Menü fragt, ob die Schnittstelle für IPv6 konfiguriert werden soll. Falls IPv6 verfügbar ist und verwendet werden soll, wählen Sie btn:[Yes] aus. [[bsdinstall-net-ipv6]] .Auswahl von IPv6 image::bsdinstall-configure-network-interface-ipv6.png[] IPv6 besitzt ebenfalls zwei Arten der Konfiguration. _StateLess Address AutoConfiguration_, (SLAAC) wird automatisch die richtigen Informationen von einem lokalen Router abfragen. Lesen Sie http://tools.ietf.org/html/rfc4862[http://tools.ietf.org/html/rfc4862] für weitere Informationen. Eine _statische_ Konfiguration verlangt die manuelle Eingabe von Netzwerkinformationen. Wenn ein IPv6-Router verfügbar ist, wählen Sie im nächsten Menü btn:[Yes], um die Netzwerkschnittstelle automatisch konfigurieren zu lassen. [[bsdinstall-net-ipv6-slaac]] .Auswahl der IPv6SLAAC-Konfiguration image::bsdinstall-configure-network-interface-slaac.png[] Wenn kein IPv6-Router zur Verfügung steht, wählen Sie btn:[No] und tragen Sie die folgenden Adressinformationen in dieses Menü ein: [[bsdinstall-net-ipv6-static]] .Statische IPv6-Konfiguration image::bsdinstall-configure-network-interface-ipv6-static.png[] * `IPv6 Address` - Die zugewiesene IPv6-Adresse, welche dem Computer zugeteilt werden soll. Diese Adresse muss eindeutig sein und nicht bereits von einer anderen Netzwerkkomponente im lokalen Netzwerk verwendet werden. * `Default Router` - Die IPv6-Adresse des Defaultrouters im Netzwerk. Das letzte Menü der Netzwerkkonfiguration konfiguriert den _Domain Name System_ (DNS) Resolver, welcher Hostnamen von und zu Netzwerkadressen umwandelt. Falls DHCP oder SLAAC verwendet wurde, um die Netzwerkschnittstelle zu konfigurieren, ist die Konfiguration für den Resolver möglicherweise bereits eingetragen. Andernfalls geben Sie den lokalen Netzwerkdomänennamen in das Feld `Search` ein. `DNS #1` und `DNS #2` sind die IPv4- und/oder IPv6-Adressen der lokalen DNS-Server. Zumindest ein DNS-Server wird benötigt. [[bsdinstall-net-dns-config]] .DNS-Konfiguration image::bsdinstall-configure-network-ipv4-dns.png[] Sobald die Schnittstelle konfiguriert ist, bestimmen Sie einen Spiegelserver, welcher in der gleichen Region auf der Welt beheimatet ist, wie der Computer, auf dem FreeBSD installiert wird. Dateien können so viel schneller übertragen werden, wenn der Spiegelserver sich näher am Zielcomputer befindet und die Installationszeit wird somit reduziert. [[bsdinstall-netinstall-mirror]] .Einen Spiegelserver wählen image::bsdinstall-netinstall-mirrorselect.png[] [[bsdinstall-install-trouble]] == Fehlerbehebung Dieser Abschnitt behandelt einfache Fehlerbehebungen für die Installation, wie beispielsweise häufig auftretende Fehler, die von Anwendern berichtet wurden. Überprüfen Sie die Hardware Notes (link:https://www.FreeBSD.org/releases/[https://www.freebsd.org/releases/]) nach der Version von FreeBSD, um sicher zu stellen, dass die Hardware auch unterstützt wird. Wenn die Hardware unterstützt wird und Sie immer noch Abstürze oder andere Probleme erleben, müssen Sie einen eigenen Kernel bauen. Diese Prozedur wird in crossref:kernelconfig[kernelconfig,Konfiguration des FreeBSD-Kernels ] beschrieben. Das erlaubt es, Unterstützung für Geräte, die im [.filename]#GENERIC#-Kernel nicht vorhanden sind, hinzuzufügen. Der Kernel ist mit der Annahme konfiguriert, dass die Hardwaregeräte sich in ihren Fabrikeinstellungen in Bezug auf IRQs, I/O-Adressen und DMA-Kanälen befinden. Wenn die Hardware neu konfiguriert wurde, werden Sie möglicherweise die Konfiguration des Kernels bearbeiten und diesen neu erstellen müssen, um FreeBSD mitzuteilen, wo es gewisse Dinge finden kann. [NOTE] ==== Manche Installationsprobleme können Aktualisierung der Firmware auf verschiedenen Hardwarekomponenten verhindert oder verringert werden, meistens am Mainboard. Mit Mainboard-Firmware ist für gewöhnlich das BIOS gemeint. Die meisten Mainboard- und Computerhersteller haben eine Webseite mit Aktualisierungen und Informationen zur Durchführung. Hersteller raten meist von einer Aktualisierung des Mainboard-BIOS ab, außer es gibt einen guten Grund dafür, wie beispielsweise eine kritische Aktualisierung. Der Aktualisierungsvorgang _kann_ schiefgehen, was das BIOS unvollständig macht und den Computer nicht mehr starten lässt. ==== Wenn das System während der Geräteerkennung beim Starten hängt oder sich während der Installation merkwürdig verhält, ist ACPI vielleicht der Übeltäter. FreeBSD macht auf i386- und amd64-Plattformen starken Gebrauch vom ACPI-Dienst, um dem System bei der Konfiguration während des Startvorgangs zu helfen. Leider existieren immer noch Fehler im ACPI-Treiber, in den Mainboards und der BIOS-Firmware. ACPI kann durch setzen der Einstellung `hint.acpi.0.disabled` im dritten Teil des Bootloaders deaktiviert werden: [source,shell] .... set hint.acpi.0.disabled="1" .... Dies wird nach jedem Neustart des Systems wieder zurückgesetzt, also ist es notwendig, die Zeile `hint.acpi.0.disabled="1"` zu der Datei [.filename]#/boot/loader.conf# hinzuzufügen. Weitere Informationen über den Bootloader lassen sich in crossref:boot[boot-synopsis,“Übersicht”] nachlesen. [[using-live-cd]] == Verwendung der Live-CD Das Willkommensmenü von bsdinstall, welches in <> gezeigt wird, enthält eine btn:[Live CD] Option. Die Live-CD ist für Benutzer, die sich fragen, ob FreeBSD das richtige Betriebssystem für sie ist und die vor der Installation noch einige Merkmale und Eigenschaften testen wollen. Die folgenden Punkte sollten beachtet werden, bevor die btn:[Live CD] benutzt wird: * Um Zugriff auf das System zu bekommen, wird eine Authentifizierung benötigt. Der Benutzername ist `root` und das Kennwort bleibt leer. * Da das System direkt von dem Installationsmedium ausgeführt wird, ist die Geschwindigkeit deutlich langsamer als bei einem System, das auf einer Festplatte installiert ist. * Diese Option enthält nur eine Eingabeaufforderung und keine graphische Oberfläche. diff --git a/documentation/content/fr/books/faq/_index.adoc b/documentation/content/fr/books/faq/_index.adoc index ef5f264e1f..d2f96b899d 100644 --- a/documentation/content/fr/books/faq/_index.adoc +++ b/documentation/content/fr/books/faq/_index.adoc @@ -1,3542 +1,3542 @@ --- title: Questions Fréquemment Posées sur FreeBSD 2.X, 3.X et 4.X authors: - author: The FreeBSD Documentation Project copyright: 1995-2020 The FreeBSD Documentation Project releaseinfo: "$FreeBSD$" trademarks: ["freebsd", "ibm", "ieee", "adobe", "intel", "linux", "microsoft", "opengroup", "sun", "netbsd", "general"] --- = Questions Fréquemment Posées sur FreeBSD 2.X, 3.X et 4.X :doctype: book :toc: macro :toclevels: 1 :icons: font :xrefstyle: basic :relfileprefix: ../ :outfilesuffix: :sectnums: :sectnumlevels: 6 :partnums: :source-highlighter: rouge :experimental: :skip-front-matter: :toc-title: Table des matières :part-signifier: Partie :chapter-signifier: Chapitre :appendix-caption: Annexe :table-caption: Tableau :example-caption: Exemple :rel-numbranch: 3 :rel-head: 13-CURRENT :rel-head-relx: 13.X :rel-head-releng: head/ :rel-relx: 12.X :rel-stable: 12-STABLE :rel-releng: stable/12/ :rel-relengdate: December 2018 :rel2-relx: 11.X :rel2-stable: 11-STABLE :rel2-releng: stable/11/ :rel2-relengdate: October 2016 ifeval::["{backend}" == "html5"] include::shared/mirrors.adoc[] include::shared/authors.adoc[] include::shared/releases.adoc[] include::shared/fr/mailing-lists.adoc[] include::shared/fr/teams.adoc[] include::shared/fr/urls.adoc[] endif::[] ifeval::["{backend}" == "pdf"] include::../../../../shared/mirrors.adoc[] include::../../../../shared/authors.adoc[] include::../../../../shared/releases.adoc[] include::../../../../shared/fr/mailing-lists.adoc[] include::../../../../shared/fr/teams.adoc[] include::../../../../shared/fr/urls.adoc[] endif::[] ifeval::["{backend}" == "epub3"] include::../../../../shared/mirrors.adoc[] include::../../../../shared/authors.adoc[] include::../../../../shared/releases.adoc[] include::../../../../shared/fr/mailing-lists.adoc[] include::../../../../shared/fr/teams.adoc[] include::../../../../shared/fr/urls.adoc[] endif::[] [.abstract-title] Résumé Ceci est la FAQ pour les versions de FreeBSD 2.X, 3.X et 4.X. Toutes les entrées sont relatives à FreeBSD 2.05 et les versions ultérieures. La dernière version de ce document est disponible en anglais à l'adresse suivante : http://www.fr.FreeBSD.ORG/[FreeBSD World Wide Web server]. Ce document est également disponible en un seul fichier link:.[HTML] sur le serveur HTTP du projet, ou en texte, PostScript, PDF, etc. sur le serveur link:ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/[FTP de FreeBSD]. Vous pouvez aussi, link:https://www.FreeBSD.org/search/[chercher dans cette FAQ]. ''' toc::[] == Préface. **Mise à jour en cours** === Quel est le but de cette FAQ ? Comme toutes les FAQ Usenet, ce document contient les questions les plus fréquemment posées à propos du système d'exploitation FreeBSD, ainsi que leurs réponses. Bien que destinées, à l'origine, à réduire le trafic et éviter que les mêmes questions soient posées encore et encore, les FAQ sont maintenant reconnues comme de précieuses sources d'information. Tous les efforts ont été apportés pour rendre cette FAQ la plus complète possible. Si vous avez des commentaires la concernant ou si vous voulez y contribuer, envoyez un e-mail au link:mailto:freebsd-france@freebsd.francenet.fr[responsable de cette FAQ]. === FreeBSD c'est quoi ? Pour résumer, FreeBSD 2.X est un système d'exploitation UN*X basé sur la distribution 4.4BSD-lite de l'université de Berkeley pour des plate-formes i386. Il est aussi basé indirectement sur le portage de William Jolitz de la distribution Net/2 de l'université de Berkeley, plus connu sous le nom de 386BSD, mais très peu de code de 386BSD subsiste. Une description plus complète de ce qu'est FreeBSD et à quoi il peut vous servir, peut être trouvée à http://www.fr.freebsd.org[la page d'accueil de FreeBSD]. FreeBSD est utilisé par des sociétés commerciales, fournisseurs d'accès à l'Internet, chercheurs, professionnels de l'informatique, étudiants et particuliers à travers le monde entier pour travailler, apprendre et se divertir. Reportez-vous à la http://www.fr.freebsd.org/gallery/gallery.html[galerie FreeBSD] pour vous faire une idée. Pour plus de détails et d'informations sur FreeBSD, référez vous au link:{handbook}/[manuel de FreeBSD] === Quels sont les buts de FreeBSD ? L'objectif du projet FreeBSD est de fournir un logiciel qui puisse être utilisé à n'importe quelle fin et sans aucun restriction. Nombre d'entre nous sont impliqués de façon significative dans le code (et dans le projet) et ne refuseraient certainement pas une petite compensation financière de temps à autre, mais ce n'est certainement pas dans nos intentions d'insister là dessus. Nous croyons que notre première et principale "mission" est de fournir du code à tout le monde, pour n'importe quel projet, de façon à ce que l'il soit utilisé le plus possible et avec le maximum d'avantages. C'est, nous le pensons, l'un des objectifs les plus fondamentaux du Logiciel Libre et l'un de ceux que nous soutenons avec enthousiasme. Le code de l'arborescence des sources, qui est régi par la Licence Publique GNU ("GNU Public License" - GPL) ou la Licence Publique GNU pour les Bibliothèques ("GNU Library Public License" - GLPL) impose légèrement plus de contraintes, bien que plutôt liées à une disponibilité plus grande qu'au contraire, comme c'est généralement le cas. En raison des complications supplémentaires qui peuvent résulter de l'utilisation commerciale de logiciels GPL, nous essayons, cependant de remplacer ces derniers par des logiciels soumis à la licence BSD qui est plus souple, chaque fois que c'est possible. === Pourquoi le nom FreeBSD ? * Il peut être utilisé gratuitement, même pour un usage commercial. * L'intégralité des sources est disponible gratuitement, et le moins de restrictions possible ont été placées sur son utilisation, sa distribution et son incorporation dans d'autres travaux (à des fins commerciales ou non). * N'importe quelle personne qui a une nouvelle fonctionnalité et/ou une correction de bogue peut soumettre une portion de code, qui pourra être inclus dans l'arbre de développement (moyennant une ou deux conditions évidentes). Pour ceux de nos lecteurs dont la langue maternelle n'est pas l'anglais, il est important de rappeler que le mot "free" est utilisé ici de deux manières, l'une signifiant "gratuitement" et l'autre "vous pouvez faire ce que vous voulez". Excepté une ou deux choses que vous _ne pouvez_ pas faire avec le code FreeBSD, par exemple prétendre que vous l'avez développé, vous pouvez réellement faire ce que vous en voulez. === Quelle est la dernière version de FreeBSD ? La link:ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/3.1-RELEASE[ version 3.1] est la dernière version _stable_ ; elle a été mise en circulation en février 1999. C'est aussi la dernière version _RELEASE_. En quelques mots, la branche _-stable_ est destinée aux fournisseurs d'accès à l'Internet et autres utilisateurs professionnels qui recherchent un système stable ainsi que des changements mineurs lors de la mise à jour de leur système en dernière version. === Qu'est-ce que FreeBSD-current ? link:{handbook}#current[FreeBSD-current] est la version de développement du système d'exploitation, qui deviendra en temps utile la version 4.0-RELEASE. Comme telle, cette version ne peut intéresser que les développeurs du noyau ainsi que certains passionnés. Voyez link:{handbook}#current[la section appropriée] du link:{handbook}[manuel] pour plus de détails sur l'utilisation de -current. Si vous n'êtes pas familier avec ce système d'exploitation, ou que vous n'êtes pas capable de différencier un problème temporaire d'un problème critique, vous ne devez pas utiliser FreeBSD-current. Cette branche évolue assez rapidement et peut ne pas être compilée pendant un certain temps. Les personnes utilisant FreeBSD-current doivent être capables d'analyser n'importe quel problème et de ne rapporter que les erreurs utiles. Assez souvent, une http://www.fr.freebsd.org/releases/snapshots/[version de test] est créée depuis la branche de développement -current et occasionnellement une distribution sur CDROM est disponible. Les buts de chaque version de test sont les suivants: * Tester la dernière version du programme d'installation. * Donner aux personnes voulant utiliser -current mais n'ayant pas le temps ou la bande passante pour suivre jour après jour les évolutions du système, une façon simple de faire évoluer leur système. * Garder un point de synchronisation pour les sources du système actuel, juste au cas ou nous casserions quelque chose plus tard d'une façon irrécupérable (Bien sur, CVS nous empêche normalement d'en arriver là :-). * Vérifier que toutes les nouvelles fonctionnalités nécessitant des tests ont le nombre maximum de testeurs potentiels. Aucune garantie ne peut être donnée sur le fait que les versions de test puissent être considérées comme des versions "de production". Pour des systèmes en production, vous devez attendre la version finale. Les versions de test sont directement téléchargeables depuis link:ftp://current.freebsd.or/pub/FreeBSD[ ce site] et sont générées en moyenne une fois par jour pour les branches 4.0-current et 3.0-stable. === Quel est le concept de la branche FreeBSD-stable ? Revenons un peu en arrière, lorsque la version 2.0.5 de FreeBSD fut livrée, nous avons décidé de scinder le développement en deux branches. Une nommée http://www.freebsd-fr.org/handbook/stable.html[-stable], où nous avons décidé de n'inclure que les correctifs testés et contenant quelques ajouts de fonctionnalités (pour les fournisseurs d'accès ou les sociétés à vocation commerciale où les fonctionnalités expérimentales sont plus qu'indésirables). L'autre nommée http://www.freebsd-fr.org/handbook/current.html[-current] qui nous emmènera jusqu'à la version 4.0-RELEASE (et audelà) depuis la livraison 2.0. Un dessin ASCII qui vous montre à quoi ressemble l'arbre de développement : [.programlisting] .... 2.0 | | | [2.1-stable] *Nouvelle BRANCHE* 2.0.5 -> 2.1 -> 2.1.5 -> 2.1.6 -> 2.1.7.1 [fin de la branche 2.1-stable] | (Mars 1997) | | | [2.2-stable] *Nouvelle BRANCHE* 2.2.1 -> 2.2.2-RELEASE -> 2.2.5 -> 2.2.6 -> 2.2.7 -> 2.2.8 [fin] |(Mars 1997) (Octobre 97) (Avril 98) (Juillet 98) (Décembre 1998) | | 3.0-SNAPs (Debut 1er trimestre 1997) | | 3.0.0-RELEASE (Octobre 1998) | | [3.0-stable] *Nouvelle BRANCHE* 3.1 (Feb 1999) -> ... future 3.x releases ... | | \|/ + [4.0-current continues] .... .L'arbre de développement La branche -current progresse lentement vers la version 4.0 et au-delà, la branche 2.2-stable étant terminée avec la version 2.2.8. La branche 3.0-stable l'a maintenant remplacée, la prochaine version arrivant avec la 3.1 au début 1999 . La version 4.0-current est maintenant la "branche courante" avec les premières versions 4.0 apparaissant au premier trimestre 2000. === Quand sont livrées les versions de FreeBSD ? Les nouvelles versions de FreeBSD sont livrées quand l'équipe principale de FreeBSD décide qu'il y a suffisamment de nouveautés et/ou de correctifs pour justifier d'une version, et lorsqu'ils sont satisfaits des modifications apportées et qu'elles ne compromettent pas la stabilité de la version. Beaucoup d'utilisateurs pensent que cela fait partie des meilleures choses de FreeBSD, même si cela peut être un peu frustrant d'attendre que les derniers ajouts soient disponibles. Les versions sont livrées à peu près tous les 4 mois en moyenne. Pour les personnes qui ont besoin (ou veulent) d'un peu plus de risques, il y a les versions SNAP qui sont livrées un peu plus souvent (à peu près tous les mois). === Sur quelles plate-formes, autre que les PC, est disponible FreeBSD ? Actuellement FreeBSD 3.x tourne sur une plate-forme link:https://www.FreeBSD.org/fr/alpha/[DEC Alpha ] aussi bien que sur les architecture x86. Un intérêt a été exprimé pour un portage sur http://www.freebsd.org/~jseger/freebsd-sparc/[UltraSPARC] mais les détails de ce projet ne sont pas encore clairs. Si vous disposez d'une autre architecture, nous vous conseillons d'aller voir aux URLs suivantes: * http://www.netbsd.org[NetBSD] * http://www.openbsd.org[OpenBSD] === Qui sont les responsables de FreeBSD ? Les décisions concernant le projet FreeBSD, comme les directions que vont prendre le projet ainsi que les personnes autorisées à ajouter du code dans le noyau, sont fixées par link:{handbook}#staff/[l'équipe principale ], composée d'environ 15 personnes. Il y a une équipe un peu plus large d'environ link:{handbook}#staff-committers/[150 personnes] qui ont le droit d'effectuer des changements dans le code. Bien sûr, la plupart des changements sont discutés au préalable dans les listes de messagerie, et il n'y a aucune restriction sur qui peut prendre part à la discussion. === Où peut-on trouver FreeBSD ? Toutes les versions sont disponibles via un ftp anonyme sur le link:ftp://ftp.FreeBSD.ORG/pub/FreeBSD/[site ftp de FreeBSD] * Pour la version 2.2-stable, 2.2.8R, voir le répertoire link:ftp://ftp.FreeBSD.ORG/pub/FreeBSD/release/2.2.8-RELEASE/[ 2.2.8-RELEASE]. * Pour la version 3.0-stable, 3.0-RELEASE, voir le répertoire link:ftp://current.freebsd.org/pub/FreeBSD/release/3.0-RELEASE[3.0-RELEASE]. * Les versions link:ftp://releng22.freebsd.org/pub/FreeBSD/[de tests 2.2 ] sont compilées une fois par jour tout au long de la vie de la branche RELENG_2_2 (post 2.2.8). Sauf gros incident, la branche RELENG_2_2 est maintenue avec extrêmement d'attention (pas de changements expérimentaux, correctifs ajoutés après test dans la branche -current uniquement). * Les versions link:ftp://releng30.freebsd.org/pub/FreeBSD/[ de test 3.0] sont compilées une fois par jour depuis la branche RELENG_3 (post 3.0-release)jusqu'à la 3.1-RELEASE. * Les versions link:ftp://current.freebsd.org/pub/FreeBSD/[ de test 4.0] sont compilées une fois par jour depuis la branche -current, ce service étant juste là pour les personnes voulant la tester, ou les développeurs. FreeBSD est aussi disponible par CDROM chez : En France [.programlisting] .... Le Monde en Tique 6 rue du Maître Albert 75005 PARIS FRANCE Téléphone :01 55 42 73 73 Télécopie :01 55 42 73 74 WWW:Serveur WWW du Monde en Tique Ouverture : Du lundi au samedi, de 9h30 à 19h30 sans interruption Métro : Ligne 10 : Station Maubert - Mutualité Rer B : Cluny - La Sorbonne, Sortie : Boulevard Saint-Michel - Boulevard Saint-Germain Rer C : Saint Michel - Notre Dame, Sortie : Notre-Dame .... [.programlisting] .... Infothèque 32, rue de Moscou 75008 Paris Téléphone:01 45 22 67 01 Télécopie:01 42 93 73 83 WWW: Serveur WWW de infotheque .... Aux USA [.programlisting] .... Walnut Creek CDROM 4041 Pike Lane, Suite F Concord, CA 94520 USA Commandes: +1 800 786-9907 Questions: +1 925 674-0783 FAX: +1 925 674-0821 email: Commandes Walnut Creek WWW: Serveur WWW de Walnut Creek .... En Australie chez : [.programlisting] .... Advanced Multimedia Distributors Factory 1/1 Ovata Drive Tullamarine, Melbourne Victoria Australia Tel: +61 3 9338 6777 CDROM Support BBS 17 Irvine St Peppermint Grove WA 6011 Tel: +61 9 385-3793 Fax: +61 9 385-2360 .... En Angleterre : [.programlisting] .... The Public Domain & Shareware Library Winscombe House, Beacon Rd Crowborough Sussex. TN6 1UL Tel: +44 1892 663-298 Fax: +44 1892 667-473 .... === Où trouver de l'information sur les listes de messagerie ? Vous trouverez ces informations dans link:{handbook}#eresources[la section sur les listes de diffusion du manuel] === Quels sont les forums de discussion disponibles sur FreeBSD ? Tous les forums sont listés dans la section sur link:{handbook}#eresources/[les forums de discussion] du manuel === Existe-t-il des canaux IRC(Internet Relay Chat) sur FreeBSD ? Oui, la plupart des réseaux IRC comportent un canal FreeBSD. * Le canal _#FreeBSD_ sur EFNET est sûrement le plus populaire et est disponible sur _irc.chat.org_. * Le canal _#FreeBSD_ sur DALNET est disponible sur _irc.dal.net_ pour les US et sur _irc.eu.dal.net_ pour l'Europe. * Le canal _#FreeBSD_ sur UNDERNET est disponible sur _us.undernet.org_ pour les US et sur _eu.undernet.org_ pour l'Europe. * Enfin vous pouvez rejoindre _#FreeBSD_ sur BSDNET, un petit serveur de chat BSD sur _irc.FreeBSD.org_ Tous ces canaux sont distincts et ne sont pas interconnectés entre eux. Les discussions sur chaque canal diffèrent, donc essayez-les tous avant de trouver celui qui vous convient. === Quels sont les livres parlant de FreeBSD ? Le livre de Greg Lehey's "stalling and Running FreeBSD" est disponible chez Walnut Creek CDROM et comprend le CDROM de la version 2.2.8. Il y a aussi un livre plus important nommé "The Complete FreeBSD" qui est lui livré avec certaines pages de manuel et qui inclut aussi les CDROMs de la version 2.2.8. Ils devraient aussi etre disponibles dans toutes les bonnes librairies. Il existe aussi un projet se nommant "FreeBSD Documentation Project", que vous pouvez contacter (ou mieux, joindre) sur la "liste de diffusion doc"link:mailto:freebsd-doc@FreeBSD.ORG[]. Cette liste a pour but de discuter sur la documentation de FreeBSD. Les questions plus générales sur FreeBSD sont à poser dans la "mailing list" link:mailto:freebsd-questions@FreeBSD.ORG[]. Un link:{handbook}[manuel] sur FreeBSD est disponible. Sachez, pour information, que ce manuel est en perpétuelle évolution, et que certaines parties peuvent être incomplètes. Comme FreeBSD 2.2.X est basé sur la version 4.4.BSD-lite2, la plupart des manuels relatifs à 4.4BSD peuvent s'appliquer à FreeBSD. Des versions imprimées sont disponibles chez O'Reilly: [.programlisting] .... 4.4BSD System Manager's Manual By Computer Systems Research Group, UC Berkeley 1st Edition June 1994, 804 pages ISBN 1-56592-080-5 .... [.programlisting] .... 4.4BSD User's Reference Manual By Computer Systems Research Group, UC Berkeley 1st Edition June 1994, 905 pages ISBN 1-56592-075-9 .... [.programlisting] .... 4.4BSD User's Supplementary Documents By Computer Systems Research Group, UC Berkeley 1st Edition July 1994, 712 pages ISBN 1-56592-076-7 .... [.programlisting] .... 4.4BSD Programmer's Reference Manual By Computer Systems Research Group, UC Berkeley 1st Edition June 1994, 886 pages ISBN 1-56592-078-3 .... [.programlisting] .... 4.4BSD Programmer's Supplementary Documents By Computer Systems Research Group, UC Berkeley 1st Edition July 1994, 596 pages ISBN 1-56592-079-1 .... Une courte description de ces livres est disponible via WWW à l'adresse suivante : http://gnn.com/gnn/bus/ora/category/bsd.html[http://gnn.com/gnn/bus/ora/category/bsd.html]. Vu le peu de ventes, ces livres sont relativement difficiles a trouver. Pour plus d'informations sur le noyau 4.4BSD vous pouvez vous reporter au livre suivant : [.programlisting] .... McKusick, Marshall Kirk, Keith Bostic, Michael J Karels, and John Quarterman. The Design and Implementation of the 4.4BSD Operating System. Reading, Mass. : Addison-Wesley, 1996. ISBN 0-201-54979-4 .... Un bon livre sur l'administration système: [.programlisting] .... Evi Nemeth, Garth Snyder, Scott Seebass & Trent R. Hein, ``Unix System Administration Handbook'', Prentice-Hall, 1995 ISBN 0-13-151051-7 .... _Attention à bien acheter la deuxième édition, version avec la couverture rouge, et non pas la première._ Ce livre couvre les bases de l'administration système aussi bien que TCP/IP, le DNS, NFS, SLIP/PPP, sendmail, INN/NNTP, l'impression, etc... Il est assez onéreux (environ 300-350 FF) mais est indispensable. Il comprend en plus un CDROM contenant énormément d'outils, dont la plupart sont inclus sur les CDROM de FreeBSD. === Comment accèder à la base de données des problèmes ? La base de données des problèmes est accessible (pour soumission ou interrogation) en utilisant votre navigateur WWW http://www.freebsd.org/send-pr/[ pour la soumission] ou http://www.freebsd.org/cgi/query-pr-summary.cgi[ pour l'interrogation ]. La commande _send-pr(1)_ peut aussi être utilisée pour soumettre des problèmes et des modifications par courrier électronique. === Où peut-on trouver des versions ASCII/PostScript de cette FAQ ? La dernière version de cette FAQ est disponible sur le serveur WWW de FreeBSD ou sur tout serveur miroir en PostScript ou texte (ASCII 7 bits et Latin1 8 bits). Le PostScript (environ 370Ko) link:http://www.freebsd-fr.org/FAQ/FAQ.ps[http://www.freebsd-fr.org/FAQ/FAQ.ps] En format texte ISO 8859-1 (environ 220Ko): http://www.freebsd-fr.org/FAQ/FAQ.txt[http://www.freebsd-fr.org/FAQ/FAQ.txt] === Où peut-on trouver des versions ASCII/PostScript du manuel ? La dernière version du manuel est disponible sur le serveur WWW de FreeBSD ou sur tout serveur miroir en PostScript ou texte (ASCII 7 bits et Latin1 8 bits). Le PostScript (environ 1.7Mo) link:http://www.freebsd-fr.org/handbook/handbook.ps[http://www.freebsd-fr.org/handbook/handbook.ps] En format texte ISO 8859-1 (environ : 1.1Mo) link:http://www.freebsd-fr.org/handbook/handbook.txt[http://www.freebsd-fr.org/handbook/handbook.txt] === La version ASCII du manuel ne contient pas que du texte ! C'est vrai. Les versions ASCII et Latin1 de la FAQ et du manuel ne contiennent pas que du texte. Elles contiennent des soulignés et d'autres codes qui supposent que l'impression sera faite sur une imprimante matricielle. Si vous avez besoin de reformater ces fichiers sous une forme plus lisible, lancez la commande col sur le fichier : [.programlisting] .... $ col -b < fichierOrigine > fichierSortie .... === Je voudrais devenir un miroir WWW de FreeBSD ! Bien sûr ! Différents moyens permettent de synchroniser les pages WWW. * En utilisant CVSUP: vous pouvez retrouver les pages formatées en HTML en utilisant CVSUP depuis cvsup.freebsd.org. Ajoutez simplement cette ligne à votre fichier cvsup: + [.programlisting] .... www release=current hostname=/home base=/usr/local/etc/cvsup prefix=/usr/local/www/data/www.freebsd.org delete old use-rel-suffix .... * En utilisant rsync: voir la http://www.freebsd.org/internal/mirror/[ page sur les miroirs] pour les informations. * En utilisant un miroir ftp: vous pouvez télécharger la copie sur serveur WWW se trouvant sur le serveur ftp. Les fichiers se trouvent à ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/www . === Je veux traduire la documentation en Javanais On ne peut pas vous payer, mais on peut s'arranger pour vous envoyer un CDROM gratuit ou un T-shirt et une entrée dans la liste des contributeurs du Handbook si vous nous soumettez une traduction de la documentation. === Autres sources d'informations. Les forums de discussion suivants se rapportent à FreeBSD * link:news:fr.comp.os.bsd[fr.comp.os.bsd] (en francais) * link:news:comp.unix.bsd.freebsd.announce[ comp.unix.bsd.freebsd.announce] (en anglais - modéré) * link:news:comp.unix.bsd.freebsd.misc[comp.unix.bsd.freebsd.misc] (en anglais) * link:news:comp.unix.bsd.misc[comp.unix.bsd.misc] (en anglais) Ressources WWW: * La http://www.freebsd.org/[page principale de FreeBSD] * La http://www.freebsd-fr.org/[page principale de fr.FreeBSD] * [[pao]]Si vous possédez un portable, vous devez visiter la page de http://www.jp.FreeBSD.org/PAO/[Tatsumi Hosokawa's Mobile Computing] au Japon * Pour plus d'informations sur SMP (Symmetric MultiProcessing) voyez la http://www.freebsd.org/~fsmp/SMP/SMP.html[page du support SMP] * Pour plus d'informations sur les applications multimedia FreeBSD , voyez la page http://www.freebsd.org/~faulkner/multimedia/mm.html[ multimédia]. Si vous vous intéressez plus spécialement à la capture vidéo Bt848 suivez ce http://www.freebsd.org/~ahasty/Bt848.html[ lien]. Le manuel de FreeBSD contient une section link:{handbook}#bibliography/[ bibliographie] plus importante, si vous recherchez d'autres livres ou informations. == Installation. **Mise à jour en cours** === Quels fichiers télécharger pour installer FreeBSD ? Vous n'avez généralement besoin que d'une image-disque, le fichier [.filename]#floppies/boot.flp#, que vous copiez sur une disquette 1.44 Mo et qui permet de démarrer pour pouvoir télécharger le reste (l'installation prend en charge votre connexion TCP/IP, votre lecteur de bandes, CDROM, disquettes, partitions DOS, tout ce est nécessaire pour le reste de l'installation). Si vous avez besoin de télécharger la distribution par vous même (pour une installation depuis une partition DOS par exemple), voici quels sont les fichiers à récupérer: * Tout le répertoire [.filename]#bin# * Tout le répertoire [.filename]#manpages# * Tout le répertoire [.filename]#compat# * Tout le répertoire [.filename]#doc# * Tous les fichiers [.filename]#src/ssys.*# Vous trouverez les instructions complètes pour cette procédure et un peu plus au sujet de l'installation en général dans la section link:{handbook}#install[ installation de FreeBSD] du manuel. === A l'aide ! L'image-disque de démarrage ne tient pas sur une seule disquette ! Une disquette 3,5 pouces (1.44 Mo) peut contenir jusqu'à 1474560 octets de données. La taille du fichier image est exactement 1474560 octets. Les erreurs courantes concernant la création de la disquette de démarrage sont les suivantes : * Vous n'avez pas téléchargé l'image-disque en mode `binary` en utilisant FTP + Certains clients FTP mettent par défaut le transfert en mode _ASCII_, et essayent de changer le caractère de fin de ligne reçu pour correspondre aux conventions utilisées par le système client. Cela altère presque inévitablement le fichier image. Vérifiez la taille du fichier image téléchargé: si elle n'est pas _exactement_ la même que sur le serveur, alors le processus de téléchargement est suspect. + Une solution simple : tapez `binary` à l'invite FTP, après la connexion sur le serveur et avant le démarrage du téléchargement de l'image. * Vous avez utilisé la commande DOS `copy` (ou une commande équivalente) pour transférer l'image de démarrage sur la disquette. + Les programmes comme `copy` ne fonctionnent pas correctement avec les images, car ils ne peuvent créer une disquette de démarrage. L'image est le contenu exact de la disquette, piste à piste, et ne peut être copiée sur la disquette comme un fichier normal. Vous devez la transférer sur la disquette en mode brut {raw} en utilisant les outils de bas niveau {low-level} `fdimage` ou `rawrite`. Ces outils sont décrits dans la section link:{handbook}#install/[installation de FreeBSD] du manuel. === Où sont les instructions pour installer FreeBSD ? Les instructions d'installation de FreeBSD se trouvent dans la section link:link:{handbook}#install[ installation de FreeBSD] du manuel. === De quoi ai-je besoin pour faire tourner FreeBSD ? Vous avez besoin d'un PC 386 ou mieux, avec 5Mo ou plus de mémoire vive (RAM) et au moins 60Mo de disque dur. Il suffit d'une carte graphique MDA, mais pour utiliser X11R6, une carte video VGA ou mieux est nécessaire. Voir aussi la section <>. === Je n'ai que 4Mo de mémoire vive. Puis-je installer FreeBSD ? FreeBSD 2.1.7 est la dernière version de FreeBSD que l'on peut installer sur des systèmes avec 4Mo de mémoire vive. Les nouvelles versions de FreeBSD, comme la version 2.2, ont besoin d'au moins 5Mo de mémoire vive pour être installées sur un nouveau système. Toutes les versions de FreeBSD, y compris la version 3.0, peuvent fonctionner avec 4Mo de mémoire vive, mais ne peuvent pas exécuter le programme d'installation en 4Mo. Vous pouvez ajouter de la mémoire vive supplémentaire pour le processus d'installation, si vous voulez, et quand le système fonctionne, revenir à 4Mo. Ou vous pouvez placer votre disque sur un système disposant de plus de 4Mo, effectuer l'installation et l'échanger à nouveau. Il y a malgré tout des situations dans lesquelles FreeBSD 2.1.7 ne peut s'installer avec 4Mo. Pour être exact : cette version de n'installe pas avec 640Ko de mémoire de base et 3Mo de mémoire étendue. Si votre carte mère peut réallouer quelques blocs mémoire "perdue" hors de la région entre 640Ko et 1Mo alors vous pourrez installer FreeBSD 2.1.7 Regardez dans la configuration de votre BIOS si vous disposez d'un option "remap". Si oui, activez la. Vous devez aussi désactiver la copie miroir de la mémoire ROM. Il est plus simple d'augmenter la mémoire vive à plus de 4Mo pour l'installation, construire un noyau contenant juste les options dont vous avez besoin, puis revenir à une configuration avec 4Mo. Vous pouvez dans le pire des cas, installer la version 2.0.5 et effectuer une mise à jour de votre système en version 2.1.7 avec l'option `upgrade` du programme d'installation de la 2.1.7. Après l'installation, si vous construisez un noyau sur mesure, cela tournera sans problème avc 4Mo. Certaines personnes ont même réussi a démarrer sur un système disposant de 2Mo de mémoire vive (bien sûr le système fut complétement inutilisable :-)). === Comment créer ma propre disquette d'installation ? Actuellement il n'y a pas de solution pour créer *juste* une disquette d'installation personnalisée. Vous devez créer une distribution complète, qui contiendra votre disquette d'installation. Le code se trouvant dans [.filename]#/usr/src/release/floppies/Makefile# peut laisser supposer que vous pouvez créer votre disquette, mais ce n'est pas le cas actuellement. Pour créer votre propre version, suivez les instructions se trouvant <>. === Puis-je avoir plus d'un système d'exploitation sur mon PC ? Voyez la page du tutoriel sur la <>. === Est-ce que Windows 95 peut coexister avec FreeBSD ? Installez en premier Windows 95, puis FreeBSD. Le gestionnaire de démarrage de FreeBSD, vous permet de démarrer indifféremment sous Windows 95 ou FreeBSD. Si vous installez Windows 95 en second, il surchargera votre gestionnaire de démarrage sans même poser une question. Si cela arrive, voir la section suivante. === Windows 95 a effacé mon gestionnaire de démarrage ! Comment le récupérer ? Vous pouvez ré-installer le gestionnaire de démarrage de FreeBSD de deux manières : * Sous DOS, allez dans le répertoire [.filename]#tools# de votre distribution FreeBSD et cherchez un programme [.filename]#bootinst.exe#. Il vous l'exécutez ainsi: + [source,shell] .... c:\tools>bootinst.exe boot.bin .... + et le gestionnaire de démarrage sera ré-installé * Démarrez à nouveau sous FreeBSD avec la disquette de démarrage et allez dans le menu `Custom installation`. Choisissez `Partition` Sélectionnez le disque devant contenir le gestionnaire de démarrage (probablement le premier) et quand vous arrivez dans l'éditeur de partition, la première chose à faire (c'est à dire n'effectuer aucun changement) sélectionnez `(W)rite`. Vous serez interrogé pour confirmation, répondez `yes`, et quand vous obtenez le menu de sélection du gestionnaire de démarrage, assurez vous de bien sélectionner `Boot manager`. Cela re-écrit le gestionnaire de démarrage sur le disque. Ensuite quittez le programme d'installation et redémarrez à partir du disque dur normalement. === Peut-on installer FreeBSD sur un disque comportant des secteurs défectueux ? La gestion des secteurs défectueux (voir la commande http://www.freebsd.org/cgi/man.cgi?bad144[bad144]) de FreeBSD n'est pas fiable à 100% ; il serait plus juste de dire que si vous disposez d'un disque IDE ou ESDI avec énormement de bad blocks, alors FreeBSD n'est pas pour vous ! En fait FreeBSD tourne sur des centaines de systèmes à base de disques IDE, il vaut mieux essayer avant de vous décourager. Si vous avez un disque SCSI comportant des secteurs défectueux, voyez <> === Il se passe des choses étranges lorsque je démarre depuis la disquette d'installation ! Si vous détectez des choses comme : un blocage de la machine, un redémarrage inopiné de votre système avec la disquette d'installation, posez vous les 3 questions suivantes : . Avez-vous utilisé une disquette neuve, sans erreurs (préférez une disquette sortie de la boîte plutôt qu'une disquette provenant du dernier magazine oublié sous votre lit depuis trois ans) ? . Avez vous téléchargé l'image en mode binaire (ne vous offusquez pas, même les meilleurs d'entre nous, ont téléchargé des fichiers en mode ASCII au moins une fois) ? . Si vous utilisez des systèmes d'exploitation récents comme Windows 95 ou Windows NT, avez vous arrété le système et redémarré en DOS simple et honnête ? Il semble que ces systèmes peuvent interférer avec des programmes qui écrivent directement sur le matériel, comme c'est le cas des programmes de création de disquette ; même en l'exécutant dans une fenêtre DOS de windows cela peut causer ces problèmes. Certaines informations mentionnant que Netscape pose des problèmes en téléchargeant l'image de la disquette de démarrage, donc utilisez un client FTP différent si vous pouvez. === Je n'arrive pas à installer à partir de la bande Si vous installez la version 2.1.7R à partir d'une bande, vous devez créer la bande en utilisant un facteur de blocage de 10 (5120 octets). Le facteur de blocage par défaut de [.filename]#tar# est 20 (10240 octets), et les bandes crées en utilisant cette valeur par défaut ne peuvent pas être utilisées pour installer la version 2.1.7R ; avec ce type de bande vous obtiendrez une erreur disant que la taille des enregistrements est trop grande. === Connecter deux systèmes FreeBSD par les ports parallèle (PLIP) Trouvez un câble "laplink". Vérifiez que les deux ordinateurs ont un noyau avec le support de pilote [.filename]#lpt#. [.programlisting] .... $ dmesg | grep lp lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface .... Installez le câble "laplink" sur les ports parallèlle. Configurez les paramètres de l'interface réseau pour lp0 des deux côtés en tant que `root`. Par exemple, si vous voulez connecter l'ordinateur max avec moritz : [.programlisting] .... max <-----> moritz IP Address 10.0.0.1 10.0.0.2 .... sur max, démarrez : [.programlisting] .... # ifconfig lp0 10.0.0.1 10.0.0.2 .... sur moritz, démarrez : [.programlisting] .... # ifconfig lp0 10.0.0.2 10.0.0.1 .... C'est tout ! Lisez aussi les manpages man:lp[4] and man:lpt[4]. Vous devez aussi ajouter les deux adresse dans [.filename]#/etc/hosts# : [.programlisting] .... 127.0.0.1 localhost.my.domain localhost 10.0.0.1 max.my.domain max 10.0.0.2 moritz.my.domain moritz .... Pour vérifier le bon fonctionnement faire : sur max : [.programlisting] .... $ ifconfig lp0 lp0: flags=8851 mtu 1500 inet 10.0.0.1 --> 10.0.0.2 netmask 0xff000000 $ netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire moritz max UH 4 127592 lp0 $ ping -c 4 moritz PING moritz (10.0.0.2): 56 data bytes 64 bytes from 10.0.0.2: icmp_seq=0 ttl=255 time=2.774 ms 64 bytes from 10.0.0.2: icmp_seq=1 ttl=255 time=2.530 ms 64 bytes from 10.0.0.2: icmp_seq=2 ttl=255 time=2.556 ms 64 bytes from 10.0.0.2: icmp_seq=3 ttl=255 time=2.714 ms --- moritz ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms .... === Peut-on effectuer une installation par le port parallèle (PLIP) Connectez les deux ordinateurs avec un cable parallèle "Laplink" .Cable parallèle [source, bash] .... +----------------------------------------+ |A-name A-End B-End Descr. Port/Bit | +----------------------------------------+ |DATA0 2 15 Data 0/0x01 | |-ERROR 15 2 1/0x08 | +----------------------------------------+ |DATA1 3 13 Data 0/0x02 | |+SLCT 13 3 1/0x10 | +----------------------------------------+ |DATA2 4 12 Data 0/0x04 | |+PE 12 4 1/0x20 | +----------------------------------------+ |DATA3 5 10 Strobe 0/0x08 | |-ACK 10 5 1/0x40 | +----------------------------------------+ |DATA4 6 11 Data 0/0x10 | |BUSY 11 6 1/0x80 | +----------------------------------------+ |GND 18-25 18-25 GND - | +----------------------------------------+ .... Voir aussi <> sur la page de FreeBSD pour les portables === Quelle géométrie dois-je utiliser pour un disque ? (Par le mot "géométrie" d'un disque, nous pensons aux nombres de cylindres, têtes et secteurs par pistes sur un disque - Nous dirons par la suite C/H/S. C'est de cette façon que le BIOS des PC arrive à écrire ou lire une zone du disque). Cela peut préter à confusion pour différentes raisons. Premièrement, la _géométrie physique_ d'un disque SCSI ne veut rien dire, de la façon dont FreeBSD utilise les blocs disques. En fait, on ne peut parler de "la" géométrie physique, la densité des secteurs variant sur le disque -ce que les fabricants appellent la "vraie" géométrie physique, c'est la géométrie qu'ils ont détérminé, pour avoir le moins d'espace perdu. Pour les disques IDE, FreeBSD voit en terme de C/H/S, mais tous les disques récents convertissent cela en blocs eux-mêmes. Tout cela est, en fait, la _géométrie logique_ la réponse que le BIOS reçoit lorsqu'il demande "quelle est votre géométrie ?" et qu'il utilise pour accéder au disque. Comme FreeBSD utilise le BIOS pour démarrer, il est très important qu'elle soit juste. En particulier, si vous avez plus d'un système d'exploitation sur votre disque, ils doivent être d'accord sur la géométrie, sinon vous rencontrerez de graves problèmes au démarrage du système. Pour les disques SCSI, la géométrie à utiliser dépend du support de translation étendu activé sur votre contrôleur (ou encore appelé "support pour les disques DOS >1Go" ou similaire). S'il n'est pas activé, utilisez N cylindres, 64 têtes et 32 secteurs par pistes, ou 'N' est la capacité du disque en Mo. Par exemple, pour un disque de 2Go vous devez utiliser 2048 cylindres, 64 têtes et 32 secteurs par piste. Si cette option est active (c'est le cas la plupart du temps pour permettre de passer outre certaines limitations de MSDOS) et que le disque a une capacité de plus de 1Go, utilisez M cylindres, 63 têtes (et *pas* 64), et 255 secteurs par piste, où M correspond à la capacité en Mo divisé par 7.844238 (!). Donc, en prenant un disque de 2Go nous obtenons 261 cylindres, 63 têtes et 255 secteurs par piste. Si vous n'êtes pas sûr de point, ou si FreeBSD n'arrive pas à détecter la géométrie correctement au moment de l'installation, la façon la plus simple de faire, est de créer une petite partition DOS sur le disque. La géométrie correcte sera alors détectée (et vous pourrez toujours retirer la partition DOS dans l'éditeur de partitions si vous ne voulez pas la garder ou conservez la pour la programmation de cartes réseau). Une autre solution est d'utiliser un outil disponible librement distribué avec FreeBSD appelé [.filename]#pfdisk.exe# (il se trouve dans le répertoire [.filename]#tools# du CDROM de FreeBSD ou sur les sites ftp), qui permet de voir quelle géométrie utilisent les autres systèmes sur ce disque. Vous pourrrez ensuite entrer cette géométrie dans l'éditeur de partitions. === Y a-t-il des restrictions sur la façon de partitionner le disque ? Oui. Vous devez vous assurer que la partition "[.filename]#/#""[.filename]#{root}#" se trouve dans les 1024 premiers cylindres, pour permettre au BIOS de trouver le noyau. (Notez que c'est une limitation dûe au BIOS des PC et non pas à FreeBSD). Dans le cas d'une disque SCSI, cela implique que la partition "[.filename]#/#""[.filename]#{root}#" soit dans les 1024 premiers Mo (ou dans les 4096 premiers si la translation est en place - voir la question précédente). Pour un disque IDE, il faut qu'elle se trouve dans les 504 premiers Mo. === A propos des gestionnaires de disque ? Ou bien, j'ai un disque de grande capacité ! FreeBSD reconnait le gestionnaire "Ontrack Disk Manager" et le tolère. Les autres gestionnaires de disque ne sont pas supportés. Si vous voulez utiliser le disque uniquement avec FreeBSD, vous n'avez pas besoin de gestionnaire de disque. Configurez simplement le disque pour utiliser le maximum de place reconnue par le BIOS (la plupart du temps 504Mo), et FreeBSD trouvera de lui même la capacité de votre disque. Si vous utilisez un vieux disque avec un controlleur MFM, vous devrez donner explicitement à FreeBSD le nombre de cylindres à utiliser. Si vous voulez utiliser le disque avec FreeBSD et un autre système d'exploitation, vous n'aurez pas besoin d'un gestionnaire de disque: assurez vous que la partition de démarrage de FreeBSD et les tranches pour les autres systèmes d'exploitation se trouvent dans les 1024 premiers cylindres. Si vous êtes prudent, une partition de démarrage de 20Mo doit suffire. === Lors du démarrage de FreeBSD j'obtiens "Missing Operating System" C'est le symptôme classique où FreeBSD et DOS, ou un autre système d'exploitation, sont en conflit à propos de la [[geometry2]] géométrie du disque. Vous devez alors réinstaller FreeBSD, en faisant attention à toutes les informations qui vous sont présentées. === Je ne peux pas aller plus loin que le message `F?` du gestionnaire de démarrage. Ceci est un autre symptôme du problème décrit à la question précédente. La géométrie trouvée par le BIOS et celle de FreeBSD ne sont pas les mêmes. Si votre contrôleur ou votre BIOS supporte la translation de cylindres (souvent indiquée comme "Support des disques >1Go"), essayez de changer les paramètres et réinstallez FreeBSD. === Je dispose de plus de 16Mo de RAM. Est-ce que cela peut poser un problème ? Mis à part les problèmes de performances, non. FreeBSD 2.X inclus des "bounce buffers" permettant à votre bus principal d'accéder à plus de 16Mo de mémoire. (Notez que cela n'est vrai que pour les périphériques ISA, et quelques périphériques EISA ou VLB). Voyez aussi la section parlant des ordinateurs <>, si vous avez autant de mémoire, ou si vous utilisez un ordinateur Compaq ou un autre BIOS qui donne de mauvaises informations sur la mémoire disponible. === Dois-je installer tous les sources ? La plupart du temps, non. Malgré tout, nous vous conseillons fortement d'installer, au minimum, les sources de base ([.filename]#sbase#) ainsi que les sources du noyau ([.filename]#ssys#). Il n'y a rien dans le système qui nécessite la présence des sources, sauf si vous désirez http://www.freebsd.org/cgi/man.cgi?config[reconfigurer] le noyau du système. A l'exception du noyau, notre structure de compilation est faite pour vous permettre de visualiser les sources (même en lecture seule) et de construire alors de nouveaux binaires. (En raison de la restriction des sources du noyau, nous vous recommandons de monter les sources ailleurs que dans [.filename]#/usr/src# en créeant les liens symboliques appropriés permettant de dupliquer la structure complète des sources). En ayant les sources à votre disposition et en sachant comment l'on construit un système avec, cela permettra d'avoir une façon très simple pour mettre à jour votre système vers les prochaines versions de FreeBSD. Pour n'installer qu'une partie des sources, utilisez le menu `Custom` quand vous êtes dans le menu `Distributions` du programme d'installation. Le script [.filename]#src/install.sh# peut installer aussi certains éléments des sources, en fonction des arguments que vous lui passez. === Suis-je obligé de construire un nouveau noyau ? Construire un nouveau noyau, était encore, il y a quelque temps, une étape à peu près obligatoire après l'installation de FreeBSD, mais les nouvelles versions ont bénéficié d'un utilitaire de configuration du noyau plus sympathique. Au démarrage de FreeBSD et après l'invite de démarrage (`boot:`) utilisez le paramètre `-c` et vous aurez alors accès au menu de configuration visuel, qui vous permet de configurer les paramètres de la plupart des cartes ISA. Il est encore recommandé construire un nouveau noyau contenant juste les pilotes dont avez besoin, seulement pour économiser un peu de RAM, mais ce n'est plus une exigence stricte pour la plupart des systèmes. === Je réside en dehors des Etats-Unis. Puis-je utiliser le DES ? Si la méthode de cryptage _DES_ ne vous est pas absolument nécessaire, alors vous pouvez utiliser le système de cryptage fourni par défaut avec FreeBSD et qui vous apporte une bien meilleure sécurité, sans aucune restriction d'exportation. Le cryptage des mots de passe par défaut de FreeBSD 2.0 est maintenant basé sur _MD5_, qui est plus difficile à casser que _DES_, avec un outil automatisé en raison de sa forte demande en temps de calcul, et qui permet aussi d'utiliser des mots de passe plus longs. La seule raison pour laquelle vous ne pouvez pas utiliser le cryptage basé sur _MD5_ est, si vous désirez utiliser la même entrée du fichier des mots de passe sur des systèmes FreeBSD et non-FreeBSD. Comme l'algorithme de cryptage _DES_ ne peut pas être légalement exporté en dehors des Etats-Unis, tout utilisateur non américain ne doit pas télécharger les logiciels l'incluant (se trouvant dans le répertoire [.filename]#sec# des sites FTP américains) Il y a cependant une librairie de remplacement disponible, libcrypt, basée sur des sources écrit en Australie par David Burren. Le code est maintenant disponible sur certains sites ftp miroirs en dehors des Etats-Unis. Les sources, ainsi que les binaires des programmes l'utilisant peuvent être téléchargés sur les sites ftp suivants: * Afrique du Sud: ** ftp://ftp.internat.freebsd.org/pub/FreeBSD ** ftp://storm.sea.uct.ac.za/pub/FreeBSD * Brésil: ** ftp://ftp.iqm.unicamp.br/pub/FreeBSD * Finlande: ** ftp://nic.funet.fi/pub/unix/FreeBSD/eurocrypt Cette distribution non-US peut être directement utilisée à la place de la distribution américaine. Ce paquetage s'installe de la même façon que le paquetage américain (regardez les notes d'installation du paquetage pour plus de détails). Si vous désirez installer le cryptage _DES_, vous devez l'installer le plus tôt possible, avant l'installation de tout autre logiciel. Les utilisateurs ne résidant pas aux Etats-Unis ne doivent télécharger aucun programme de cryptage sur un site américain. Cela pourrait entrainer, pour les responsables du site depuis lequel le logiciel est téléchargé, de graves problèmes juridiques. Une distribution non-US de Kerberos est aussi en cours de développement, et les versions courantes peuvent généralement être obtenues depuis un site FTP anonyme link:ftp://braee.ru.ac.za[braae.ru.ac.za] Il existe aussi une liste de messagerie discutant de tous les logiciels non-US de cryptage. Pour plus d'informations, envoyez un email contenant le mot "help" dans le corps du message à link:mailto:majordomo@braae.ru.ac.za[] === La disquette de démarrage se bloque sur le message "Probing Devices..." Si vous disposez d'un disque ZIP ou JAZ, retirez-le et recommencez. La disquette d'installation a des problèmes avec ce genre de disque. Une fois le système installé, vous pouvez reconnecter le disque. Si tout va bien ce problème sera fixé dans une version ultérieure. === J'obtiens le message "panic: cant mount root" lors du redémarrage de mon système après l'installation. Cette erreur indique un conflit entre les blocs de démarrage du système et la connaissance du noyau sur les disques. Cette erreur arrive fréquemment dans le cas d'un système disposant de deux disques IDE, avec chaque disque installé en maître ou périphérique unique sur des contrôleurs séparés, avec FreeBSD installé sur le contrôleur IDE secondaire. Le programme de démarrage pense que le système est installé sur wd1 (le second disque vu par le BIOS) alors que le noyau affecte wd2 au premier disque du deuxième contrôleur. Après le test de tous les périphériques, le noyau essaye de "monter" ce que le programme de démarrage pense être le disque de démarrage, wd1, alors qu'il s'agit en fait de wd2 et échoue. Pour résoudre ce problème, effectuez les opérations suivantes : * Au message de démarrage tapez : `1:wd(2,a)kernel` puis Entrée. Si le système démarre, lancez la commande `echo "1:wd(2,a)kernel" > /boot.config` pour affecter la bonne chaîne de démarrage. * Déplacez le disque FreeBSD sur le controleur primaire, les disques sont alors vus de façon contigus. * link:{handbook}#kernelconfig[Reconstruisez un noyau] en modifiant les lignes de configuration wd pour avoir: + [.programlisting] .... controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr disk wd0 at wdc0 drive 0 # disk wd1 at wdc0 drive 1 # comment out this line controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr disk wd1 at wdc1 drive 0 # change from wd2 to wd1 disk wd2 at wdc1 drive 1 # change from wd3 to wd2 .... Puis installez le nouveau noyau. Si vous avez déplacé vos disques et vous voulez restaurer la configuration précédente, placez les disques dans la configuration désirée puis redémarrez. Votre système doit démarrer correctement. === Quelles sont les limites mémoire ? Pour la mémoire, la limite est (en théorie) 4Go. Un essai a été fait avec un Go ; vous ne pourrez probablement pas acheter des PC i386 pouvant supporter plus que cela. === Quelles sont les tailles limites pour les systèmes de fichiers FFS ? La taille maximum théorique d'un système de fichiers FFS est de 8 téraoctets (2G blocs) ou de 16To avec la taille de bloc par défaut de 8K. Il y a en pratique une limite logicielle à 1 téraoctet mais, avec quelques modifications, il est possible d'avoir des systèmes de fichiers de 4 téraoctet (et il en existe). La taille maximum d'un fichier FFS est d'environ 1G blocs (4To), quand la taille de bloc est de 4K. [.programlisting] .... taille de fichier maximum ----------------------------------------- 2.2.7 3.0 taille de bloc -stable -current marche devrait marcher -------------- ------- -------- ------ --------------- 4K 4T-1 4T-1 4T-1 4+T 8K 32+G 8T-1 32+G 16T-1 16K 128+G 16T-1 128+G 32T-1 32K 512+G 32T-1 512+G 64T-1 64K 2048+G 64T-1 2048+G 128T-1 .... Quand la taille du bloc est de 4K, l'adressage du bloc par indirection triple fonctionne et la limite devrait être définie par le plus grand numéro de bloc qui peut être reprété avec une indirection triple (approximativement 1K^3 + 1K^2 + 1K), mais la limite effective est en fait donnée par une valeur (erronée) de 1G-1 pour le nombre de blocs maximum. Cette valeur devraite être de 2G-1. Il y a des bogues avec les blocs dont le numéro est voisin de 2G-1, et ces blocs ne peuvent être adressés quand la taille du bloc est de 4K. Pour les tailles de blocs de 8K et plus, tout devrait être limité par la valeur de 2G-1 pour les numéros de blocs, mais l'est en fait par la valeur maximum de 1G-1, hormis sous -stable, les blocs adressés par indirection triple ne peuvent être atteints, la limite est donc donnée par le plus grand numéro de bloc qui peut être adressé par une double indirection (approximativement (taille du bloc/4)^2 + (taille du bloc/4)), et dépasser cette limite sous -current peut poser des problèmes. Utiliser la valeur correcte de 2G-1 blocs posent à coup sûr des problèmes. === Comment puis-je mettre des fichiers de 1To sur une disquette ? J'en ai plusieurs - virtuels - sur disquette :-). La taille maximum d'un fichier n'a pas de lien étroit avec la dimension maximum d'un disque. Un disque peut avoir jusqu'à un 1To. Il est fonctionnellement possible d'avoir un fichier plus grand que le disque. L'exemple suivant crée un fichier de 8T-1 occupant 32K d'espace disque. (3 blocs indirects et 1 bloc de données) sur une petite partition racine. Il faut pour cela une version de la commande `dd` qui fonctionne sur de gros fichiers. [.programlisting] .... ttyv0:bde@alphplex:/tmp/q> cat foo df . dd if=/dev/zero of=z bs=1 seek=`echo 2^43 - 2 | bc` count=1 ls -l z du z df . ttyv0:bde@alphplex:/tmp/q> sh foo Filesystem 1024-blocks Used Avail Capacity Mounted on /dev/sd0a 64479 27702 31619 47% / 1+0 records in 1+0 records out 1 bytes transferred in 0.000187 secs (5346 bytes/sec) -rw-r--r-- 1 bde bin 8796093022207 Sep 7 16:04 z 32 z Filesystem 1024-blocks Used Avail Capacity Mounted on /dev/sd0a 64479 27734 31587 47% / ttyv0:bde@alphplex:/tmp/q> exit .... Bruce Evans, September 1998 == Compatibilité matérielle. **Mise à jour en cours** === Quels sont les types de disques durs supportés par FreeBSD ? FreeBSD supporte les disques EIDE et SCSI (pour les contrôleurs compatibles, voir la section suivante), ainsi que tous les disques utilisant l'interface originale "Western Digital" (MFM, RLL, ESDI et bien sûr IDE). Quelques contrôleurs ESDI utilisant des interfaces propriétaires peuvent ne pas marcher: utilisez les interfaces WD1002/3/6/7 et leurs clones. === Quels sont les contrôleurs SCSI supportés ? Voir la liste complète dans le link:{handbook}#install[Handbook]. === Quels sont les lecteurs CD-ROM supportés par FreeBSD ? N'importe quel lecteur SCSI connecté à un contrôleur supporté est supporté. Les interfaces CD-ROM propriétaires suivantes sont aussi supportées: * Mitsumi LU002 (8 bits), LU005 (16 bits) et FX001D (16 bits double vitesse). * Sony CDU 31/33A * CD-ROM Sound Blaster Non-SCSI * CD-ROM Matsushita/Panasonic * CD-ROM ATAPI compatible IDE Toutes les cartes non-SCSI sont connues pour être extrêmement lentes par rapport aux lecteurs SCSI, et certains CDROM ATAPI peuvent ne pas être pris en charge. A partir de la version 2.2, le CD-ROM FreeBSD de Walnut Creek permet de démarrer directement FreeBSD depuis le CD. === Est-ce que FreeBSD supporte les lecteurs ZIP ? FreeBSD supporte bien sûr les lecteurs ZIP SCSI de base - out of the box. Les lecteurs ZIP ne peuvent être réglés que pour marcher sur les cibles SCSI d'adresse 5 ou 6, mais si le BIOS de votre adaptateur SCSI hôte le permet, vous pourrez même démarrer à partir du ZIP. Je ne sais pas quel adaptateur SCSI hôte vous permet de démarrer depuis des cibles autres que 0 ou 1... regardez votre documentation (et dites moi si cela marche pour vous). Les ZIP ATAPI (IDE) sont pris en charge par FreeBSD 2.2.6 ainsi que par les versions ultérieures. FreeBSD 3.0-STABLE contient le support pour lecteur ZIP sur port parallèle, mais pour cela, vous aurez à construire un nouveau noyau avec support pour ppbus (Parallel Port Bus) afin d'utiliser le ZIP. Prendre le fichier de configuration LINT comme exemple. Regarder aussi cette note traitant <>, ainsi que celle sur <>. === Est-ce que FreeBSD supporte JAZ, EZ et autres disques amovibles ? A part la version IDE du lecteur EZ, ce sont tous des périphériques SCSI, alors pour FreeBSD, ils sont considérés comme des disques SCSI, et le lecteur IDE EZ est considéré comme un lecteur IDE. [[jaz]]Je ne suis pas sûr que FreeBSD supporte correctemement un changement de media en cours de fonctionnement. Vous devrez bien sûr démonter le lecteur avant l'échange, et vous assurer que les unités externes soient allumées pendant le démarrage du système de sorte que FreeBSD puisse les voir. === Quelles sont les cartes séries multi-ports prises en charge par FreeBSD ? Une liste est disponible à la section link:{handbook}#INSTALL-HW[périphériques divers ] du handbook. A notre connaissance, certaines cartes clone sans marque sont connues pour fonctionner, en particulier celles qui se disent être compatibles AST. Regarder la page de manuel http://www.freebsd.org/cgi/man.cgi?sio[sio] pour plus d'informations sur la configuration de telles cartes. === J'ai une souris bus inhabituelle. Comment la configurer ? FreeBSD supporte les souris bus et les souris bus InPort de constructeurs tels que Microsoft, Logitech et ATI. Le contrôleur du bus est compilé dans le noyau GENERIC par défaut. Si vous construisez un noyau personalisé avec le contrôleur de souris bus, assurez-vous d'avoir bien mis la ligne suivante dans le fichier de configuration du noyau : [.programlisting] .... device mse0 at isa? port 0x23c tty irq5 vector mseintr .... La souris bus vient souvent avec une interface dédiée. Cela vous permet de mettre une adresse de port et un numéro d'IRQ autres que ceux donnés ci-dessus. Reportez-vous au manuel de votre souris et à la page de manuel http://www.freebsd.org/cgi/man.cgi?mse[mse] pour plus d'informations. === Comment utiliser ma souris PS/2 (port souris ou clavier) ? Si vous utilisez une version de FreeBSD post-2.2.5, le pilote nécessaire, psm, est inclu et activé dans le noyau. Le noyau devrait détecter votre souris PS/2 au moment du démarrage. Si vous utilisez une version précédente mais assez récente de FreeBSD (2.1.x ou mieux), alors vous pouvez simplement l'activer dans le menu de configuration du noyau à l'installation, ou plus tard avec -c à l'invite du démarrage (boot). Il est désactivé par défaut, c'est pourquoi vous aurez à l'activer explicitement. Si vous utilisez une version plus ancienne du noyau, alors vous aurez à ajouter la ligne suivante dans la configuration de votre noyau, et compiler un nouveau noyau : [.programlisting] .... device psm0 at isa? port "IO_KBD" conflicts tty irq 12 vector psmintr .... Voir la link:{handbook}#kernelconfig/[section du Handbook sur la configuration du noyau] si vous n'avez aucune expérience dans la construction d'un noyau. Un fois que vous aurez un noyau détectant correctement psm0 au moment du démarrage, assurez vous qu'une entrée pour psm0 existe bien dans /dev. Vous pouvez le faire en tapant : [.programlisting] .... cd /dev; sh MAKEDEV psm0 .... une fois loggué sous root. === Puis-je utiliser ma souris en dehors de X Window ? Si vous utilisez le pilote de console par défaut, syscons, vous pourrez utiliser un curseur souris dans les consoles texte pour couper et coller du texte. Lancer le démon (de gestion de la) souris : moused, et déclencher le curseur de souris dans la console virtuelle. [.programlisting] .... moused -p /dev/xxxx -t yyyy vidcontrol -m on .... Où [.filename]#xxxx# est le nom du périphérique souris et [.filename]#yyyy# le type de protocole pour la souris. Voir la page de manuel http://www.freebsd.org/cgi/man.cgi?moused[moused] pour les types de protocoles supportés. Peut-être préférez-vous lancer le démon gérant la souris au moment du démarrage du système. Dans la version 2.2.1, positionnez les variables suivantes dans [.filename]#/etc/sysconfig#. [.programlisting] .... mousedtype="yyyy" mousedport="xxxx" mousedflags="" .... Dans les versions 2.2.2 et plus, positionnez les variables suivantes dans [.filename]#/etc/rc.conf#. [.programlisting] .... moused_type="yyyy" moused_port="xxxx" moused_flags="" .... A partir de la version 2.2.6 de FreeBSD, le démon souris est capable de déterminer le type de protocole approprié automatiquement à moins que votre souris série ne soit d'un modèle relativement ancien. Spécifiez [.filename]#auto# comme protocole pour activer la détection automatique. Quand le démon souris tourne, l'accès à la souris doit être coordonné entre le démon souris et les autres programmes comme X-Window. Se référer à <> de ce document. === Comment puis-je couper et coller du texte avec ma souris dans ma console texte ? Une fois que vous aurez réussi à lancer le démon souris (voir <>), appuyez en le maintenant sur le bouton 1 (bouton de gauche) et déplacez la souris afin de sélectionner une partie du texte. Puis, appuyez (clicquez) sur le bouton 2 (bouton du milieu) ou bouton 3 (bouton de droite) pour le coller à l'endroit du curseur texte. Dans les versions 2.2.6 et plus, un clic sur le bouton 2 collera le texte. Un clic sur le bouton droit étendra la partie de texte sélectionné. Si votre souris n'a pas de bouton du milieu, vous pouvez l'émuler ou redéfinir les boutons en utilisant les options de la souris. Se reporter à la page de référence http://www.freebsd.org/cgi/man.cgi?moused[moused] pour plus de détails. === Ma souris a une roulette et des boutons ésotériques. Puis-je les utiliser sous FreeBSD ? Malheureusement, la réponse est: Cà dépend. Ces souris avec des fonctionnalités supplémentaires ont besoin de pilotes spéciaux dans la majorité des cas. Alors, à moins que le pilote de la souris ou que le programme utilisateur ait un support spécifique pour cette souris, la souris se comportera comme une souris standard 2 ou 3 boutons. === Comment utiliser la souris/trackball/touchpad de mon portable ? Se référer à <> ainsi qu'à cette section sur <>. === Quels types de lecteurs de bandes sont supportés ? FreeBSD supporte les lecteurs de bandes magnétique SCSI, QIC-36 (avec une interface QIC-02) et QIC-40/80 (basés sur l'interface Floppy). Ceci inclut les lecteurs 8-mm (connus sous le nom d'Exabyte) et lecteurs DAT. Les lecteurs QIC-40/80 sont connus pour être lents. Parmi les premiers lecteurs 8-mm, quelques-uns ne sont pas tout à fait compatibles SCSI-2, et peuvent de ce fait ne pas très bien marcher avec FreeBSD. === FreeBSD supporte-t-il les changeurs de bandes ? FreeBSD 2.2 gère les changeurs SCSI en utilisant le périphérique http://www.freebsd.org/cgi/man.cgi?ch(4)[ch] ainsi que la commande http://www.freebsd.org/cgi/man.cgi?chio[chio]. Pour avoir plus de détails sur le contrôle du changeur, lisez la page du manuel http://www.freebsd.org/cgi/man.cgi?chio[chio]. Si vous n'utilisez pas http://www.freebsd.org/cgi/ports.cgi?amanda[AMANDA] ou un autre produit qui gère déjà les changeurs, souvenez-vous qu'ils ne savent que déplacer une bande d'un point à un autre. Par conséquent, vous devrez garder une trace de l'emplacement dans lequel une bande est mise, ainsi que celui où la bande courante devra revenir. === Quelles sont les cartes son supportées par FreeBSD ? FreeBSD prend en charge les cartes son: SoundBlaster, SoundBlaster Pro, SoundBlaster 16, Pro Audio Spectrum 16, AdLib et Gravis UltraSound. Il y a aussi un support limité pour les cartes MPU-401 et compatible MIDI. Les cartes conformes aux spécifications Microsoft Sound System sont aussi supportées par l'intermédiaire du pilote pcm. [NOTE] ==== Ceci n'est valable que pour les sons! Ce pilote ne supporte pas les CD-ROMs, SCSI ou joysticks sur ces cartes, excepté pour la SoundBlaster. L'interface SCSI SoundBlaster et quelques CD-ROM non-SCSI sont aussi supportés. Mais vous ne pourrez pas démarrer depuis ces périphériques. ==== === Quels sont les cartes réseau supportées par FreeBSD ? Regarder la section link:{handbook}#INSTALL-HW[ cartes éthernet] du handbook pour une liste complète. === Je n'ai pas de coprocesseur arithmétique. Est-ce un problème ? [NOTE] ==== Cela ne touche que ceux qui ont un 386/486SX/486SLC - toutes les autres machines en ont déjà un intégré dans la CPU. ==== En règle générale, il n'y a pas d'inconvénient, mais il existe des circonstances dans lesquelles cela peut causer des problèmes aussi bien au niveau des performances qu'au niveau de la précision du code d'émulation arithmétique (voir la section <>). En particulier, le dessin de courbes sous X sera TRES lent. Il est hautement recommandé d'acheter un coprocesseur arithmétique : c'est quand même mieux avec ! [NOTE] ==== Certains coprocesseurs mathématiques sont meilleurs que d'autres. Cela nous peine de le dire, mais personne n'a jamais été licencié pour avoir acheté de l'Intel. A moins que d'être sûr qu'ils fonctionnent avec FreeBSD, méfiez-vous des clones ! ==== === Quels autres périphériques la version 2.X supporte-t-elle ? Lire le link:{handbook}#INSTALL-HW[Handbook] pour obtenir la liste des périphériques supportés. === FreeBSD supporte-t-il le gestionnaire d'énergie de mon portable ? FreeBSD supporte l'APM sur certaines machines. Regardez dans le fichier de configuration du noyau [.filename]#LINT#, et cherchez le mot-clef http://www.freebsd.org/cgi/man.cgi?apm[APM]. === Solutions de contournement pour des problèmes matériels particuliers. Cette section traite de solutions de contournement pour des problèmes rencontrés par nos utilisateurs sur certains matériels particuliers. ==== Les systèmes Micron sont suspendus au moment du démarrage. Certaines cartes mères Micron ont des implémentations non-conformes de PCI BIOS, ce qui peut poser des problèmes lorsque FreeBSD démarre car les périphériques PCI ne sont pas configurés à l'adresse annoncée. Désactivez l'option "Système d'exploitation Plug and Play" dans le BIOS pour contourner ce problème. Des compléments d'informations peuvent être trouvés à http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html#micron["http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html#micron"] === J'ai un nouveau contrôleur Adaptec, et FreeBSD ne le reconnait pas. Les nouvelles puces de la série Adaptec AIC789x sont supportées dans le cadre du CAM SCSI qui démarre avec la 3.0. Des patches pour la version 2.2-STABLE sont disponibles à link:ftp://ftp.freebsd.org/pub/FreeBSD/cam/[ ftp://ftp.freebsd.org/pub/FreeBSD/cam/ ] Une disquette d'amorce avec CAM est disponible à http://www.freebsd.org/~abial/cam-boot/[ http://www.freebsd.org/~abial/cam-boot/]. Dans les deux cas, lisez le fichier README avant toute chose. === J'ai un modem interne plug'n play, et FreeBSD ne le reconnait pas. Vous devez ajouter l'ID PnP du modem à la liste des ID PnP dans le pilote série. Pour activer le support Plug & Play, il faut compiler un nouveau noyau avec [.filename]#controller pnp0# dans le fichier de configuration, puis redémarrer le système. Le noyau affichera alors l'ID PnP de tous les périphériques qu'il trouvera. Copier alors l'ID PnP du modem dans le tableau de [.filename]#/sys/i386/isa/sio.c#, vers la ligne 1200. Cherchez la chaîne de caractère "SUP1310" dans la structure "siopnp_ids[]" pour trouver le tableau. Construire à nouveau le noyau, installer, redémarrer, et votre modem devrait être reconnu. Vous pouvez configurer manuellement les périphériques PnP en utilisant la commande `pnp` à la configuration au moment du démarrage, avec une commande du style : [.programlisting] .... pnp 1 0 enable os irq0 3 drq0 0 port0 0x2f8 .... pour afficher le modem. === Comment puis-je obtenir l'invite de commande `boot:` sur la console série ? * Construire un noyau avec [.filename]#options COMCONSOLE#. * Créer un fichier /boot.config avec pour seul contenu [.filename]#-P# * Déconnecter le clavier du système. Redardez [.filename]#/usr/src/sys/i386/boot/biosboot/README.serial# pour plus d'informations. === Pourquoi ma carte réseau 3Com PCI ne marche pas avec mon Micron ? Certaines cartes mères Micron ont une implémentation non-conforme du BIOS PCI qui ne configure pas les périphériques PCI à l'adresse annoncée. Cela cause des problèmes quand FreeBSD démarre. Pour contourner ce problème, désactiver l'option "Système d'exploitation Plug and Play" dans le BIOS. Pour plus d'informations sur ce problème, allez voir à l'URL: http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html#micron[ http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html#micron ] === FreeBSD supporte-t-il les Multiprocesseurs Symétriques (SMP) ? SMP n'est supporté que dans la version 3.0-STABLE et les versions suivantes. == Résolutions des incidents. **Mise à jour en cours** [[awre]] === J'ai des secteurs défectueux sur mon disque dur ! Pour les disques SCSI, le disque devrait être capable de réallouer ceux-ci automatiquement. Quoiqu'il en soit, beaucoup de disques sont livrés avec cette fonctionnalité désactivée, pour une raison mystérieuse... Pour l'activer, vous aurez à éditer le first device page mode, ce qui peut être fait sur FreeBSD en tapant la commande (sous root) [.programlisting] .... scsi -f /dev/rsd0c -m 1 -e -P 3 .... et en changeant la valeur de AWRE et ARRE de 0 à 1 : [.programlisting] .... AWRE (Auto Write Reallocation Enbld): 1 ARRE (Auto Read Reallocation Enbld): 1 .... Les paragraphes suivants ont été soumis par link:mailto:tedm@toybox.placo.com[Ted Mittelstaedt] : Pour les disques IDE, le moindre secteur défectueux est habituellement un signe d'incident potentiel. Tous les disques IDE modernes sont livrés avec la réallocation des secteurs défectueux activée. Tous les fabriquants de disques durs IDE offrent aujourd'hui des garanties étendues et remplaceront les disques possédant des secteurs défectueux. Si vous voulez toutefois essayer de récupérer un disque IDE avec des secteurs défectueux, vous pouvez essayer de télécharger le programme de diagnostic du fabriquant de disque IDE et de le faire exécuter sur le disque. Quelquefois, ces programmes peuvent être configurés pour forcer l'électronique du disque à rebalayer le disque pour les secteurs défectueux et leur inhibition. Pour les disques ESDI, RLL et MFM, les secteurs défectueux font partie de la vie normale du disque et ne sont pas signes d'incidents, généralement. Avec un PC, la carte contrôleur de disque et le BIOS prennent en charge la tâche d'inhibition des secteurs défectueux. C'est bien pour les systèmes d'exploitation comme DOS qui utilisent le code du BIOS pour accéder au disque. Toutefois, le driver de disque FreeBSD ne passe pas par le BIOS, aussi un mécanisme, bad144, existe pour remplacer cette fonctionnalité. bad144 ne fonctionne qu'avec le driver [.filename]#wd#, il ne peut _pas_ être utilisé avec le SCSI. bad144 fonctionne en entrant tous les secteurs défectueux trouvés dans un fichier spécial. Un inconvénient avec bad144 - le fichier spécial des secteurs défectueux est placé sur la dernière piste du disque. Comme ce fichier contient peut-être une liste de secteurs dont l'un serait près du début du disque, où le fichier noyau [.filename]#/kernel# serait aussi localisé, il doit donc être accéssible au progamme d'amorce (bootstrap) qui utilise les appels du BIOS pour lire le fichier du noyau. Cela signifie qu'un disque géré avec bad144 ne peut dépasser 1024 cylindres, 16 têtes et 63 secteurs. Cela place une limite effective de 500Mo sur un disque qui est réalloué avec bad144. Pour utiliser bad144, positionnez simplement le balayage des secteurs défectueux Bad Block à ON dans le menu `fdisk` de FreeBSD lors de l'installation initiale. Cela marche jusqu'à la version 2.2.7 de FreeBSD. Le disque doit avoir moins de 1024 cylindres. Il est généralement recommandé de laisser tourner préalablement le disque pendant plus de 4 heures avant cette opération, pour tenir compte de la dilatation thermique et des pistes errantes. Si le disque a plus de 1024 cylindres (comme un gros disque ESDI), le contrôleur ESDI utilise un mode de translation spécial pour le faire fonctionner sous DOS. Le driver [.filename]#wd# comprend ces modes de translation, _si_ vous entrez la géométrie "translatée" avec la commande `set geometry` dans `fdisk`. De plus, vous ne devez _pas_ utiliser le mode dangerously dedicated de création d'une partition FreeBSD, parce qu'il ignore la géométrie. De plus, même si `fdisk` va utiliser votre géométrie surchargée, il continue à connaître la vrai taille du disque et va tenter de créer une partition FreeBSD trop grande. Si la géométrie du disque est remplacée par la géométrie translatée, la partition _doit_ être créée manuellement avec le nombre de secteurs. Un truc rapide à utiliser est d'initialiser le gros disque ESDI avec le contrôleur ESDI, le démarrer avec un disque DOS et le formatter avec une partition DOS. Puis, démarrez l'installation FreeBSD et dans le menu `fdisk`, lire depuis l'écran et écrire à côté la taille et le nombre de secteurs de la partition DOS. Puis, réinitilisez la géométrie comme celle de DOS en détruisant la partition DOS et en créant une partition FreeBSD cooperative avec la taille précédemment notée. Puis positionnez la partition pour être amorçable et autorisez le balayage des secteurs défectueux. Pendant l'installation réelle, `bad144` passera en premier, avant la moindre création de systèmes de fichiers (vous pouvez le voir avec un `Alt-F2`). S'il a le moindre problème pour créer le fichier des secteurs défectueux, vous avez initialisé une géométrie de disque trop grande - redémarrez le système et recommencez tout depuis le début (y compris le repartitionnement et reformattage en DOS). Si la réallocation est autorisée et que vous voyez des secteurs défectueux, envisagez un remplacement du disque. Les secteurs défectueux ne feront que s'aggaver au fil du temps. === FreeBSD ne reconnait pas ma carte EISA SCSI Bustek 742a ! Cette information est spécifique à la 742a, mais peut aussi couvrir les autres cartes Buslogic (Bustek = Buslogic). Il y a 2 `versions` générales de la carte 742a. Ce sont les révisions matérielles A-G et H - et plus. La lettre de révision est placée après le numéro d'assemblage sur le bord de la carte. La 742a possède 2 puces ROM dessus, l'une est la puce BIOS et l'autre est la puce Firmware. Si FreeBSD ne fait pas attention à la version de la puce BIOS que vous avez, il le fait par contre pour la version de la puce Firmware. Buslogic vous enverra des ROMs de mise à jour si vous appelez leur support technique. Les puces BIOS et Firmware sont appariées. Vous devez avoir la ROM Firmware la plus en cours dans votre carte d'adaptatation pour votre révision de matériel. Les cartes REV A-G ne peuvent recevoir que les versions de BIOS/Firmware 2.41/2.21. Les cartes REV H - et plus peuvent accepter les plus récente versions de BIOS/Firmware 4.70/3.37. La différence entre ces jeux de firmware est que le 3.37 supporte l'allocation tournante (`round robin`). Les cartes Buslogic ont aussi un numéro de série inscrit. Si vous avez une vieille révision de carte, vous pouvez appeler le département Buslogic RMA et leur donner le numéro de série afin d'essayer d'échanger celle-ci contre une révision plus récente. Si votre carte n'est pas trop vieille, il l'échangeront. FreeBSD 2.1 ne supporte que les versions firmware 2.21 et plus. Si vous avez une version Firmware plus vieille, votre carte ne sera pas reconnue comme une carte Buslogic. Elle peut malgré tout être reconnue comme une carte Adaptec 1540. La vieille carte firmware contient un mode `émulation` AHA1540. Quoiqu'il en soit, ce n'est pas une bonne chose pour une carte EISA. Si vous avez une vieille révision de carte et que vous obtenez le firmware 2.21, vous aurez à vérifier la position du cavalier (jumper) W1 à B-C ; par défaut, il est positionné à A-B. Les cartes EISA 742q n'ont jamais eu le problème `>16Mo` mentionné dans la section <16 Mo>>. Ceci est un problème qui apparaît avec les cartes SCSI Buslogic Vesa-Local. === Mon contrôleur SCSI HP Netserver n'est pas détecté ! C'est à la base un problème connu. Le contrôleur SCSI-EISA intégré sur la carte mère des machines HP Netserver occupe le slot EISA numéro 11, aussi tous les `vrais` slots EISA se retrouvent devant lui. Malheureusement, l'espace d'adressage pour les slots EISA >= 10 se retrouve en conflit avec l'espace d'adressage assigné aux slots PCI, et l'auto-configuration de FreeBSD ne peut actuellement pas très bien gérer cette situation. Donc, pour le moment, le mieux que vous ayez à faire, est de prétendre qu'il n'y a pas de conflit de plage d'adresse :-), en propulsant l'option du noyau [.filename]#EISA_SLOTS# à la valeur 12. Configurez et compilez un noyau comme décrit dans link:{handbook}#kernelconfig/[le manuel de référence sur la configuration du noyau]. Bien sûr, cela se présente comme le problème bien connu de la poule et de l'oeuf lorsque l'on installe sur une telle machine. Afin de pouvoir contourner ce problème, un hack spécial est disponible au moment de la configuration utilisateur (UserConfig). Ne pas utiliser l'interface `visual`, mais l'interface en mode texte. Tapez simplement : [.programlisting] .... eisa 12 quit .... au prompt, et installez le système comme d'habitude. Quoiqu'il en soit, il est recommandé de compiler et d'installer un noyau adapté. http://www.freebsd.org/cgi/man.cgi?dset[dset] comprend aussi maintenant qu'il faut sauver cette valeur. Heureusement, les versions futures auront une solution appropriée à ce problème. [NOTE] ==== Vous ne pouvez pas utiliser un disque *dangereusement dédié* (dangerously dedicated) avec un Netserver HP. Voir http://www.freebsd.org/cgi/man.cgi?dedicate[cette note ] pour plus d'informations. ==== === Que se passe-t'il avec le contrôleur CMD640 IDE controller? Il ne marche pas, Il ne peut pas manipuler des commandes sur les deux canaux simultanément. Il y a un détour disponible à présent, et elle s'active automatiquement si votre système utilise cette puce. Pour plus de détails, référez-vous à la page de manuel du driver de dique (man 4 wd). Si vous lancez déjà FreeBSD 2.2.1 ou 2.2.2 avec un contrôleur IDE CMD640 et que vous voulez utiliser le deuxième canal, construisez un nouveau noyau avec les options [.filename]#options "CMD640"# activé. Il est mis par défaut pour FreeBSD 2.2.5 et plus. === Je n'arrête pas de voir [.filename]#ed1: timeout#. Cela est généralement causé par un conflit d'interruption (par exemple , 2 cartes utilisant le même IRQ). FreeBSD avant 2.0.5R était tolérant et fonctionnait même en cas de conflit d'IRQ. Mais à partir du 2.0.5R, les conflits ne sont plus tolérés. Booter avec l'option -c et changer l'ed0/de0/... pour se conformer à votre carte. Si vous utilisez un connecteur BNC sur votre carte réseau, vous pouvez aussi voir des timeouts sur les périphériques à cause de mauvaise terminaison. Pour le vérifier, attachez un terminateur directement au NIC (sans câble) et regardez si les messages d'erreurs disparaissent. Certaines cartes compatibles NE2000 donneront une telle erreur s'il n'y a pas de liaison sur le port UTP ou si le cable est déconnecté. === Quand je monte le CD-ROM, j'obtiens Incorrect super block. Vous devez spécifier à http://www.freebsd.org/cgi/man.cgi?mount[ mount ] le type de périphérique que vous voulez monter. Par défaut, http://www.freebsd.org/cgi/man.cgi?mount[ mount ] supposera que le système de fichier est de type [.filename]#ufs#. Vous pouvez vouloir monter un système de fichier CDROM, et vous pouvez le faire en spécifiant l'option [.filename]#-t cd9660# à http://www.freebsd.org/cgi/man.cgi?mount[ mount ]. Cela suppose évidemment que le CDROM contienne un système de fichier ISO 9660 , qui est celui qu'ont presque tous les CDROM. Comme pour le 1.1R, FreeBSD comprend automatiquement les extensions Rock Ridge (nom long). Par exemple, si vous voulez monter le lecteur CDROM [.filename]#/dev/cd0c#, sous le répertoire [.filename]#/mnt#, vous aurez à exécuter : [.programlisting] .... mount -t cd9660 /dev/cd0c /mnt .... Bien noter que le nom du périphérique ([.filename]#/dev/cd0c# de cet exemple peut être différent suivant l'interface du CDROM. Noter que l'option [.filename]#-t cd9660#'' ne fait qu'exécuter la commande [.filename]#mount_cd9660#, c'est ainsi que l'exmple pourrait être simplifié en : [.programlisting] .... mount_cd9660 /dev/cd0c /mnt .... === Quand je monte un CDROM, j'obtiens Device not configured. Cela veut généralement dire qu'il n'y a pas de CDROM dans le lecteur de CDROM, ou que le lecteur n'est pas visible du bus. Mettez un disque dans le lecteur, et/ou vérifiez son état maître/esclave si c'est un IDE (ATAPI). Cela peut prendre quelques secondes pour le lecteur CDROM pour s'apercevoir qu'il y a un disque, alors, soyez patient. De temps en temps, un lecteur CD-ROM SCSI peut être manqué car il n'a pas eu assez de temps pour répondre à la réinitialisation du bus. Si vous avez un lecteur CDROM SCSI, essayez d'ajouter la ligne suivante dans votre fichier de configuration du noyau, et recompilez. [.programlisting] .... options "SCSI_DELAY=15" .... === Mon imprimante est extrêmement lente, que puis-je faire ? Si c'est du parallèle, et que le seul problème est qu'elle est terriblement lente, essayez de positionner votre port imprimante en mode poller: [.programlisting] .... lptcontrol -p .... Certaines nouvelles imprimantes HP sont soupçonnées de ne pas fonctionner correctement en mode interruption, apparemment, cela est dû a certains problème de timing (mais cela n'est pas encore exactement compris). === Mes programmes se tuent souvent avec l'erreur Signal 11. Cela peut-être causé par du mauvais matériel (mémoire, carte mère...). Essayez de lancer un programme de test de mémoire sur votre PC. Notez que même si chaque programme de test de mémoire essayeront de vous dire que tout va bien, il est possible que certaines rares zones de mémoire passent tous les tests mémoires, mais échouent pourtant durant certaines conditions d'opération (comme pendant qu'un bus maîtrise l'accès direct à la mémoire depuis un contrôleur SCSI comme l'Adaptec 1542, quand vous chargez la mémoire en compilant le noyau, ou quand le système tourne dans des conditions très critiques) La FAQ sur SIG11 (listée ci-dessous) dénonce les mémoires lentes comme étant le problème le plus courant. Augmentez le nombre d'états d'attente dans votre configuration du BIOS ou récupérez de la mémoire plus rapide. Pour moi, la partie incriminée a été une mauvaise mémoire cache, ou un mauvais contrôleur cache. Essayez de désactiver le cache secondaire dans la setup BIOS, et regardez si cela résoud le problème. Il y a une FAQ plus détaillée sur http://www.bitwizard.nl/sig11/[ la FAQ du problème SIG11 ] === Quand je boote, l'écran devient noir, et perd sa synchronisation Ceci est un problème connu avec les cartes vidéo ATI Mach 64. Le problème est que cette carte utilise l'adresse [.filename]#2e8#, et que le quatrième port série aussi. Dû à un bug (une fonctionnalité ?) dans le driver http://www.freebsd.org/cgi/man.cgi?sio[ sio.c ], cela touchera ce port même si vous n'avez pas ce quatrième port série, et *même* si vous désactives sio3 (le quatrième port) qui utilise normalement cette adresse. Jusqu'à ce que ce bug soit fixé, vous pouvez utiliser cette astuce : * Entrez [.filename]#-c# à l'invite. (Cela mettra le noyau en mode configuration). * Désactivez [.filename]#sio0#, [.filename]#sio1#, [.filename]#sio2# and [.filename]#sio3# (tous). De cette manière, le driver sio ne sera pas activé. et donc plus de problèmes. * Tapez exit et continuez le rebootage. Si vous voulez pouvoir utiliser les ports séries, vous aurez à construire un nouveau noyau avec les modifications suivantes : Dans [.filename]#/usr/src/sys/i386/isa/sio.c# cherchez la seule occurence de la chaîne [.filename]#0x2e8# et enlevez cette chaîne et la virgule précédente (gardez la virgule de liaison). Puis suivre la procédure normale de la construction d'un nouveau noyau. Même après avoir appliqué toutes ces astuces, vous pouvez trouver que X Window ne marche pas correctement, Certaines nouvelles cartes vidéo ATI Mach 64 (notamment ATI Mach Xpression) ne marche pas avec la version actuelle de [.filename]#XFree86#; l'écran devient noir quand vous démarrez X Window, ou alors il marche avec des problèmes étranges. Vous pouvez obtenir la version beta d'un nouveau serveur X qui marche mieux. Regardez sur http://www.xfree86.org[ le site XFree86 site ] et suivez les liens à la nouvelle beta release. Récupérez les fichiers suivants : [.filename]#AccelCards, BetaReport, Cards, Devices, FILES, README.ati,README.FreeBSD, README.Mach64, RELNOTES, VGADriver.Doc,X312BMa64.tgz# Remplacez les vieux fichiers avec ceux de la nouvelle version et vérifiez que vous lancez bien : http://www.freebsd.org/cgi/man.cgi?manpath=xfree86&query=xf86config[ xf86config ] à nouveau. === J'ai 128 MB de RAM mais le système n'en voit que 64 MB. Dûe à la façon dont FreeBSD récupère la taille de la mémoire depuis le BIOS, il ne peut seulement détecter qu'une taille dont la valeur est codée en kilo-octets par 16 bits (65535 Ko = 64MB) (ou moins... certains BIOS tronque la taille de la mémoire à 16Mo). Si vous avez plus de 64 Mo, FreeBSD tentera de le détecter, mais il se peut que cette tentative échoue. Pour contourner ce problème, vous devez utiliser l'option du noyau donnée ci-dessous. Il y a une manière de récupérer les informations complète de la mémoire depuis le BIOS, mais nous n'avons pas assez de place sur les blocks de boot pour le faire. Un jour, quand le manque de place sur les blocs de boots sera résolu, nous utiliserons les fonctions du BIOS étendu pour récupérer l'information complète sur la mémoire... mais pour l'instant, nous utilisons cette option du noyau. [.filename]#options "MAXMEM="# Où [.filename]#n# est votre mémoire en KiloOctet. Pour une machine à 128Mo, vous pouvez utiliser [.filename]#131072#. === FreeBSD 2.0 panique avec kmem_map too small! [.filename]#Note :# Le message peut aussi être mb_map too small!' La panique indique que le système n'a plus de mémoire virtuelle pour les buffers réseau (spécialement mbuf clusters). Vous pouvez augmenter la quantité de mémoire virtuelle disponible pour les clusters mbuf en ajoutant : [.filename]#options "NMBCLUSTERS="# dans votre configuration du kernel, où est un nombre compris entre 512 et 4096, suivant le nombre de connexions concurrentes TCP que vous aurez à supporter. Je vous recommande d'utiliser 2048 - cela devrait vous débarasser complètement de cette panique. Vous pouvez contrôler le nombre de clusters mbuf alloué/en cours d'utilisation sur votre système, avec http://www.freebsd.org/cgi/man.cgi?netstat[ netstat -m ]. La valeur par défaut pour NMBCLUSTERS est [.filename]#512 + MAXUSERS * 16/#. === CMAP busy panic au moment d'un reboot avec un nouveau noyau. La logique permettant de détecter un fichier obsolète [.filename]#/var/db/kvm_*.db# peut parfois échouer et utiliser un fichier non approprié peut alors conduire à cette panique. Si cela arrive, rebooter en mode single-user et faites : [.programlisting] .... rm /var/db/kvm_*.db .... === ahc0: brkadrint, Illegal Host Access at seqaddr 0x0 C'est un conflit avec l'adaptateur hôte Ultrastor SCSI. Durant la procédure de boot, entrez dans le menu de configuration du noyau et désactivez http://www.freebsd.org/cgi/man.cgi?uha(4)[ uha0" ] qui est à la cause de ce problème. === Sendmail me dit mail loops back to myself Cela est répondu dans la FAQ sendmail de la façon suivante : [.programlisting] .... * Je reçois des messages "Local configuration error" messages, comme: 553 relay.domain.net config error: mail loops back to myself 554 ... Local configuration error Comment puis-je résoudre ce problème ? Vous avez demandé que les mails adressés au domaine (par exemple domain.net) soient dirigés vers un hôte spécifique (dans ce cas relay.domain.net) en utilisant un enregistrement MX, mais la machine de relai ne s'est pas reconnu lui-même comme domain.net. Ajoutez domain.net à /etc/sendmail.cw (si vous utilisez FEATURE(use_cw_file)) ou ajoutez "Cw domain.net" à /etc/sendmail.cf. .... La version actuelle de link:ftp://rtfm.mit.edu/pub/usenet/news.answers/mail/sendmail-faq[ la FAQ sendmail ] n'est plus maintenue avec la release sendmail. Mais elle est de toute façon postée régulièrement à : link:news:comp.mail.sendmail[ comp.mail.sendmail ], link:news:comp.mail.misc[ comp.mail.misc ], link:news:comp.mail.smail[ comp.mail.smail ], link:news:comp.answers[ comp.answers ], et link:news:news.answers[ news.answers ]. Vous pouvez aussi en recevoir une copie par courrier électronique, en envoyant un mail à : link:mailto:mail-server@rtfm.mit.edu[ mail-server@rtfm.mit.edu ] avec la commande with the command "send usenet/news.answers/mail/sendmail-faq" comme corps de message. === Les applications plein-écran sur des machines distantes se comportent étrangement. La machine distante peut régler votre type de terminal à autre chose que le type de terminal [.filename]#cons25# utilisé par la console FreeBSD. Il y a un certains nombres de contournement de ce problème : * Après s'être loggué sur la machine distante, positionnez votre variable d'environnement TERM à soit [.filename]#ansi# soit [.filename]#sco#. * Utilisez localement un émulateur VT100 comme http://www.freebsd.org/cgi/ports.cgi?screen[. screen ][.filename]#screen# permet la possibilité de lancer plusieurs sessions concurentes depuis un terminal. * Installez l'entrée [.filename]#cons25# du terminal dans la base de données sur la machine distante. * fire up X et login vers la machine distante depuis un [.filename]#xterm#. == Applications commerciales. **Mise à jour en cours** NOTE : Cette section est encore très clairsemée, car nous espérons naturellement, que les industries y contribueront :-) L'organisation FreeBSD n'a aucun intérêt financier dans aucune des sociétés énumérées ici, mais les liste simplement comme service public (et estime que l'intérêt commercial dans FreeBSD peut avoir des effets très positifs sur la viabilité à long terme de FreeBSD). Nous encourageons les constructeurs de logiciel commerciaux à envoyer leurs références ici pour inclusion. Voir http://www.fr.freebsd.org/commercial/commercial.html[ les pages des constructeurs ] pour une liste plus complète. === Où puis je obtenir Motif pour FreeBSD ? Contactez http://www.apps2go.com[Apps2go] pour une distribution ELF Motif 2.1 pour FreeBSD. Cette distribution comprend : * OSF/Motif manager, xmbind, panner, wsm. * Les librairies ELF statiques et dynamiques (utilisables avec FreeBSD 3.0 et supérieur). * Kit de développement avec les fichiers uil, mrm, xm, xmcxx, include et Imake. * Des applications de démonstration. Soyez sûr d'indiquer que vous voulez la version de FreeBSD de Motif lors de la commande ! Des versions pour NetBSD et OpenBSD sont également vendues par _Apps2go_. Vous avez actuellement juste la possiblité de télécharger en FTP. [.programlisting] .... Pour plus d'informations Serveur WWW de Apps2go Ou les addresse de messageries du département des ventes ou encore du support Tél: (817) 431 8775 ou +1 817 431-8775 .... Contactez http://www.metrox.com[Metro Link] pour une distribution a.out ou ELF Motif 2.1 pour FreeBSD. Cette distribution comprend : * OSF/Motif manager, xmbind, panner, wsm. * Kit de développement avec les fichiers uil, mrm, xm, xmcxx, include et Imake. * Les librairies a.out et ELF statiques et dynamiques (utilisables avec FreeBSD 3.0 et supérieur pour les librairies ELF et 2.2.8 et supérieur pour les librairies a.out ). * Des applications de démonstration. * Les pages de manuel préformattées Soyez sûr d'indiquer que vous voulez la version de FreeBSD de Motif lors de la commande ! Des versions pour Linux sont également vendues par _Metro Link_. La distribution est disponible par téléchargement FTP ou sur un CDROM. Contactez http://www.xig.com[Xi Graphics] pour une distribution a.out Motif 2.0 pour FreeBSD. Cette distribution comprend : * OSF/Motif manager, xmbind, panner, wsm. * Les librairies a.out statiques et dynamiques (utilisables avec FreeBSD 2.2.8 et supérieur). * Kit de développement avec les fichiers uil, mrm, xm, xmcxx, include et Imake. * Des applications de démonstration. * Les pages de manuel préformattées Soyez sûr d'indiquer que vous voulez la version de FreeBSD de Motif lors de la commande ! Des versions pour BSDI et Linux sont également vendues par _Xi Graphics_. La distribution comprend actuellement 4 disquettes. Dans le futur il y aura un CD comme pour CDE. === Où puis-je avoir CDE pour FreeBSD? Contactez http://www.xig.com[Xi Graphics] pour une distribution CDE 1.0.10 pour FreeBSD. Cela inclut Motif 1.2.5, et peut être utilisé avec Motif 2.0. C'est une distribution CDROM uniforme pour FreeBSD et Linux. === Y a-t-il des serveurs X commerciaux haute-performance ? Oui, http://www.xig.com[ Xi Graphics ] et http://www.metrolink.com[Metro Link] vendent leur produit Accelerated-X pour FreeBSD et autres systèmes basés sur Intel. Le serveur X de Metro Link offre une configuration facile grace a l'utilisation des outils de gestion des packages de FreeBSD, supporte de multiples cartes vidéos et est distribué en forme binaire seulement, par FTP. N'oublions pas de mentionner que Metro Link offre se serveur a un prix raisonnable de 39$. Metro Link vend aussi une version ELF et a.out de Motif (voir ci-dessus). [.programlisting] .... Pour plus d'informations Serveur WWW de Metro Link Ou les addresse de messageries du département des ventes ou encore du support Tél: (954) 938-0283 or +1 954 938-0283 .... http://www.xig.com[ Xi Graphics] offre un serveur X haute performances comportant une facilité de configuration et supportant des cartes vidéos multiples. La distribution est sous forme binaire, et est au format disquette pour FreeBSD et Linux. Xi Graphics offre aussi un serveur haute performances pour les portables. Il y a une "démo de compatibilité" disponible et gratuite de la version 5.0. Xi Graphics vends aussi Motif et CDE pour FreeBSD (voir ci-dessus). [.programlisting] .... Pour plus d'informations : Xi Graphics WWW page ou par courrier électronique aux adresses suivantes : Ventes ou Support ou encore par téléphone au (800) 946 7433 ou +1 303 298-7478. .... === Y a-t-il un système de bases de données pour FreeBSD? Oui ! Conetic Software Systems a porté leur système de bases de données C/base and C/books pour FreeBSD 2.0.5 et plus, et Sleepycat Software vend une version commerciale supportée de leur librairie de base de données DB. Pour plus d'informations : http://www.conetic.com/[ Conetic Software Systems ] ou envoyez un courrier électronique à link:mailto:info@conetic.com[ Information E-mail address ] et http://www.sleepycat.com/[ Sleepycat Software ] == Applications. **Mise à jour en cours** === Ou puis-je trouver toutes les applications utilisateurs? Allez voir sur la link:{handbook}#ports/[ page des ports] pour plus d'informations sur les packages portés sur FreeBSD. La liste complète inclut plus de 1000 ports, et grossit chaque jours, donc vérifiez souvent cette liste, ou souscrivez à la mailing liste link:freebsd-announce[ freebsd-announce ] pour vous tenir au courant des mises à jour. La plupart des ports sont disponibles pour la branche 2.2 et 3.0, et la plupart d'entre eux sont susceptibles de fonctionner sur des systèmes 2.1.x. A chaque fois qu'une version de FreeBSD est livrée, une version des ports, au moment de la livraison de la version, est incluse dans le répertoire [.filename]#ports#. FreeBSD supporte aussi le concept de package, qui n'est rien de plus qu'une distribution binaire compressée avec quelques informations en plus, permettant de l'installer très simplement. Un package peut être installé et désinstallé facilement, sans avoir besoin de savoir les détails sur les fichiers qu'il inclut. Il vous suffit d'utiliser le menu d'installation des package du programme [.filename]#/stand/sysinstall# ou servez vous de la commande __pkg_add(1)__ pour installer les packages que vous désirez. Les fichiers des packages sont très simple à identifiés de part leur suffixe _.tgz_. Les personnes disposant d'une distribution sur CDROM les trouveront dans le répertoire [.filename]#packages/All#. Ils sont aussi disponibles sur ces différents serveurs ftp: * Pour les versions 2.1.x-release: link:ftp://ftp.FreeBSD.ORG/pub/FreeBSD/packages-2.1.7/[ftp://ftp.FreeBSD.ORG/pub/FreeBSD/packages-2.1.7/] * Pour les versions 2.2.6-release/2.2.-stable: link:ftp://ftp.FreeBSD.ORG/pub/FreeBSD/packages-2.2.6/[ftp://ftp.FreeBSD.ORG/pub/FreeBSD/packages-2.2.6/] * Pour la version 3.0-current: link:ftp://ftp.FreeBSD.ORG/pub/FreeBSD/packages-3.0/[ftp://ftp.FreeBSD.ORG/pub/FreeBSD/packages-3.0/] ou sur un site mirroir. Notez, que tous les ports ne sont pas obligatoirement disponibles sous forme de package. C'est une bonne idée de vérifier régulièrement la disponibilité des différents packages sur le link:ftp://ftp.freebsd.org/pub/FreeBSD/[site principal de FreeBSD] === Ou trouver la librairie libc.so.3.0? Cela veut dire que vous essayez d'utiliser un package compilé pour des versions 2.2/3.0 sur un système 2.1.x. Voyez la section précedente et retrouvez le port/package correct pour votre système. [[emul]] === ghostscript m'affiche énormément d'erreurs sur mon 386/486SX. Vous n'avez pas de coprocesseur mathématique, n'est-ce pas ? Vous devez absolument compiler l'émulateur mathématique fournit dans votre noyau; il vous suffit d'ajouter la ligne suivante dans votre fichier de configuration du noyau: [.programlisting] .... options GPL_MATH_EMULATE .... NOTE: Vous devez retirer la ligne contenant l'option [.filename]#MATH_EMULATE# si vous activez la précédente. === Lorsque je lance des applications SCO/iBCS2, elles plantent sur [.filename]#socksys# Vous devez en tout premier éditer le fichier [.filename]#/etc/sysconfig# (ou http://www.freebsd.org/cgi/man.cgi?rc.conf(5)[ /etc/rc.conf ]) et positionner la variable suivante sur _YES_: [.programlisting] .... # à positionner sur YES si vous voulez que l'émulation ibcs2(SCO) soit chargée au démarrage ibcs2=NO .... Cela activera le module http://www.freebsd.org/cgi/man.cgi?ibcs2[ ibcs2 ] au démarrage. Vous devrez aussi créer le répertoire [.filename]#/compat/ibcs2/dev# et mettre en place ce qui suit : [.programlisting] .... lrwxr-xr-x 1 root wheel 9 Oct 15 22:20 X0R@ -> /dev/null lrwxr-xr-x 1 root wheel 7 Oct 15 22:20 nfsd@ -> socksys -rw-rw-r-- 1 root wheel 0 Oct 28 12:02 null lrwxr-xr-x 1 root wheel 9 Oct 15 22:20 socksys@ -> /dev/null crw-rw-rw- 1 root wheel 41, 1 Oct 15 22:14 spx .... Il suffit de faire pointer socksys vers http://www.freebsd.org/cgi/man.cgi?null(4)[ /dev/null ] pour tromper les open & close. Le code, dans la version -current, fera le reste. Si vous avez besoin du driver [.filename]#spx# pour la connexion d'une socket X, définissez [.filename]#SPX_HACK# lors de la compilation de votre système. === Comment dois-je configurer INN (Internet News) pour mon système ? Après avoir installé le package ou le port de inn, la meilleur façon de commencer est de voir la page de http://www.eerie.fr/~news/[Fabien TASSIN] sur INN, ou vous trouverez la FAQ de INN. === Quelle version de Microsoft FrontPage dois-je utiliser ? Utilisez les ports ! Une pré-version patchée pour Apache est disponible dans les ports == Configuration du noyau. **Mise à jour en cours** === J'aimerais personnaliser mon noyau. Est-ce difficile ? Pas du tout ! Jetez un coup d'oeil à link:{handbook}#kernelconfig/[ la section de la configuration du noyau du manuel de référence. ] NOTE : Je vous recommande de faire une sauvegarde datée de votre noyau dans [.filename]#kernel.YYMMDD# dès que vous arrivez à tout faire marcher. Ainsi, si jamais en jouant avec votre configuration du noyau, vous mélangez tout, vous pourrez démarrer sur ce noyau plutôt que de repartir depuis [.filename]#kernel.GENERIC#. Ceci est particulièrement important si vous démarrez actuellement depuis un contrôleur qui n'est pas supporté par le noyau GENERIC (oui, c'est une expérience personelle). === Ma compilation du noyau échoue car [.filename]#&hw&float# manque. Laissez-moi deviner. Vous avez supprimé http://www.freebsd.org/cgi/man.cgi?npx(4)[ npx0 ] de votre fichier de configuration du noyau car vous n'avez pas de coprocesseur arithmétique, c'est ça ? Faux ! :-). Le périphérique [.filename]#npx0# est *OBLIGATOIRE*. Même si vous n'avez pas de coprocesseur arithmétique, vous *devez* inclure le périphérique [.filename]#npx0#. === Conflits d'interruption avec le code multi-port série. [qanda] Quand je compile le noyau avec du code multi-port série, cela me dit que seul le premier port est examiné et le reste est ignoré à cause des conflits d'interruption. Comment puis-je résoudre cela ?:: Le problème ici, est que FreeBSD a du code intégré pour éviter au noyau de se planter à cause d'un conflit matériel ou logiciel. La façon de fixer ce problème est d'ignorer le réglage des IRQ sur tous les ports sauf un. Voici un exemple : [.programlisting] .... # # Multiport high-speed serial line - 16550 UARTS # device sio2 at isa? port 0x2a0 tty irq 5 flags 0x501 vector siointr device sio3 at isa? port 0x2a8 tty flags 0x501 vector siointr device sio4 at isa? port 0x2b0 tty flags 0x501 vector siointr device sio5 at isa? port 0x2b8 tty flags 0x501 vector siointr .... === Comment puis-je activer le support des disques QIC-40/80 ? Vous supprimez le commentaire de la ligne suivante du fichier générique de configuration (ou ajoutez la à votre fichier de configuration), ajoutez un [.filename]#flags 0x1# à la ligne http://www.freebsd.org/cgi/man.cgi?fdc(4)[ fdc ] et recompilez. [.programlisting] .... controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 flags 0x1 vector fdintr disk fd0 at fdc0 drive 0 ^^^^^^^^^ disk fd1 at fdc0 drive 1 #tape ft0 at fdc0 drive 2 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .... Puis, vous créez un périphérique appelé [.filename]#/dev/ft0# en allant dans le répertoire [.filename]#/dev# et en lançant la commande suivante : [.programlisting] .... sh ./MAKEDEV ft0 .... pour le premier périphérique. [.filename]#ft1# pour le second, et ainsi de suite. Vous aurez un périphérique appelé [.filename]#/dev/ft0#, où vous pourrez écrire par l'intermédiaire d'un programme spécial appelé [.filename]#ft# - Voir la page de manuel http://www.freebsd.org/cgi/man.cgi?ft[ ft ] pour plus de détails. Les versions précédentes de [.filename]#-current# ont aussi quelques problèmes avec certaines cartouche ddfectueuses. Si vous avez des problèmes où [.filename]#ft# semble aller et venir indéfiniment, essayez de récupérer la dernière version de [.filename]#ft# depuis [.filename]#/usr/src/sbin/ft# dans [.filename]#-current# et essayez le. == Administration système. **Mise à jour en cours** === Où sont les fichiers de démarrage du système ? De la version 2.0.5R à la version 2.2.1R, le fichier de configuration principal était [.filename]#/etc/sysconfig#. Toutes les options sont spécifiées dans ce fichier et les autres fichiers comme http://www.freebsd.org/cgi/man.cgi?rc[ /etc/rc ] et [.filename]#/etc/netstart# ne font que l'inclure. Regardez dans le fichier [.filename]#/etc/sysconfig# et changez les valeurs nécessaires pour configurer votre système. Ce fichier inclut des commentaires indiquant les valeurs à mettre. Pour les versions 2.2.1 et suivantes, le fichier [.filename]#/etc/sysconfig# a été renommé en http://www.freebsd.org/cgi/man.cgi?rc.conf(5)[ rc.conf ] et a été épuré au passage. Le fichier [.filename]#/etc/netstart# a aussi été renommé en [.filename]#rc/network# comme cela tous les fichiers peuvent être copiés grâce à une seule commande : http://www.freebsd.org/cgi/man.cgi?cp[ cp ] [.filename]#/usr/src/etc/rc* /etc#. Le fichier [.filename]#/etc/rc.local# existe toujours et peut être utilisé pour démarrer des services additionnels comme http://www.freebsd.org/cgi/ports.cgi?^inn[INN] ou pour positionner certaines valeurs. Le fichier [.filename]#/etc/rc.serial# permet d'initialiser les ports série (par exemple mettre en place les caractéristiques du port, etc..). Le fichier [.filename]#/etc/rc.i386# est spécifique aux paramètres des plateformes Intel, comme l'émulation iBCS2 ou la configuration de la console système d'un PC. Avec la version 2.1.0R, vous pouvez définir des fichiers de démarrage "locaux" se trouvant dans un répertoire spécifié dans le fichier [.filename]#/etc/sysconfig# (ou le fichier [.filename]#/etc/rc.conf#): [.programlisting] .... # Emplacement des fichiers de démarrage locaux local_startup=/usr/local/etc/rc.local.d .... Chaque fichier se terminant par [.filename]#.sh# sera éxécuté dans l'ordre alphabétique. Si vous voulez vous assurez d'un certain ordre de démarrage sans changer le nom des fichiers, vous pouvez utiliser un schéma similaire à celui qui suit, en faisant précéder chaque fichier de chiffres pour assurer l'ordre de démarrage: [.programlisting] .... 10news.sh 15httpd.sh 20ssh.sh .... Cela peut vous sembler un peu laid (ou SysV :-)) mais cela fournit une façon simple pour les packages locaux ajoutés sans être obligé d'éditer [.filename]#/etc/rc.local#. La plupart des ports ou des packages assument que le répertoire [.filename]#/usr/local/etc/rc.d# permet le démarrage des programmes locaux. === Comment ajouter simplement un utilisateur ? Utilisez la commande http://www.freebsd.org/cgi/man.cgi?adduser[ adduser ] Il existe aussi un autre outil nommé [.filename]#new-account# écrit en Perl par link:mailto:roberto@FreeBSD.ORG[Ollivier Robert]. Demandez le lui. Cet outil est actuellement en cours de développements supplémentaires Pour retirer un utilisateur, utilisez la commande http://www.freebsd.org/cgi/man.cgi?rmuser[rmuser]. === Comment ajouter un nouveau disque dur à mon système FreeBSD ? Voyez le link:/articles/diskformat/[tutoriel] sur le formatage des disques dur. === Comment utiliser mon nouveau disque amovible ? Que ce soit un disque amovible de type ZIP ou EZ (ou même une disquette), ou un disque dur, une fois installé et reconnu par le système et que vous avez inséré une cartouche/disquette, la manipulation est la même pour tous les périphériques. [[disklabel]](Cette section est basée sur http://www.vmunix.com/mark/FreeBSD/ZIP-FAQ.html[la FAQ ] des lecteurs ZIP de Mark Mayo) Si c'est un disque ZIP ou une disquette DOS, il y a déjà un système de fichier DOS installé, vous pouvez utilisez les commandes suivantes: [.programlisting] .... mount -t msdos /dev/fd0c /floppy .... s'il s'agit d'une disquette; ou: [.programlisting] .... mount -r msdos /dev/sd2s4 /zip .... s'il s'agit d'un lecteur ZIP dans sa configuration d'origine. Pour les autres types de disques, voyez leur partitionnement en utilisant [.filename]#fdisk# ou [.filename]#/stand/sysinstall#. Les exemples qui suivent supposent que vous disposez d'un disque ZIP sur sd2, le troisième disque SCSI. Si votre disque amovible n'est pas une disquette, ou tout autre disque amovible que vous ne désirez par partager avec d'autres personnes, il vaut mieux mettre un système de fichiers BSD dessus. Vous pourrez avoir des noms longs, une amélioration de performances et une meilleur stabilité. Pour commencer, vous devez effacer la partition ou le système de fichiers DOS. Vous pouvez utiliser l'utilitaire http://www.freebsd.org/cgi/man.cgi?fdisk[ fdisk ] ou [.filename]#/stand/sysinstall#, ou pour un disque d'une petite capacité, détruire la table des partitions FAT et utiliser le partitionnement BSD standard : [.programlisting] .... dd if=/dev/zero of=/dev/rsd2 count=2 disklabel -Brw sd2 auto .... Vous pouvez utiliser disklabel ou [.filename]#/stand/sysinstall# pour créer plusieurs partitions BSD. Vous effectuerez probablement ces opérations si vous ajoutez de l'espace de "swap" sur un disque fixe, mais il est inconcevable de le faire sur un disque amovible ZIP. Pour finir construisez un nouveau système de fichier, utilisant tout l'espace disponible sur votre lecteur ZIP : [.programlisting] .... newfs /dev/rsd2c .... et montez le : [.programlisting] .... mount /dev/sd2c /zip .... C'est surement une bonne idée d'ajouter la ligne suivante au fichier http://www.freebsd.org/cgi/man.cgi?fstab[ /etc/fstab ], cela vous permettra de ne taper que "mount /zip" par la suite : [.programlisting] .... /dev/sd2c /zip ffs rw,noauto 0 0 .... === Comment monter une partition DOS étendue ? Les partitions DOS étendues se trouvent après la fin de toutes les partitions primaires. Par exemple, si vous avez une partition "E" en tant que partition DOS étendue sur le deuxième disque SCSI, vous devez créer le fichier spécial pour la partition 5 dans /dev et monter /dev/sd1s5 : [.programlisting] .... # cd /dev # ./MAKEDEV sd1s5 # mount -t msdos /dev/sd1s5 /dos/e .... === Puis-je monter d'autres systèmes de fichiers sous FreeBSD ? Les CDROM _Digital UNIX_ au format UFS peuvent être montés directements sous FreeBSD. Il peut être très difficile, par contre, de monter des partitions disques de Digital UNIX, ou d'autres systèmes supportant l'UFS. Cela dépend des partitionnements effectués sur le système en question. _Linux:_ Les version 2.2 et supérieures incluent le support des partitions _ext2fs_. Pour plus d'informations voyez la page de manuel de http://www.freebsd.org/cgi/man.cgi?mount_ext2fs[ mount_ext2fs ]. Toute autre information sur le sujet est appréciée. === Comment utiliser le programme de démarrage de NT pour démarrer FreeBSD ? Il faut pour cela copier le premier secteur de votre partition FreeBSD dans un fichier sur une partition DOS/NT. Nous supposerons qu'il s'appelle [.filename]#c:>bootsect.bsd# (équivalent de [.filename]#c:>bootsect.dos#). Il suffit d'éditer le fichier [.filename]#c:>boot.ini# pour qu'il ressemble à ceci: [.programlisting] .... [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows NT" C:\BOOTSECT.BSD="FreeBSD" C:\="DOS" .... Cette procédure implique que DOS, NT ou FreeBSD soient installés sur le même disque. Dans mon cas DOS et NT sont installés respectivement sur la première partition du disque et FreeBSD sur la seconde. FreeBSD est aussi configuré pour démarrer depuis sa partition et _non_ depuis le MBR du disque. Monter une disquette préformatée DOS (si vous cette partition n'est pas en FAT, mais en NTFS) sous [.filename]#/mnt#. [.programlisting] .... dd if=/dev/rsd0a of=/mnt/bootsect.bsd bs=512 count=1 .... Redémarrez en mode DOS ou NT. Si vous avez une partition NTFS copiez le fichier [.filename]#bootsect.bsd# de la disquette dans le répertoire C:>. Modifiez les attributs (permissions) du fichier boot.ini. [.programlisting] .... attrib -s -r c:\boot.ini .... Ajoutez la ligne correcte au fichier boot.ini et restaurez les anciens attributs. [.programlisting] .... attrib -s -r c:\boot.ini .... Si FreeBSD démarre depuis le MBR, restaurez-le avec la commande DOS [.filename]#fdisk /MBR# après avoir reconfiguré FreeBSD pour démarrer depuis sa partition native. === Comment démarrer FreeBSD et Linux grace à LILO ? Si vous avez installé FreeBSD et Linux sur le mème disque, suivez les instructions du manuel de LILO pour démarrer sur d'autres systèmes que Linux. En résumé il faut : Démarrer sous Linux et ajouter les lignes suivantes au fichier [.filename]#/etc/lilo.conf#: [.programlisting] .... other=/dev/hda2 table=/deb/hda label=FreeBSD .... (l'exemple précédant suppose que la partition FreeBSD est connue par linux sous le nom [.filename]#/dev/hda2#. Ensuite lancez [.filename]#lilo# sous root, et c'est fini. Si FreeBSD se trouve sur un autre disque vous devez ajouter [.filename]#loader=/boot/chain.b# au fichier de configuration de lilo : [.programlisting] .... other=/dev/sdb4 table=/dev/sdb loader=/boot/chain.b label=FreeBSD .... Dans certains cas, vous devez spécifier le numéro du disque connu par le BIOS au programme de démarrage de FreeBSD pour démarrer sur le deuxième disque. Par exemple, si votre disque SCSI contenant FreeBSD est trouvé par le BIOS comme disque numéro 1, vous devez taper la ligne suivante au prompt du programme de démarrage: [.programlisting] .... Boot: 1:sd(0,a)/kernel .... Vous pouvez configurer le http://www.freebsd.org/cgi/man.cgi?boot(8)[ programme de démarrage ] de FreeBSD version 2.2.5 ou supérieure pour prendre cette chaine par défaut. Le document http://sunsite.unc.edu/LDP/HOWTO/mini/Linux+FreeBSD.html[Linux+FreeBSD mini-HOWTO] est une très bonne référence sur l'interopérabilité entre FreeBSD et Linux. === Comment démarrer FreeBSD et Linux depuis BootEasy ? Il faut installer LILO au début de votre partition de démarrage de Linux au lieu du MBR. Vous pouvez alors démarrer LILO depuis BootEasy. Si vous utilisez Linux et Windows-95, c'est la meilleur façon d'installer LILO si vous voulez continuer à démarrer Linux après avoir réinstallé Windows-95 (qui lui ne tient pas contre des autres systèmes et se croit seul sur le MBR). === Est-ce dangereux d'utiliser un disque dédié ? La procédure d'installation vous permet de choisir deux façons différentes pour partitionner vos disques. Par défaut, elle permet de les rendre compatibles avec d'autres systèmes d'exploitation se trouvant sur votre ordinateur en utilisant les entrées des tables de fdisk (appelés "slices" sous FreeBSD), en faisant en sorte qu'une "slice" FreeBSD corresponde à une partition. Vous pouvez aussi installer un selecteur de démarrage pour choisir de démarrer sous un autre système d'exploitation. Comme ceci correspond à la plupart des cas de personnes venant des PC, les personnes venant d'Unix et qui désirent mettre en place une machine pour y faire tourner FreeBSD et juste FreeBSD, utilisent la procédure classique d'installation d'Unix, ou Unix utilise le disque au complet, du premier secteur au dernier. Une véritable table pour fdisk n'est d'aucune utilité dans le vas d'une machine utilisant FreeBSD 24h/24, 7jours sur 7, car aucun autre système d'exploitation ne sera démarré. Donc si vous sélectionnez A)ll FreeBSD dans l'éditeur de partition du programme d'installation et répondez No à la question qui suit, vous serez dans ce cas. Notez que cela implique que le programme de démarrage BSD correspond au MBR de ce disque. N'essayez pas d'en réinstaller un sous peine de détruire le précédent. Donc pourquoi est-ce donc dangereux? Un disque configuré de la sorte ne contient pas de table fdisk valides, pour la plupart des utilitaires PC. Suivant la façon dont ils ont été conçus, ils vous avertissent ou tout simplement ne disent rien et détruisent le programme de démarrage BSD sans avertissement. Certains systèmes d'exploitation très utilisés sur PC, sont connus pour agir de la sorte (bien sûr, ils agissent de la sorte sous le couvert de système "orienté-utilisateur"). Au moins un BIOS de chez Award, qui est par exemple utilisé sur les HP Netserver (mais sur d'autre systèmes aussi), est connu pour ignorer tout disque dur n'ayant pas de table fdisk valide. Lorsque votre machine démarre il ignore tout simplement de tels disques, tente de démarrer sur une disquette, et vous affiche un Read error. Très impressionnant, non ?. C'est ce que certains appellent un système "orienté-utilisateur". Les avantages de ce partitionnement sont : FreeBSD utilise le disque au complet, il n'y a donc pas de besoin de garder quelques 'pistes' au début du disque qui ne servaient à rien sauf pour un modèle de partitionnement vieux et simpliste qui n'a maintenant plus aucun sens. Ces contraintes étant ce que l'on peut appeler la plus grosse prise de tête lors de l'installation des systèmes d'exploitations sur PS, et qui menaient le plus souvent à deux façon complètement redondantes de stockage des informations dans les tables fdisk. Voyez le chapitre sur <>. Dans le cas d'un disque dangereusement dédié, le programme de démarrage BSD commence au secteur 0, qui est le seul secteur ne changeant de valeur C/H/S, pour les valeurs du disque du BIOS. Vous pouvez donc, dans ce cas, interchanger des disques entre plusieurs controleurs ou systèmes utilisant des schémas de translation différents sans vous poser de questions. Pour passer d'un disque dangereusement dédié à un disque normal de PC, il y a deux solutions simples. La première est de recouvrir le MBR d'octets vides, pour permettre de faire croire que le disque est vierge. Pour pouvez le faire de la façon suivante: [.programlisting] .... dd if=/dev/zero of=/dev/rds0 count=15 .... Ou en utilisant une fonctionnnalité non-documentée de DOS : [.programlisting] .... fdisk /mbr .... qui installe aussi un nouveau MBR, en recouvrant le programme de démarrage BSD. === Comme faire pour ajouter plus de "swap" ? La meilleur façon de faire, est d'augmenter la taille de votre partition de swap, ou de prendre cette excuse pour ajouter un autre disque. Ajouter du "swap" sur un autre disque permet plus d'augmenter la rapidité que d'en ajouter sur le même disque. Par exemple, si vous compilez des fichiers qui se trouvent sur un disque et que le "swap" se trouve sur un autre disque, cela va beaucoup plus vite d'avoir le "swap" et les sources sur le même disque. Ceci est spécialement vrai pour les disques SCSI. Les disques IDE ne permettent pas l'accès à deux disques sur le même canal au même moment (FreeBSD ne supporte pas le mode 4, donc toutes les entrées/sorties disques sont programmées). Je vous suggère de mettre le "swap" sur un autre disque aussi. Les disques durs sont si peu couteux, que cela ne vaut pas le coup de tout mettre sur un. C'est une très mauvaise idée de mettre le fichier de "swap" sur une partition NFS, sauf si vous disposez d'un environnement réseau extrèmement rapide, et d'un très bon serveur NFS. Voici un exemple pour ajouter 64Mo de swap en utilisant un fichier se nommant [.filename]#/usr/swap0#. Assurez vous que votre noyau est compilé avec la ligne [.programlisting] .... pseudo-device vn 1 # #Vnode driver (turns a file into a device) .... Le noyau GENERIC la contient par défaut. * Créez un vn-device : + [.programlisting] .... cd /dev sh./MAKEDEV vn0 .... * Créez le fichier de "swap" ([.filename]#/usr/swap0#). + [.programlisting] .... dd if=/dev/zero of=/usr/swap0 bs=1024k count=64 .... * Activez le fichier de "swap" dans le fichier [.filename]#/etc/rc.conf# + [.programlisting] .... swapfile="/usr/swap0" # Set to name of swapfile if aux swapfile desired. .... * Rebootez la machine Pour activer le fichier de "swap" immédiatement, tapez [.programlisting] .... vnconfig -ce /dev/vn0c /usr/swap0 swap .... === J'ai des problèmes pour installer mon imprimante. Référez-vous à la section sur les link:{handbook}#printing/[imprimantes du Handbook]. Elle couvre l'essentiel des problèmes que l'on peut rencontrer. === Le clavier est mal configuré sur mon ordinateur. Le programme [.filename]#kbdcontrol# comporte une option permettant de charger une configuration clavier différente. Vous trouverez dans [.filename]#/usr/shared/syscons/keymaps# différents fichiers de configuration. Choisissez celle voulue et chargez la : [.programlisting] .... kbdcontrol -l fr.iso .... Dans tous les cas le programme http://www.freebsd.org/cgi/man.cgi?kbdcontrol[kbdcontrol] recherche dans [.filename]#/usr/shared/syscons/keymaps# un fichier se terminant par [.filename]#.kbd#. Vous pouvez le configurer dans le fichier [.filename]#/etc/sysconfig# (ou http://www.freebsd.org/cgi/man.cgi?rc.conf(5)[rc.conf]). Regardez les commentaires apropriés dans ce fichier. Pour les versions 2.0.5 et suivantes, tout ce qui est relatif aux fontes du texte, à la configuration du clavier se trouve dans [.filename]#/usr/shared/syscons#. Actuellement les configurations de claviers suivantes sont supportées : * Belgian ISO-8859-1 * Brazilian 275 keyboard Codepage 850 * Brazilian 275 keyboard ISO-8859-1 * Danish Codepage 865 * Danish ISO-8859-1 * French ISO-8859-1 * German Codepage 850 * German ISO-8859-1 * Italian ISO-8859-1 * Japanese 106 * Japanese 106x * Latin American * Norwegian ISO-8859-1 * Polish ISO-8859-2 (programmer's) * Russian Codepage 866 (alternative) * Russian utf-8 (shift) * Russian utf-8 * Spanish ISO-8859-1 * Swedish Codepage 850 * Swedish ISO-8859-1 * Swiss-German ISO-8859-1 * United Kingdom Codepage 850 * United Kingdom ISO-8859-1 * United States of America ISO-8859-1 * United States of America dvorak * United States of America dvorakx === Comment faire en sorte que les quotas utilisateurs fonctionnent correctement ? * Ne mettez pas de quotas sur '/', * Mettez le fichier des quotas sur le système de fichiers qui en dispose, par ex : + [.programlisting] .... Système de fichier Emplacement du fichier des quotas /usr /usr/admin/quotas /home /home/admin/quotas ... .... === Qu'est-ce qui ne va pas avec ma configuration de ccd ? Le symptome est le suivant : [.programlisting] .... # ccdconfig -C ccdconfig: ioctl (CCDIOCSET): /dev/ccd0c: Inappropriate file type or format # .... Ceci apparait la plupart du temps lorsque vous essayez de concaténer les partitions `c`, qui par défaut ont comme type `unused`. Le gestionnaire de disque ccd nécessite que le type de la partition soit de type FS_BSDFFS. Dans ce cas, éditez le label des disques à concaténer et changez le type des partitions en type 4.2BSD. === Pourquoi je ne peux pas éditer le label de mes disques concaténés ? Le symptome est le suivant : [.programlisting] .... # disklabel ccd0 (ça affiche quelque chose de particulier ici, donc essayons de l'éditer) # disklabel -e ccd0 (édition, sauvegarde, sortie) disklabel: ioctl DIOCWDINFO: No disk label on disk; use "disklabel -r" to install initial label # .... Cela apparait souvent lorsque le label retourné par le gestionnaire de disques concaténé est un faux, un qui n'est pas véritablement sur le disque. Pour résoudre ce problème il faut écrire explicitement sur le disque, comme ceci : [.programlisting] .... # disklabel ccd0 > /tmp/disklabel.tmp # disklabel -Rr ccd0 /tmp/disklabel.tmp # disklabel -e ccd0 (maintenant cela doit fonctionner correctement) .... === Est-ce que FreeBSD supporte les communications inter-processus de type Système V (IPC) ? Oui, FreeBSD supporte les communications inter-processus de type Système V, IPC. Cela inclue la mémoire partagée, les files de messages et les sémaphores. Vous devez ajouter les lignes suivantes à votre fichier de configuration du noyau pour les activer : [.programlisting] .... options SYSVSHM options "SHMMAXPGS=64" # 256Ko de mémoire partagée options SYSVSEM # activation des sémaphores options SYSVMSG # activation des files de messages .... Recompilez le noyau et installez le. _Note :_ Vous aurez sûrement besoin d'augmenter SHMMAXPGS à un nombre plus élevé, comme 4096 (16M!) si vous avez besoin d'utiliser GIMP. 256Ko est largement suffisant pour la mémoire partagée dont à besoin X11R6. === Comment configurer sendmail pour fonctionner avec UUCP ? La configuration de sendmail fournie avec FreeBSD, correspond à un site directement connecté à l'Internet. Les sites qui utilisent UUCP pour échanger du courrier électronique doivent installer un autre fichier de configuration pour sendmail. Modifier directement le fichier [.filename]#/etc/sendmail.cf# est réservé la plupart du temps aux gourous. La version 8 de sendmail dispose d'une interface http://www.freebsd.org/cgi/man.cgi?m4[m4] de génération du fichier de configuration, qui encapsule le fichier de configuration dans un format abstrait de haut niveau. Vous devez trouvez les différents fichiers de configuration dans le répertoire [.filename]#usr/src/usr.sbin/sendmail/cf#. Si vous n'avez pas installé tous les sources du système, vous pouvez trouver les différents fichiers de configuration de sendmail dans un fichier séparé des autres sources sur le CD-ROM. Si vous avez monté le CD-ROM exécutez les commandes suivantes : [.programlisting] .... cd /usr/src tar -xvzf /cdrom/dists/src/ssmailcf.aa .... Cela correspond juste à une centaine de kilo-octets. Le fichier [.filename]#README# dans le répertoire [.filename]#cf# vous explique rapidement comment fonctionnne m4. Pour utiliser UUCP, vous devez utiliser la fonctionnnalité _mailertable_. Elle permet à sendmail de constituer une base de données pour lui permettre de router le courrier correctement. Pour commencer, vous devez créer une fichier de configuration [.filename]#.mc#. Tous ces types de fichiers se trouvent dans le répertoire [.filename]#/usr/src/usr.sbin/sendmail/cf/cf#. Il y a quelques fichiers d'exemples dans ce répertoire pouvant vous aider. En supposant que vous avez appelé ce fichier [.filename]#foo.mc#, tout ce que vous devez faire pour le convertir en un fichier valide de configuration de sendmail, [.filename]#sendmail.cf# est : [.programlisting] .... cd /usr/src/usr.sbin/sendmail/cf/cf make foo.cf cp foo.cf /etc/sendmail.cf .... Un fichier classique ressemble à ceci: [.programlisting] .... include(`../m4/cf.m4') VERSIONID(`Votre numéro de version) OSTYPE(bsd4.4) FEATURE(nodns) FEATURE(nocanonify) FEATURE(mailertable) define(`UUCP_RELAY', nom.du.relai.uucp) define(`UUCP_MAX_SIZE', 200000) MAILER(local) MAILER(smtp) MAILER(uucp) Cw alias.de.votre.nom.de.machine Cw votrenomdenoeuduucp.UUCP .... Les directives __nodns_et_nocanonify__ forcent sendmail à ne pas utiliser le DNS lors de l'envoi du courrier. La directive __UUCP_RELAY__ est utilisée pour des raisons assez bizarres; ne posez pas de questions et utilisez-la. Mettez juste un nom de machine capable de recevoir du courrier en UUCP. La plupart du temps il faut mettre le nom du serveur de messagerie de votre fournisseur d'accès. Après avoir défini tout ceci, vous avez besoin d'un fichier [.filename]#/etc/mailertable#. Voici un exemple de ce type de fichier : [.programlisting] .... # # makemap hash /etc/mailertable.db < /etc/mailertable # horus.interface-business.de uucp-dom:horus .interface-business.de uucp-dom:if-bus interface-business.de uucp-dom:if-bus .heep.sax.de smtp8:%1 horus.UUCP uucp-dom:horus if-bus.UUCP uucp-dom:if-bus . uucp-dom:sax .... Les trois premières lignes font en sorte d'envoyer le courrier à des serveurs UUCP voisins et non pas au serveur par défaut, pour permettre de racourcir le temps d'envoi des messages. La ligne suivante permet d'envoyer le courrier sur le domaine local en protocole SMTP. Et pour finir, les voisins UUCP sont mentionner dans la la notation de domaine .UUCP, permettant au format de mail voisin-uucp!destinataire d'écraser les règles par défaut. La dernière ligne doit toujours être un `.`, qui représente toutes les destinations, qui doit correspondre à un serveur de messagerie UUCP voisin, et qui sert de passerelle de courrier éléctronique vers le reste du monde. Tous les noms de noeuds se trouvant après le mot clé [.filename]#uucp-dom:# doivent être des noms valides de voisins UUCP, que vous pouvez vérifier en utilisant la commande [.filename]#uuname# Pour vous rappeler que ce fichier doit être converti en fichier DBM pour pouvoir être utilisé, la ligne de commande nécessaire à sa création est rappelée dans les commentaires du fichier mailertable. Vous devez lancer cette commande à chaque fois que vous changez quelque chose dans ce fichier. Pour finir : si vous n'etes pas certain de votre configuration d'envoi de messages électroniques, rappellez-vous l'option [.filename]#-bt# de sendmail. Cela lance sendmail en _mode test_ ; entrez simplement `0` suivi de l'adresse que vous voulez tester. La dernière ligne vous indiquera alors le type d'agent utilisé pour l'envoi, la machine auquelle l'agent enverra le courrier, et l'adresse à laquelle il l'enverra. Pour quitter ce mode tapez Control-D. [.programlisting] .... j@uriah 191% sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter
> 0 foo@interface-business.de rewrite: ruleset 0 input: foo @ interface-business . de ... rewrite: ruleset 0 returns: $# uucp-dom $@ if-bus $: foo \ < @ interface-business . de > > ^D j@uriah 192% .... === Comment mettre en oeuvre le courrier électronique avec une connexion temporaire à un réseau ? Si vous disposez d'un adresse IP statique, vous ne devez rien changer. Definissez juste votre nom de machine pour qu'il corresponde à votre nom de machine internet et sendmail s'occupera du reste. Dans le cas ou vous disposez d'une adresse IP dynamiquement assignée et que vous utilisez une connexion ppp pour accèder à l'internet, vous diposez probablement d'une boite aux lettres chez votre fournisseur d'accès. Prenons comme exemple que le domaine de votre fournisseur soit [.filename]#monISP.com#, que votre nom d'utilisateur soit [.filename]#monlogin#, que votre nom de machine soit [.filename]#bsd.perso# et que votre fournisseur vous aie indiqué la machine [.filename]#relai.monISP.com# comme serveur relai de messagerie électronique. Pour pouvoir recevoir votre courrier depuis votre boite à lettres, vous devez installer un agent de rapatriement de mail._Fetchmail_ est un bon choix, car il supporte la plupart des protocoles de messagerie. La plupart du temps, votre fournisseur offre l'accès à travers le protocole POP3. Si vous avez décidé d'utiliser la partie utilisateur de ppp, vous pouvez automatiquement rapatrier votre courrier lorsque la connexion vers le réseau est établie en ajoutant la ligne suivante au fichier [.filename]#/etc/ppp/ppp.linkup# : [.programlisting] .... MYADDR: !bg su monlogin -c fetchmail .... Ici nous assumons que vous disposez d'un compte nommé [.filename]#monlogin# sur la machine [.filename]#bsd.perso#. Vous devez alors créer un fichier [.filename]#.fetchmailrc# dans votre répertoire principal contenant : [.programlisting] .... poll monISP.com protocol pop3 fetchall pass monPasswd: .... Naturellement, ce fichier ne doit être lisible que par l'utilisateur [.filename]#monlogin# car il contient le mot de passe [.filename]#monPasswd#. Pour permettre d'envoyer du courrier avec l'entête _from:_ correcte, vous devez configurer sendmail pour utiliser l'adresse [.filename]#monlogin@monISP.com# plutôt que [.filename]#monlogin@bsd.perso#. Vous devez aussi dire à votre sendmail d'envoyer tout le courrier via le serveur [.filename]#relai.monISP.com#, permettant au courrier d'être envoyé plus rapidement. Le fichier de configuration [.filename]#.mc# suivant doit convenir : [.programlisting] .... VERSIONID(`bsd.perso.mc version 1.0') OSTYPE(bsd4.4)dnl FEATURE(nouucp)dnl MAILER(local)dnl MAILER(smtp)dnl Cwlocalhost Cwbsd.perso MASQUERADE_AS(`monISP.com')dnl FEATURE(allmasquerade)dnl FEATURE(masquerade_envelope)dnl FEATURE(nocanonify)dnl FEATURE(nodns)dnl define(SMART_HOST, `relai.monISP.com') Dmbsd.perso define(`confDOMAIN_NAME',`bsd.perso')dnl define(`confDELIVERY_MODE',`deferred')dnl .... Reférez-vous à la section précédente pour l'explication détaillée de conversion du fichier [.filename]#.mc# en fichier [.filename]#sendmail.cf#. N'oubliez pas non plus de redémarrer sendmail après avoir modifié le fichier [.filename]#/etc/sendmail.cf# === Horreur !! J'ai perdu le mot de passe de root !! Ne paniquez pas! Redémarrez tout simplement le système en tapant -s au "prompt" Boot: pour passer en mode mono-utilisateur. A la question sur le shell à utiliser, appuyez sur ENTREE. Vous obtiendrez alors un prompt "#". Tapez la commande [.filename]##mount -u## pour remonter votre partition primaire en lecture/écriture et lancez la commande [.filename]##mount -a## pour remonter tous les systèmes de fichiers. Tapez [.filename]##passwd root## pour changer le mot de passe root puis tapez [.filename]##exit## pour continuer le processus de démarrage du système. === Comment empècher le redémarrage du système en appuyant sur les touches Control-Alt-Delete ? Editez le fichier de configuration du clavier que vous utilisez pour la console et remplacez le mot clé [.filename]#boot# par [.filename]#nop#. Le fichier de configuration du clavier utilisé par défaut est [.filename]#/usr/shared/syscons/keymaps/us.iso.kbd#. Vous pouvez changer la configuration en éditant le fichier [.filename]#/etc/rc.conf#. Bien sur si vous utilisez une autre configuration, il faut éditer le fichier de configuration la décrivant. === Comment transformer les fichiers textes au format DOS en fichiers UNIX ? Utilisez tout simplement la commande perl suivante : [.programlisting] .... perl -i.bak -pe 's/\r\n/\n/g' fichier.dos ... .... fichier.dos étant le fichier à modifier. Cette commande remplace dans le fichier et sauvegarde l'ancien sous le nom [.filename]#fichier.dos.bak#. === Comment tuer un processus par son nom ? Utilisez link:/cgi/cvsweb.cgi/man.cgi?killall[killall(1)] === Pourquoi la commande [.filename]#su# me dit sans arrêt que je ne suis pas dans les ACL de root ? Cette erreur vient du système d'authentification distribué Kerberos. Ceci n'est pas un problème très grave. Un palliatif consiste à utiliser l'option "-k" de su ou de désinstaller Kerberos comme expliqué à la section suivante. === Comment désinstaller Kerberos ? Pour désinstaller Kerberos de votre système, vous devez réinstaller la distribution [.filename]#bin# depuis votre version de FreeBSD. Si vous disposez d'un CDROM, vous devez monter le cd (la plupart du temps dans /cdrom) et lancer : [.programlisting] .... cd /cdrom/bin ./install.sh .... === Comment ajouter des pseudo-terminaux au système ? Si vous avez un grand nombre de telnet, ssh, X, or screen users, vous risquez probablement de manquer de pseudo-terminaux. Voici comment en ajouter plusieurs : . Créer et installer un nouveau noyau avec la ligne + [.programlisting] .... pseudo-device pty 256 .... + dans le fichier de configuration. . Exécuter la commande : + [.programlisting] .... # cd /dev # ./MAKEDEV pty{1,2,3,4,5,6,7} .... + pour créer 256 device nodes pour les nouveaux terminaux. . Editer [.filename]#/etc/ttys# et jouter une ligne pour chacun des 256 terminaux. Elles doivent correspondre à la forme des entrées existantes. c'est à dire ressembler à : + [.programlisting] .... ttyqc none network .... + L'ordre des lettres de désignation est [.filename]#tty[pqrsPQRS][0-9a-v]#, en utilisant une expression régulière. . Démarrez le système avec le nouveau noyau et vous êtes prêts à travailler. == Le système X-Windows et les consoles virtuelles. **Mise à jour en cours** === Je veux lancer X, comment dois-je faire ? La manière la plus simple est de spécifier au moment de l'installation que l'on veut utiliser X. Puis, lire la documentation suivante sur l'outil http://www.freebsd.org/cgi/man.cgi?manpath=xfree86&query=xf86config[ xf86config ], qui vous aidera dans la configuration de XFree86(tm) pour vos cartes graphiques, souris etc... Vous pouvez aussi regarder du côté du serveur Xaccel qui est disponible pour un prix très raisonnable/ Voir la section sur http://www.freebsd.org/cgi/man.cgi?manpath=xig[ Xi Graphics ]pour plus de détails. [[x-and-moused]] === Pourquoi ma souris ne marche pas sous X ? Si vous utilisez syscons (le driver par défaut de la console), vous pouvez configurer FreeBSD de telle sorte qu'il puisse supporter un pointeur de souris sur chacun des écrans virtuels. Afin d'éviter des conflits avec X, les supports syscons un périphérique virtuel nommé [.filename]#/dev/sysmouse#. Tous les évènement liés à la souris sont écrit vers le périphérique sysmouse, en utilsant le protocole MouseSystems. Si vous voulez utiliser votre souris sur une console virtuelle ou plus, _et_ utiliser X, la configuration suivante est recommandée. [.programlisting] .... /etc/rc.conf: moused_type=ps/2 # or whatever your actual type is moused_port=/dev/psm0 # or whatever your real port is moused_flags= /etc/XF86Config Section Pointer Protocol "MouseSystems" Device "/dev/sysmouse" ..... .... Certaines personnes préfèrent utiliser ``[.filename]#/dev/mouse#'' sous X. Ppour le faire marcher, ``[.filename]#/dev/mouse#'' devrait être un lien symbolique pour http://www.freebsd.org/cgi/man.cgi?sysmouse[ /dev/sysmouse] [.programlisting] .... cd /dev rm -f mouse ln -s sysmouse mouse .... === les menus X Window et les boîtes de dialogue ne marchent pas bien! Essayez de désactiver la touche Num Lock. Si votre touche Num Lock est activée par défaut au moment du boot, vous pouvez ajouter la ligne suivante dans la section _Keyboard_ q du fichier [.filename]#XF86config#. [.programlisting] .... Let the server do the NumLock processing. This should only be required when using pre-R6 clients ServerNumLock .... === Qu'est ce qu'une console virtuelle, et comment puis-je en avoir plus ? En gros, les consoles virtuelles vous permettent d'avoir plusieurs sessions simultanées sur la même machine sans faire de trucs compliqués du genre monter un réseau, ou lancer X. Quand le système démarre, il vous affichera une invite de login sur le moniteur juste après avoir affiché les messages du boot. Vous pouvez taper votre login et votre mot de passe et commencer à travailler (ou à jouer !) sur la première console virtuelle. A un moment, vous voudrez probablement ouvrir une autre session, par exemple pour lire la documentation d'un programme que vous êtes en train d'exécuter, ou alors lire le courrier en attendant qu'un transfert FTP se termine. Fais juste Alt-F2 (Appuyez en maintenant la touche Alt puis, pressez F2), et vous trouverez une invite de login vous attendant sur la seconde console virtuelle! Quand vous voudrez revenir à la session de départ, faites Alt-F1. L'installation par défaut de FreeBSD a 3 consoles virtuelles activées, et Alt-F1, Alt-F2, et d Alt-F3 vous permettra de basculer entre ces consoles virtuelles. Pour en activer plus, éditez http://www.freebsd.org/cgi/man.cgi?ttys[/etc/ttys] et ajoutez les entrées pour [.filename]#ttyv4# à _ttyvc_ après les commentaires sur les terminaux virtuels: [.programlisting] .... Edit the existing entry for ttyv3 in /etc/ttys and change "off" to "on". ttyv3 "/usr/libexec/getty Pc" cons25 on secure ttyv4 "/usr/libexec/getty Pc" cons25 on secure ttyv5 "/usr/libexec/getty Pc" cons25 on secure ttyv6 "/usr/libexec/getty Pc" cons25 on secure ttyv7 "/usr/libexec/getty Pc" cons25 on secure ttyv8 "/usr/libexec/getty Pc" cons25 on secure ttyv9 "/usr/libexec/getty Pc" cons25 on secure ttyva "/usr/libexec/getty Pc" cons25 on secure ttyvb "/usr/libexec/getty Pc" cons25 on secure .... Utilisez en autant que vous voulez/ Mais plus vous avez de terminaux virtuels, plus vous utilisez de ressources; cela peut-être important si vous avez 8Mo de RAM ou moins. Vous pouvez aussi changer [.filename]#secure# to [.filename]#insecure#. _NOTE IMPORTANTE_ si vous voulez lancer un serveur X, vous _DEVEZ_ avoir au moins un terminal virtuel non utilisé (ou désactivé)afin qu'il puisse l'utiliser. Tout cela pour dire que si vous voulez une invite de prompt pour les tous les 12 de vos touches Alt-fonctions, pas de chance, vous pourrez le faire que pour 11 d'entre eux si vous voulez aussi lancer un serveur X sur cette machine. La meilleure façon de désactiver une console est de la déselectionner. Par exemple, si vous avez alloué tous les 12 terminaux mentionné ci-dessus, et que vous voulez lancer X, vous aurez à changer le réglage pour le terminal virtuel 12 de : [.programlisting] .... ttyvb "/usr/libexec/getty Pc" cons25 on secure .... à: [.programlisting] .... ttyvb "/usr/libexec/getty Pc" cons25 off secure .... Si votre clavier n'a que 10 touches de fonctions, vous pouvez terminer par : [.programlisting] .... ttyv9 "/usr/libexec/getty Pc" cons25 off secure ttyva "/usr/libexec/getty Pc" cons25 off secure ttyvb "/usr/libexec/getty Pc" cons25 off secure .... (Vous pouvez aussi juste effacer ces lignes) Une fois que vous avez édité http://www.freebsd.org/cgi/man.cgi?ttys[ /etc/ttys" ], l'étape suivante est de s'assurer que vous avez assez de périphériques de terminaux virtuels. La plus simple manière de procéder est : [.programlisting] .... cd /dev ./MAKEDEV vty12 # For 12 devices .... Ensuite, la plus simple (et plus propre) manière d'activer la console virtuelle est de rebooter. Malgrè tout, si vous voulez vraiment ne pas avoir è rebooter, vous pouvez juste arrêter le système X Window et exécuter _root_. [.programlisting] .... kill -HUP 1 .... Il est impératif d'arrêter complètement X Window s'il est en train de marcher, avant de lancer cette commande. Si vous ne le faite pas, votre système, se trouvera probablement suspendu/bloqué après le lancement de la commande kill. === Comment accéder à mes consoles virtuelles depuis X ? Si la console est actuellement en train d'afficher X Window, vous pouvez utiliser Ctrl-Alt-F1, etc. pour passer d'une console à une autre. Notez cependantm qu'une fois que vous avez basculé depuis X Window vers un terminal virtuel, vous ne pouvez utiliser seulement les touches de fonctions Alt- pour passer à un autre terminal virtuel ou revenir è X Window. Vous n'avez pas à maintenir enfoncé la touche Ctrl. Si vous utilisez la touche contrôle pour revenir a X sur certaines vieilles versions, vous pouvez retrouver votre console texte bloquée en mode control-lock Taper la touche contrôle à nouveau pour le débloquer. === Comment démarrer XDM au boot ? Il y a deux écoles de pensée à propos du démarrage de http://www.freebsd.org/cgi/man.cgi?manpath=xfree86&query=xdm[xdm] Une école démarre xdm epuis http://www.freebsd.org/cgi/man.cgi?ttys[ /etc/ttys] en utilisant l'exemple fourni. tandis que l'autre lance simplement xdm depuis http://www.freebsd.org/cgi/man.cgi?rc[ rc.local] depuis un script _X.sh_ dans [.filename]#/usr/local/etc/rc.d#. Les deux approches sont valides, et suivant les situations, une méthode peut marcher et pas l'autre. Dans les deux cas, le résultat est le même : X fera apparaître une incite de login graphique. La méthode du ttys a l'avantage de documenter quel vty X va démarrer et en passant la responsabilité de redémarrer le serveur X au logout pour s'initialiser. La méthode rc.local rend la destruction par un kill de xdm très facile si jamais un problème de démarrage du serveur X était rencontré. Si _xdm_ est chargé depuis /etc/rc.local, il peut-être démarré avec n'importe quel argument (i.e comme un démon). Une version précédente de la FAQ disait d'ajouter les _vt_ que vous vouliez que X utilise dans le fichier [.filename]#/usr/X11R6/lib/X11/xdm/Xservers#. Cela n'est pas nécessaire, et X utilisera le premier _vt_ qu'il trouvera. === Quand je lance xconsole, j'obtiens Couldn't open console Si vous démarrez http://www.freebsd.org/cgi/man.cgi?manpath=xfree86&query=X[X] avec http://www.freebsd.org/cgi/man.cgi?manpath=xfree86&query=startx[startx], les permissions sur /dev/console ne seront _pas_ changé, ce qui entraînera que http://www.freebsd.org/cgi/man.cgi?manpath=xfree86&query=xterm[xterm -C] et http://www.freebsd.org/cgi/man.cgi?manpath=xfree86&query=xconsole[xconsole] ne marcheront pas. Cela est dû à la manière dont les droits sur la consoles sont fixés par défaut. Sur un système multi-utilisateur, on ne veut pas nécessairement que n'importe quel utilisateur ait la possibilité d'écrire sur la console système. Pour les utilisateurs qui se logguent directement sur la machine avec un VTY, le fichier http://www.freebsd.org/cgi/man.cgi?fbtab[fbtab] est là pour résoudre ce problème. En pratique, assurez vous d'avoir une ligne décommenté de la forme : [.programlisting] .... /dev/ttyv0 0600 /dev/console .... dans http://www.freebsd.org/cgi/man.cgi?fbtab(5)[/etc/fbtab] et cela assurera que quiconque se logguera sur [.filename]#/dev/ttyv0# obtiendra les droits sur la console. === Ma souris PS/2 ne se comporte pas bien sous X. Votre souris et votre pilote de souris ont dû se désynchroniser Dans les versions 2.2.5 et avant, passer de X à un termical virtuel et revenir à X ensuite , peuvent les re-synchroniser. Si le problème apparaît souvent, vous pouvez ajouter l'option suivante dans votre fichier de configuration du noyau, et recompiler. [.programlisting] .... options PSM_CHECKSYNC .... voir la section sur http://www.freebsd.org/cgi/man.cgi?=make-kernel[ la construction du noyau] si vous n'avez aucune expérience dans la recompilation de noyau. Avec cette option, vous aurez moins de chance d'avoir de problème de synchronisation entre la souris et le pilote. Si, malgrès tout, vous aviez ce problème, cliquez sur un bouton quelconque de la souris en maintenant la souris jusqu'à resynchroniser la souris et le pilote. Notez que malheureusement cette option peut ne pas marcher avec tous les systèmes et vide la fonctionnalité TAP du périphérique ALPS GlidePoint attaché auport souris PS/2 Dans les versions 2.2.6 et plus, la vérification de la synchronisation est un peu mieux faite et est standard avec les pilotes souris PS/2. Cela devrait même marcher avec GlidePoint. (comme le code de vérification est devenu une fonctionnalité standard, l'option PSM_CHECKSYNC n'est pas disponible dans ces versions). Malgrès il y a des rares cas où le pilote peut de façon erronée repporter des problèmes de synchronisation, et vous pourrez alors voir le message : [.programlisting] .... psmintr: out of sync (xxxx != yyyy) .... et voir que votre souris ne marche pas correctement. Si cela arrive, désactiver le mode de vérification de la synchronization en positionnant le drapeau pour les pilotes de souris PS/2 à 0x100. Entrez dans _UserConfig_ en tapant [.filename]#-c# option à l'invite du boot. [.programlisting] .... boot: -c .... Puis en ligne de comande de _UserConfig_, tapez : [.programlisting] .... UserConfig>flags psm0 0x100 UserConfig>quit .... === Ma souris PS/2 mouse de MouseSystems ne marche pas Certains ont rapportés que certains modèles de souris PS/2 de MouseSystem ne marchaient que lorsqu'ils étaient mis en mode haute résolution. D'un autre côté, le curseur de souris peut sauter d'une extrémité de l'écran à l'autre très souvent. Malheureusement, il n'y a pas de solution pour les versions 2.0.X et 2.1.X. Dans les versions 2.2 à 2.2.5, ajouter le patch suivant à [.filename]#/sys/i386/isa/psm.c# et reconstruisez le noyau. Voir la section sur http://www.freebsd.org/cgi/man.cgi?make-kernel[ la construction d'un noyau]si vous n'avez aucune expérience dans la construction des noyaux, [.programlisting] .... diff -u psm.c.orig psm.c @@ -766,6 +766,8 @@ if (verbose >= 2) log(LOG_DEBUG, "psm%d: SET_DEFAULTS return code:%04x\n", unit, i); + set_mouse_resolution(sc->kbdc, PSMD_RES_HIGH); + if 0 set_mouse_scaling(sc->kbdc); /* 1:1 scaling */ set_mouse_mode(sc->kbdc); /* stream mode */ .... Dans les versions 2.2.6 et plus, spécifier le drqpeau 0x04 au pilote de souris PS/2 afin de mettre la souris en mode haute résolution. Entrez dans__UserConfig__ en spécifiant l'option [.filename]#-c# à l'invite du boot. [.programlisting] .... boot: -c .... puis, dans la ligne de commande de__UserConfig__ tapez : [.programlisting] .... UserConfig>flags psm0 0x04 UserConfig>quit .... Voir les sections précédentes pour les autres causes possibles de problèmes avec la souris. === Lorsque je construis une application X, _imake_ dit qu'il ne trouve pas _Imake.tmpl_. Où est-t-il ? Imake.tmpl est une partie du paquetage Imake, un outil de développement standart sous X. Imake.tmpl,tout comme plusieurs fichiers d'en-tête qui sont requis lors de la construction d'applications X est contenu dans la distribution de programmes X. Vous pouvez l'installer depuis sysinstall ou manuellement à partir des fichiers de distributions X. === Comment puis-je inverser les boutons de la souris ? Lancez la commande _xmodmap -e "pointer = 3 2 1"_ depuis votre .xinitrc ou .xsession. == Réseaux. **Mise à jour en cours** === Où puis-je trouver des informations sur le boot sans disque? Le boot sans disque veut dire que la machine sous FreeBSD est bootée depuis le réseau, et lit les fichiers nécessaires depuis un serveur et non depuis son disque dur. Pour plus de détails, lisez link:{handbook}#diskless[ la section du Handbook sur le Diskless booting ] === Une machine sous FreeBSD peut-elle être utilisée comme routeur dédié ? Les standards de l'Internet et de bonnes pratiques techniques nous interdisent de faire par défaut du routage de paquets avec FreeBSD. Mais vous pouvez néamoins activer cette fonctionnalité en changeant la variable suivante à _YES_ dans http://www.freebsd.org/cgi/man.cgi?rc.conf[ rc.conf]: [.programlisting] .... gateway_enable=YES # L'hote agira comme routeur s'il est positionne a YES .... Cette option mettra la variable http://www.freebsd.org/cgi/man.cgi?sysctl[sysctl]_net.inet.ip.forwarding_ à _1_. Dans la plupart des cas, vous aurez aussi à lancer un processus de routage afin de renseigner les autres systèmes sur votre routeur. FreeBSD est fourni avec le démon de routage standard BSD http://www.freebsd.org/cgi/man.cgi?routed[routed], ou pour des situations plus complexes, vous pouvez essayer _GaTeD_ (disponible par FTP depuis _ftp.gated.Merit.EDU) _ qui supporte FreeBSD depuis 3_5Alpha7. Nous nous devons de vous prévenir que lorsque FreeBSD est configuré de cette manière, il ne correspond pas tout à fait aux requis standards de l'Internet sur les routeurs. Néamoins, il s'en rapproche assez pour un usage ordinaire. === Puis-je connecter ma machine sous Win95 à l'Internet via FreeBSD ? Typiquement, les gens qui posent cette questions sont ceux qui ont 2 PC à la maison, un avec FreeBSD et un avec Win95. L'idée est d'utiliser la machine sous FreeBSD pour se connecter à l'Internet et puis pouvoir ensuite accéder à l'Internet depuis la machine sous Windows 95 via la machine sous FreeBSD. Ce n'est en réalité qu'un cas particulier de la question précédente. Il y a un document très pratique qui explique comment configurer FreeBSD comme http://www.ssimicro.com/~jeremyc/ppp.html[routeur par connexion PPP] _NOTE:_ Cela requiert que vous ayez au moins deux adresses IP fixes, et probablement 3 ou plus, cela dépend du travail que vous voulez effectuer pour pouvoir mettre en place la machine sous Windows. Comme alternative, si vous n'avez pas d'adresse IP fixe, vous pouvez utiliser une des adresses IP privés et installer des _proxies_ comme http://squid.nlanr.net/Squid/[SQUID] et http://www.tis.com/[le TIS firewall toolkit] sur la machine sous FreeBSD. Voir aussi la section sur http://www.freebsd.org/cgi/man.cgi?natd[ natd ]. === Pourquoi la recompilation du dernier BIND de ISC échoue-t-elle ? Il y a un conflit entre le fichier _cdefs.h_ de la distribution et celui fourni par FreeBSD. Vous n'avez qu'à enlever _compat/include/sys/cdefs.h_. === FreeBSD supporte-t-il SLIP et PPP? Oui, regardez les pages de manuel http://www.freebsd.org/cgi/man.cgi?slattach[slattach], http://www.freebsd.org/cgi/man.cgi?sliplogin[sliplogin], http://www.freebsd.org/cgi/man.cgi?pppd[pppd] et http://www.freebsd.org/cgi/man.cgi?ppp[ppp]. _pppd_ et _ppp_ permettent les connexions entrantes et sortantes http://www.freebsd.org/cgi/man.cgi?sliplogin[Sliplogin] ne peut s'utiliser qu'avec des connexions entrantes et http://www.freebsd.org/cgi/man.cgi?slattach[slattach] qu'avec des connexions sortantes. Ces programmes sont décrits dans les sections suivantes du link:{handbook}[handbook]: * link:link:{handbook}#slips[référence du handbook sur SLIP (côté serveur)] * link:.link:{handbook}#slipc[référence du handbook sur SLIP (côté client)] * link:link:{handbook}#ppp[référence du handbook sur PPP (mode noyau)] * link:link:{handbook}#USERPPP[référence du handbook sur PPP (mode utilisateur)] Si vous avez accès à l'Internet à travers un "compte shell" vous pouvez jeter un coup d'oeil au paquetage http://www.freebsd.org/cgi/ports.cgi?^slirp[slirp]. Il peut vous fournir un accès (limité) aux services tels que ftp et http directement depuis votre machine locale. === Est-ce que FreeBSD supporte NAT ou le Masquerading ? Si vous avez un sous-réseau local (une ou plusieur machines), mais qu'une seule adresse IP vous a été allouée (même si ce n'est qu'une adresse IP dynamique), vous pouvez regarder le programme http://www.freebsd.org/cgi/man.cgi?natd[natd] . _Natd_ vous permet de connecter un sous-réseau entier à l'Internet en n'utilisant qu'une seule adresse IP. Le programme http://www.freebsd.org/cgi/man.cgi?ppp[ppp] a des fonctionnalités similaires construit par l'intermédiaire de l'option _-alias_ switch. La http://www.freebsd.org/cgi/man.cgi?libalias[bibliothèque alias] est utilisée dans les deux cas. === Je n'arrive pas à faire marcher ppp. Où me suis-je trompé ? Vous devriez tout d'abord lire la page de manuel http://www.freebsd.org/cgi/man.cgi?ppp[ppp] et link:{handbook}#USERPPP[la section du handbook sur ppp]. Activer le logging avec la commande [.programlisting] .... set log Phase Chat Connect Carrier lcp ipcp ccp command .... Cette commande peut-être tapée à l'invite de commande de _ppp_ ou peut-être entrée dans le fichier de configuration _/etc/ppp/ppp.conf_. (le début de la section par défaut _default_ est l'endroit idéal pour le mettre). Assurez vous que le fichier http://www.freebsd.org/cgi/man.cgi?syslog.conf[/etc/syslog.conf] contienne les lignes [.programlisting] .... !ppp *.* /var/log/ppp.log .... et que le fichier _/var/log/ppp.log_ existe. Vous pouvez aussi tirer pas mal de renseignements sur ce qui se passe en lisant les fichiers log. Ne vous inquiétez pas même si cela vous semble dénué de sens, si vous obtenez de l'aide de quelqu'un, pour lui, cela aura un sens. Si votre version de ppp ne comprend pas la commande "set log" vous devriez charger la http://www.freebsd.org/~brian[dernière version]. Il pourrra se construire sur FreeBSD version 2.1.5 et plus. ==== Ppp se bloque quand je le lance Cela est usuellement dû au fait que votre nom d'hôte ne peut être résolu. La meilleure solution pour résoudre ce problème est de s'assurer que votre _/etc/hosts_ est consulté en premier par votre résolveur en éditant _/etc/host.conf_ et en mettant la ligne _hosts_ en premier. Puis, ajoutez simplement une entrée pour votre machine locale dans _/etc/hosts_. Si vous n'avez pas de réseau local, changez simplement votre ligne _localhost_ : [.programlisting] .... 127.0.0.1 foo.bar.com foo localhost .... Sinon, ajoutez simplement une autre entrée pour votre hôte. Consultez les pages de manuels appropriées pour plus de détails. Vous devrez être alors capable de réussir à faire un __ping -c1 ``hostname``__ quand vous aurez fini. ==== Ppp ne veut pas communiquer en mode -auto Tout d'abord, vérifiez que vous avez bien un routage par défaut en lançant http://www.freebsd.org/cgi/man.cgi?netstat[ netstat -rn], vous devriez voir deux entrées comme suivent : [.programlisting] .... Destination Gateway Flags Refs Use Netif Expire default 10.0.0.2 UGSc 0 0 tun0 10.0.0.2 10.0.0.1 UH 0 0 tun0 .... ici, on supposera que vous avez utilisé les adresses données en exemple dans le handbook, les pages man ou depuis le fichier ppp.conf.sample. Si vous n'avez pas de routage par défaut, c'est peut-être parce que vous utilisez une vieille version de http://www.freebsd.org/cgi/man.cgi?ppp[ppp] qui ne comprend pas le mot _HISADDR_ dans le fichier ppp.conf. Si votre version de _ppp_ est antérieure à FreeBSD 2.2.5, changer la ligne [.programlisting] .... add 0 0 HISADDR .... par celle-ci : [.programlisting] .... add 0 0 10.0.0.2 .... Une autre raison au fait que la ligne du routage par défaut soit manquante est que vous avez pu régler un routage par défaut erroné dans le fichier http://www.freebsd.org/cgi/man.cgi?rc.conf[/etc/rc.conf] (ce fichier est appelé _/etc/sysconfig_ avant la release 2.2.2), et que vous avez oublié la ligne suivante : [.programlisting] .... delete ALL .... from _ppp.conf_. Si cela est le cas, revenez à la section du handbook sur link:{handbook}#ppp-and-slip[la configuration finale du système] section of the handbook. ==== Que veut dire "No route to host" ? Cette erreur est usuellement dûe à une omission de la section [.programlisting] .... MYADDR: delete ALL add 0 0 HISADDR .... dans votre fichier _/etc/ppp/ppp.linkup_. Cela est seulement nécessaire si vous avez une adresse IP dynamique ou que vous ne savez pas l'adresse de votre routeur. Si vous utilisez le mode interactif, vous pouvez taper les lignes suivantes après être entré en _mode paquet_ (le mode paquet est indiqué par le _PPP_ en majuscule à l'invite): [.programlisting] .... delete ALL add 0 0 HISADDR .... Se référer à la section du handbook sur link:{handbook}#ppp-and-slip[ PPP et les adresses IP dynamiques ]pour plus de détails. === Ma connexion se termine au bout de 3 minutes La limite de temps (timeout) par défaut de ppp est de 3 minutes. Cela peut-être ajusté avec les lignes : [.programlisting] .... set timeout NNN .... où _NNN_ est le nombre de secondes d'inactivité avant que la connexion ne soit fermée. Si _NNN_ est égal à zero, la connexion ne sera jamais fermée pour cause de limite de temps écoulée. Il est possible de mettre cette commande dans le fichier _ppp.conf_, ou de la taper à l'invite en mode interactif. Il est également possible de l'ajuster au vol alors que la ligne est active, en se connectant à la socket du serveur _ppp_ en utilisant http://www.freebsd.org/cgi/man.cgi?telnet[telnet] ou http://www.freebsd.org/cgi/man.cgi?pppctl[pppctl]. Se réferer à la page de manuel de http://www.freebsd.org/cgi/man.cgi?ppp[ppp] pour plus de détails. ==== Ma connexion se termine lors de gros chargements. Si vous avez activé le report de la qualité de connexion (Link Quality Reporting (LQR)), il est possible ce soit parce que que trop de paquets LQR sont perdus entre la machine et son interlocuteur. PPP en déduit que la ligne doit être trop mauvaise, et se déconnecte. Avant la version 2.2.5 de FreeBSD, LQR était activé par défaut. Il est maintenant désactivé par défaut. LQR peut-être désactivé avec la ligne suivante : [.programlisting] .... disable lqr .... ==== Ma connexion se termine après un certain temps aléatoire. Parfois, sur une ligne de téléphone avec des parasites, ou même sur une ligne avec des attentes d'appels activées, le modem peut se suspendre parce qu'il pense (de manière erronée) qu'il y a une perte du support de connexion (lost carrier) Il y a un réglage sur la plupart des modems qui déterminent le degré de tolérance sur la perte temporaire de la ligne porteuse. Sur un USR Sportster par exemple, cela est mesuré par le registre S10 en dixième de secondes. Pour rendre votre modem plus tolérant, vous pouvez ajouter la séquence envoi-attente suivante à votre chaîne de connexion : [.programlisting] .... set dial "...... ATS10=10 OK ......" .... Se référer au manuel de votre modem pour plus de détails. ==== Rien ne se passe après le message Login Ok! Avant la version 2.2.5 de FreeBSD, une fois la ligne établie, http://www.freebsd.org/cgi/man.cgi?ppp[ppp] devait attendre que ce soit l'autre parti (peer) qui initialise le protocole de contrôle de ligne (Line Control Protocol (LCP). Or, plusieurs ISPs ne débuteront pas la négociation et attendront du client qu'il le fasse. Pour forcer _ppp_ à initialiser le LCP, utiliser la ligne suivante : [.programlisting] .... set openmode active .... _Note_: Cela ne fait pas de dégats si chacun des deux parties initialisent tous les deux la connexion, c'est pourquoi openmode est à présent activé par défaut. Quoiqu'il en soit, la prochaine section expliquera quand est-ce ce que cela peut gêner. ==== Je n'arrête pas de voir des erreurs à propos de magic being the same De temps en temps, juste après la connexion, vous pouvez voir des messages dans le log qui dit "magic is the same". Parfois ces messages sont sans conséquences, et parfois l'un ou l'autre des partis quitte. La plupart des implémentations ppp ne peuvent survivre à ce problème, et même si la ligne semble venir, vous verrez régulièrement des demandes de configuration et des accusés de réception de configuration dans le fichier log à moins que ppp abandonne et ne ferme la connexion. Cela apparaît normallement sur les machines serveurs avec des disques lents qui diffusent un getty sur le port, et qui exécute ppp depuis un script ou programme de login après le login. J'ai aussi eu vent de cela arrivant lorsqu'on utilise slirp. La raison est qu'entre le temps où getty quitte et que ppp commence, le ppp côté-client commence par envoyer des paquets Line Control Protocol (LCP). Parce que l'ECHO est toujours actif sur les ports du côté serveur, le client ppp verra ces paquets qui lui seront "reflèté". Une partie de la négociation LCP est d'établir un nombre magique (magic number) de chaque côté de la ligne, ceci afin que les "réflexions" soient détectées. Le protocole dit que lorsque l'autre parti essaye de négocier le même nombre magique, un NAK devrait être envoyé et un nouveau nombre magique choisi. Durand la période où le serveur où le port serveur a l'ECHO activé, le client ppp envoie des paquets LCP, voit le même nombre magique dans les paquets reflètés et il le "NAK". Il voit aussi les reflexions de NAK (qui veut aussi dire que ppp devrait changer son nombre magique). Cela produit potentiellement un énorme nombre de nombre magiques à changer, chacun d'entre eux tous s'empilant joyeusement dans le buffer stty du serveur. Aussitôt que ppp démarre sur le serveur, il est innondé par des changement de nombre magique et souvent décide qu'il a assez essayé de négociation LCP et abandonne. Pendant ce temps, le client qui ne voit alors plus de réflexions, se réjouit juste le temps de voir que le serveur l'a déconnecté. Cela peut-être évité en autorisant l'autre parti à démarrer la négociation avec la ligne suivante dans le fichier ppp.conf [.programlisting] .... set openmode passive .... Cela dit à ppp d'attendre que le serveur débute la négociation LCP. Certains serveurs toutefois peuvent ne jamais initier la négociation. Si cela est le cas, vous pouvez faire quelque chose du genre : [.programlisting] .... set openmode active 3 .... Cela dit à ppp de rester passif pendant 3 secondes, et puis commencer à envoyer les requêtes LCP/ Si l'autre parti commence à envoyer des requêtes durant cette période, ppp répondra immédiatement plutôt qu'en attendant que la période des 3 secondes se termine. ==== Les négociations LCP continuent jusqu'à ce que la connexion soit fermée. Cela est pour l'instant un défaut d'implémentation dans _ppp_ où il n'associe pas les réponses LCP, CCP & IPCP avec leur requête originale. Comme conséquence, si l'une des implémentations _ppp_ est 6 secondes plus lente que l'autre côté, l'autre côté enverra 2 requêtes de configuration LCP supplémentaire. Cela est fatal. Soient 2 implémentations, _A_ et _B_. _A_ commence à envoyer des requêtes LCP immédiatement après s'être connecté et _B_ met 7 secondes à démarer. Quand _B_ démarre, _A_ a envoyé 3 requêtes LCP. Nous supposons que la ligne a désactivée l'ECHO, car dans le cas contraire nous verrions des problèmes de nombres magiques comme décrit dans la section précédente. _B_ envoi un REQ, puis un ACK au premier REQ de _A_. Le résultat est que _A_ entre dans l'état _OPENED_ et envoie un ACK (le premier) en retour à _B_. Pendant ce temps, _B_ renvoi 2 ACK de plus en réponse au 2 REQ supplémentaires envoyés par _A_ avant _B_ que B n'ait commencé. _B_ reçoit alors le premier ACK de _A_ et entre dans l'état _OPENED_. _A_ reçoit le deuxième ACK de _B_ et revient à l'état _REQ-SENT_, et envoie un autre (quatrième) REQ comme décrit dans la RFC. Il envoie alors un troisième ACK et entre dans l'état _OPENED_. Durant ce moment, _B_ reçoit le quatrième REQ de _A_, par conséquent, revient dans l'état _ACK-SENT_ et envoie un autre (second) REQ et (quatrième) ACK as per the RFC. _A_ reçoit le REQ, va dans l'état _REQ-SENT_ et envoie un autre REQ. Il reçoit alors immédiatement le ACK suivant et entre dans l'état _OPENED_. Cela continue tant qu'un des partis ne s'aperçoive qu'ils n'iront nulle part comme cela et abandonne. La meilleure façon d'éviter cela est de configurer un côté comme étant _passif_ - cela fait, faire de telle sorte qu'un des côtés attende que l'autre commence la négociation. Cela peut-être fait par la commande : [.programlisting] .... set openmode passive .... Faire attention avec cette option, vous devriez aussi utiliser la commande [.programlisting] .... set stopped N .... afin de limiter la durée avant que _ppp_ attende de l'autre parti de commencer la négociation. D'une autre façon, la commande [.programlisting] .... set openmode active N .... (où _N_ est le nombre de secondes qu'il faut attendre avant que le démarrage de la négociation ne soit faite). Regardez les pages de manuels pour plus de détails. ==== Ppp se verrouille peu après la connexion. Avant la version 2.2.5 de FreeBSD, il était possible que votre ligne soit désactivée peu après la connexion, dûe à une mauvaise négociation de compression Predictor1 de _ppp_ Cela ne devrait arriver que si deux côtés essayent de négocier des protocoles de contrôle de compression ( Compression Control Protocols (CCP) différents. Ce problème est à présent résolu, mais si vous utilisez toujours une vieille version de _ppp_, le problème peut-être sauté avec la ligne [.programlisting] .... disable pred1 .... ==== Ppp se verrouille quand je "shell" pour le tester. Quand vous exécutez le _shell_ ou la commande _!_, _ppp_ exécute un shell (ou si vous avez passé des arguments, _ppp_ exécutera ces arguments). Ppp attendra que la commande se termine avant de continuer. Si vous avez l'intention d'utiliser la connexion ppp pendant que vous lancez la commande, la connexion apparaîtra alors comme ayant été gelée. Cela parce que _ppp_ attend que la commande se termine. Si vous voulez exécuter des commandes comme cela, utilisez plutôt la commande _!bg_. Cela exécutera la commande en arrière plan, et ppp pourra continuer de servir la connexion. ==== Ppp sur un null-modem ne quitte jamais. Il n'y a aucune manière pour que _ppp_ détermine automatiquement qu'une connexion directe s'est achevée. Cela est dû aux lignes utilisées dans un câble série null-modem. Quand on utilise cette sorte de connexion, LQR devrait être toujours activé avec la ligne : [.programlisting] .... enable lqr .... LQR est accepté pas défaut si négocié par l'autre parti. === Pourquoi ppp tente de se connecter sans raison em mode -auto ? Si _ppp_ tente de se comnnecter sans raison aucune, vous devez en déterminer la cause et mettre en place des filtrages d'appels (dfilters) pour prévenir de tels appels. Afin d'en déterminer la cause, utilisez la ligne suivant : [.programlisting] .... set log +tcp/ip .... Cela tracera tous le trafic à travers une connexion. La prochaine fois que la connexion se mettra en place de manière inattendue, vous verrez la raison tracé avec le moment où cela s'est produit à côté. Vous pouvez à présent désactiver les appels sous ces circonstances. D'habitude, ces sortes de problèmes arrivent à cause des DNS lookup. Pour empêcher le DNS lookup d'établir une connexion (cela n'empêchera _pas__ppp_ de passer les paquets à travers une connexion établie), utilisez les lignes suivantes : [.programlisting] .... set dfilter 1 deny udp src eq 53 set dfilter 2 deny udp dst eq 53 set dfilter 3 permit 0/0 0/0 .... Cela ne convient pas toujours puisqu'il enlèvera effectivement vos fonctionnalités de demandes d'appels - la plupart des programmes auront besoin du DNS lookup avant de faire quelque chose ayant un rapport avec le réseau. Dans le cas DNS, vous pouvez essayer de déterminer qui est-ce qui essaye actuellement de résoudre le nom de l'hôte. La plupart du temps, c'est http://www.freebsd.org/cgi/man.cgi?sendmail[sendmail] le coupable. Vous devez vous assurer que vous avez dit à sendmail de ne faire aucun DNS lookup dans ses fichiers de configuration, regardez la section sur link:ispmail[la configuration du mail] pour les détails de comment créer son propre fichier de comfiguration, et qu'est ce qu'on doit mettre dedans. Vous pouvez aussi vouloir ajouter les lignes suivantes dans votre fichier _.mc_ : [.programlisting] .... define(`confDELIVERY_MODE', `d')dnl .... Cela fera que sendmail mettra tout en file d'attente jusqu'à ce que la file soit lancée (habituellement, sendmail est invoqué avec -bd -q30m, lui disant de lancer la file d'attente toutes les 30 minutes) ou jusqu'à ce que un sendmail -q soit effectué (peut-être dans votre fichier ppp.linkup). ==== Que veulent dire ces erreurs CCP ? Je n'arrête pas de voir les erreurs suivantes dans mon fichier log : [.programlisting] .... CCP: CcpSendConfigReq CCP: Received Terminate Ack (1) state = Req-Sent (6) .... Ceci est obtenu parce que ppp est en train de négocier la compression Predictor1 et que l'autre parti ne veut pas du tout négocier de compression. Ces messages sont sans conséquences aucune, mais si vous voulez les enleverm vous pouvez désactiver la compression Predictor1 aussi en local. [.programlisting] .... disable pred1 .... === Ppp se bloque durant les transferts de fichiers avec une erreur IO. Sous FreeBSD 2.2.2 et avant, il y avait un bug dans le driver tun qui stoppait tous les paquets entrants d'une taille plus grande que la taille MTU de l'interace tun. La réception de paquets plus grands que la taille du MTU résultait en une erreur IO qui était alors tracé avec syslogd, Les spécifications ppp disent qu'un MTU de 1500 devrait _toujours_ être accepté comme un minimum, ceci quelque soit la négociation LCP. Il est toutefois possible que vous diminuez le MTU à moins de 1500, votre ISP vous transmettra des paquets de 1500 sans s'en préoccuper, et cela vous bloquera, gelant ainsi la ligne. Ce problème peut être contourné en ne réglant jamais un MTU en dessous de 1500 sous FreeBSD 2.2.2 et avant. ==== Pourquoi ppp ne trace-t-il pas ma vitesse de connexion ? La façon de tracer toutes les lignes de la conversation de votre modem est d'activer : [.programlisting] .... set log +connect .... Cela permettra à http://www.freebsd.org/cgi/man.cgi?ppp[ppp] de tout tracer jusqu'à la dernière chaîne de requête d'"attente" Si vous voulez voir votre vitesse de connexion et que vous utilisez PAP ou CHAP (et donc ne rien avoir avec "chat" après le CONNECT dans le script dial - pas de script "set login"), vous devez vous assurer que vous prévenez ppp de s'attendre tout la ligne CONNECT, quelque chose comme : [.programlisting] .... set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n" .... Ici, nous avons notre CONNECT, ne rien envoyer, et puis attendre un saut de ligne, forçant _ppp_ à lire toute la réponse CONNECT. ==== Ppp ignore le caractère \ dans mon script chat Ppp parse chacune des lignes de votre fichier de configuration, de telle sorte qu'il puisse interprêter des chaines comme _set phone "123 456 789"_ correctement (et réaliser qu'il n'y a que _un_ seul argument. Pour pouvoir spécifier un caractère `, vous devez l'échapper avec un backslash (\). Quand l'interprêteur chat parse chaque argument, il re-interprête l'argument de telle sorte à trouver des séquences de caractères d'échappement comme \P ou \T (voir les pages de manuel). En conséquence de ce double-parsing, vous devez vous souvenir d'utiliser le nombre correct d'échappement. Si vous voulez envoyer un caractère `\` à votre modem, vous aurez besoin de faire quelque chose comme : [.programlisting] .... set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK" .... qui se résultera en la séquence suivante : [.programlisting] .... ATZ OK AT\X OK .... ou encore [.programlisting] .... set phone 1234567 set dial "\"\" ATZ OK ATDT\\T" .... résultera en la séquence suivante : [.programlisting] .... ATZ OK ATDT1234567 .... ==== Ppp reçoit une erreur de segmentation, mais je ne trouve pas de fichier _ppp.core_ Ppp (ou n'importe quel programme dans le même cas) ne devrait jamais faire de coredump. Parce que ppp tourne avec une identité d'utilisateur effectif de 0, le système d'exploitation n'écrira pas d'image du core sur le disque avant de l'avoir terminé. Si, malgrè tout, ppp se _termine_ actuellement à cause d'une violation de segmentation, ou n'importe quel autre signal qui cause normalement un core dump, _et_ que vous êtes sûr que vous utilisez la dernière version (voir le début de cette section), alors vous devriez faire la chose suivante : [.programlisting] .... $ tar xfz ppp-*.src.tar.gz $ cd ppp*/ppp $ echo STRIP= >>Makefile $ echo CFLAGS+=-g >>Makefile $ make clean all $ su make install chmod 555 /usr/sbin/ppp .... Vous aurez alors une version déboguable de ppp installé. Vous aurez à être root pour lancer ppp puisque tous ses privilèges auront été révoqués. Quand vous démarrez ppp, retenez soigneusement le répertoire courant dans lequel vous étiez. A présent, si et quand ppp recevra une violation de segmentation, cela crééra un fichier core nommé ppp.core. Vous aurez alors à faire la chose suivante : [.programlisting] .... $ su gdb /usr/sbin/ppp ppp.core (gdb) bt ..... (gdb) f 0 ..... (gdb) i args ..... (gdb) l ..... .... Toutes ces informations devront être données suivant votre question, rendant ainsi possible le diagnostique de votre problème. Si vous êtes familier avec gdb, vous pouvez vouloir trouver d'autres techniques pour trouver ce qui a causé le dump, et les adresses et valeurs des variables concernées. ==== Le processus qui force un appel en mode auto ne se connecte jamais. Cela est un problème connu quand _ppp_ est réglé de telle sorte à négocier une adresse IP dynamique avec son homologue. Quand ce programme initial appelle http://www.freebsd.org/cgi/man.cgi?connect[ connect(2) ], l'adresse IP de l'interface tun est assignée à l'extrêmité de la socket. Le noyau crée le premier paquet sortant et l'écrit sur le périphérique tun. _Ppp_ lit alors le paquet et établit alors la connexion. Si, comme résultat de l'assignation dynamique de _ppp_, l'adresse de l'interface est changée, l'extrêmité originale de la socket sera invalide. Tout paquet envoyé à l'autre parti sera alors en principe perdu. Et même s'il ne l'était pas, toute réponse ne pourrait pas être renvoyée à la machine originelle puisque l'adresse IP ne serait plus possèdée par cette machine. Théoriquement, il y a plusieurs manières d'aborder ce problème. Le mieux serait que l'homologue re-assigne la même adresse IP si possible _:-)_ La meilleure méthode de notre côté, serait de ne jamais changer l'adresse IP de l'interface tun, mais à la place, changer tous les paquets sortant de telle sorte que les adresses IP de la source soient changées de l'interface Ip à l'IP négocié au vol. C'est essentiellement ce que http://www.freebsd.org/cgi/man.cgi?libalias[ libalias(3) ] (et l'option _-alias_ de ppp) font actuellement. Une autre alternative (et probablement la plus sûre); est d'implémenter un appel système qui change tous les sockets reliées depuis une adresse IP à une autre. _Ppp_ utiliserait cet appel pour modifier la socket de tous les programmes existant lorsqu'une nouvelle adresse IP est négociée. Une troisième possibilité est d'autoriser à une interface de s'activer sans adresse IP. Les paquets sortant auront une adresse IP de 255.255.255.255 jusqu'à ce que le premier SIOCAIFADDR ioctl soit fait. Cela reviendrait à lier entièrement la socket, et ça serait à _ppp_ de changer l'adresse IP source, mais seulement si il est à 255.255.255.255, et seulement si le numéro IP et le checksum IP doivent être changés. Quoiqu'il en soit, c'est de la bidouille puisque le noyau enverra des paquets invalides à une interface mal configurée, en supposant que d'autres mécanismes seront capables de réparer les choses retrospectivement. Aucune de ces solutions n'a (encore) été implémentée. ==== Pourquoi la plupart des jeux ne marchent pas avec l'option -alias ? La raison pour laquelle les jeux et assimilés ne marchent pas avec libalias est que la machine extérieure essaye d'ouvrir une connexion ou envoyer des paquets UDP (non sollicités) à la machine interne. Le logiciel packet alias ne sait alors pas qu'il faut envoyer ces paquets à une machine interne. Pour que ça marche, assurez vous que la seule chose qui tourne est le logiciel avec lequel vous avez des problèmes, puis alors, soit vous lancez tcpdump sur votre interface tun de votre routeur, soit vous activez le login ppp tcp/ip (`set log +tcp/ip`) sur votre routeur. Quand vous démarrez le logiciel incriminé, vous devriez voir les paquets passer à travers la machine routeur. Quand quelque chose revient depuis l'extérieur, il sera retiré (c'est ça le problème). Noter le numéro de port de ces paquets, puis arrêtez le logiciel incriminé. Faite ceci quelques fois pour voir si les numéro de ports sont consistants. Si ils le sont, alors la ligne suivante dans la section appropriée de /etc/ppp/ppp.conf rendra le logiciel fonctionnel. [.programlisting] .... alias port proto internalmachine:port port .... où proto est soit tcp ou udp, internalmachine est la machine à laquelle vous voulez que les paquets soient envoyés et port le numéro de port de destination des paquets. Vous ne pourrez pas utiliser le logiciel sur d'autres machines sans changer la commande du dessus, et lancer le logiciel sur 2 machines internes en même temps est hors de question - après tout, le monde extérieur voit tout votre réseau entier comme une seule machine. Si les numéros de ports ne sont pas consistants, il y a 3 autres options : _1)_ Soumettre le support dans libalias. Des exemples de cas spéciaux peuvent être trouvés dans /usr/src/lib/libalias/alias_*.c (alias_ftp.c iest un bon prototype). Cela implique habituellement la lecture de certains paquets sortant reconnus, identification des instructions qui dit à la machine extérieure d'initialiser la connexion en retour vers machine interne sur un port (aléatoire) spécifique, et mettre en place une route dans la table d'alias de telle sorte que les paquets concernés sachent où aller. C'est la solution la plus difficile, mais c'est la meilleure et permettra au logiciel de marcher sur plusieurs machines _2)_ Utiliser un proxy. L'application peut pouvoir supporter socks5 par exemple, ou (comme dans le cas de cvsup) peut avoir une option passive qui évite d'avoir à toujours demander que l'autre parti ouvre une connexion en retour sur la machine locale. _3)_ Tout rediriger vers une machine interne utilisant alias addr. C'est l'approche "bourrin". ==== Rien de cela ne marche - je suis désespéré ! Si tout le reste échoue, envoyer autant d'informations que vous pouvez, y compris vos fichiers de configuration, comment vous avez démarré _ppp_, les parties pertinentes de votre fichier log, et la sortie de la commande http://www.freebsd.org/cgi/man.cgi?netstat[ netstat -rn ](avant et après connexion) à la liste de diffusion link:mailto:freebsd-questions@FreeBSD.org[ freebsd-questions@FreeBSD.org ]ou au newsgroup link:news:comp.unix.bsd.freebsd.misc[ comp.unix.bsd.freebsd.misc, ]et quelqu'un devrait vous orienter dans la bonne direction. === Je ne peux pas créer un périphérique _/dev/ed0_ ! Dans le cadre des réseaux Berkeley, les interfaces réseaux sont seulement directement accessibles par le code du noyau. Regarder le fichier _/etc/rc.network_ et les pages de manuels pour les différents programmes réseaux mentionnés ici pour plus d'informations. Si cela vous est complètement confus, vous devriez prendre un livre décrivant l'administration réseaux sur un autre système d'exploitation relatif à BSD; à quelques exceptions mineures, administrer un réseau sous FreeBSD est basiquement la même chose que sur un SunOS 4.0 ou un Ultrix. === Comment puis-je régler les alias éthernet ? Ajouter _netmask 0xffffffff_ à votre ligne de commande http://www.freebsd.org/cgi/man.cgi?ifconfig[ifconfig] comme ci-dessous : [.programlisting] .... ifconfig ed0 alias 204.141.95.2 netmask 0xffffffff .... === Comment puis-je faire pour que mon 3C503 utilise l'autre port réseau ? Si vous voulez utiliser les autres ports, vous avez à spécifier un paramêtre supplémentaire dans la ligne de commande http://www.freebsd.org/cgi/man.cgi?ifconfig[ifconfig]. Le port par défaut est _link0_. Pour utiliser le port AUI à la place du BNC,utiliser _link2_. Ces paramêtres devraient être spécifiés en utilisant les variables de ifconfig_* variables dans http://www.freebsd.org/cgi/man.cgi?rc.conf[/etc/rc.conf]. === J'ai des problèmes avec NFS depuis/vers FreeBSD. Certaines cartes réseaux sont meilleures que d'autres et peuvent causer quelquefois des problèmes lors d'applications réseaux intensives comme NFS. Regarder link:{handbook}#nfs[la partie du Handbook sur NFS ]pour plus d'informations à ce sujet. === Pourquoi ne puis-je pas monter par NFS depuis une machine sous Linux ? Certaines versions du code NFS de Linux ne peuvent accepter des requêtes de montages que depuis un port privilègié; essayez [.programlisting] .... mount -o -P linuxbox:/blah /mnt .... === Pourquoi ne puis-je pas monter un NFS depuis une machine Sun ? Les stations de travail Sun sous SunOS 4.X n'acceptent seulement des requêtes de montage que depuis un port privilègié; essayez [.programlisting] .... mount -o -P sunbox:/blah /mnt .... === J'ai des problème pour parler PPP à des machines NeXTStep. Essayer de désactiver l'extension TCP dans http://www.freebsd.org/cgi/man.cgi?rc.conf[/etc/rc.conf] en changeant la variable à NO : [.programlisting] .... tcp_extensions=NO .... les machines Xylogic's Annex ne marchent pas non plus dans ce contexte, et vous devez changer de même que ci-dessus pour pouvoir vous connecter au travers d'elles. === Comment activer le support multicast IP ? Les opérations multicast sont entièrement supportées par FreeBSD 2.0 et plus par défaut. Si vous voulez que votre machine marche comme un routeur multicast, vous devez recompiler votre noyau avec l'option _MROUTING_ et lancer _mrouted_. FreeBSD 2.2 et plus démarrera _mrouted_ au moment du boot si l'option _mrouted_enable_ est mis à "YES" dans _/etc/rc.conf_. Les outils MBONE tools sont disponibles dans leur propre catégorie de ports, mbone. Si vous cherchez les outils de conférence _vic_ et _vat_, c'est là qu'il faut voir ! Pour plus d'informations, regarder http://www.mbone.com/[le web d'information Mbone]. === Quelles cartes réseaux sont basées sur le chipset DEC PCI ? Voici une liste compilée par link:mailto:gfoster@driver.nsta.org[Glen Foster], avec quelques ajouts récents : [.programlisting] .... Vendor Model ---------------------------------------------- ASUS PCI-L101-TB Accton ENI1203 Cogent EM960PCI Compex ENET32-PCI D-Link DE-530 Dayna DP1203, DP2100 DEC DE435 Danpex EN-9400P3 JCIS Condor JC1260 Linksys EtherPCI Mylex LNP101 SMC EtherPower 10/100 (Model 9332) SMC EtherPower (Model 8432) TopWare TE-3500P Zynx ZX342 .... === Pourquoi dois-je utiliser le FQDN pour les hôtes de mon site ? Vous verrez probablement que l'hôte est actuellement dans un domaine différent; par exemple, si vous êtes dans foo.bar.edu et que vous voulez atteindre un hôte nommé mumble dans le domaine bar.edu domain, vous aurez à vous y référer par son nom de domaine entièrement qualifié, mumble.bar.edu, à la place de juste mumble. Traditionellement, cela était autorisés par les résolveurs BSD BIND. Malgrè tout, la version courante de http://www.freebsd.org/cgi/man.cgi?named[bind] qui est fournie avec FreeBSD ne fournit plus d'abbréviation par défaut pour un domaine non entièrement qualifié; autre que le domaine dans lequel vous êtes. Ainsi, un hôte non-qualifié _mumble_ doit soit être trouvé comme _mumble.foo.bar.edu_, ou alors il sera cherché dans le domaine racine. Cela est différent du comportement décrit auparavant, où la recherche continuait à travers _mumble.bar.edu_, et _mumble.edu_. Jetez un coup d'oeil à la RFC 1535 pour savoir pourquoi cela est considéré comme une mauvaise pratique, ou encore même un trou de sécurité. Comme détour, vous pouvez placer la ligne : [.programlisting] .... search foo.bar.edu bar.edu .... à la place de la précédente : [.programlisting] .... domain foo.bar.edu .... dans votre fichier http://www.freebsd.org/cgi/man.cgi?resolv.conf[ /etc/resolv.conf ]. Quoiqu'il en soit, assurez vous que l'ordre de recherche ne vas pas en dehors des limites entre l'administration locale et publique, comme appelée dans la RFC 1535. === Permission denied pour toutes les opérations réseaux. Si vous avez compilé votre noyau avc l'option _IPFIREWALL_, vous devez être prévenu, que la politique par défaut depuis le 2.1.7R (cela a changé durant le développement du 2.1-STABLE) est de refuser tous les paquets qui ne sont pas explicitement autorisés. Si vous avez inintentionnellement mal configuré votre système pour le firewall, vous pouvez rétablir les fonctionnalité réseaux en tapant la commande suivante sous root : [.programlisting] .... ipfw add 65534 allow all from any to any .... Vous pouvez aussi régler "firewall_type='open'" dans _/etc/rc.conf_. Pour plus d'informations sur la configuration d'un firewall FreeBSD, voir la link:{handbook}#firewalls[section correspondante du handbook]. === Combien d'overhead, IPFW implique-t-il ? La réponse à ceci dépend pour la plupart à votre ensemble de règle et à votre vitesse de processeur. Pour la plupart des applications utilisant ethernet et de petits ensembles de règles, la réponse est : négligeable. Pour tous ceux d'entre vous qui veulent des mesures actuelles pour satisfaire leur curiosité, continuez à lire : Les mesures suivantes ont été réalisées en utilisant 2.2.5-STABLE sur un 486-66. IPFW a été modifié pour mesurer le temps écoulé par l'intermédiaire de la routine _ip_fw_chk_ en affichant les résultats sur la console tous les 1000 paquets. 2 ensembles de règles, chacun avec 1000 règles ont été testés. Le premier ensemble a été conçu pour démontrer le scénario du pire des cas en répétant la règle : [.programlisting] .... ipfw add deny tcp from any to any 55555 .... Cela démontre le pire des cas en faisant que chaque paquet IPFW entraine l'exécution de la routine de vérification qui finallement décide que le paquet ne correspond pas aux règles (en vertu du numéro de port)? Apès la 999eme itération de cette règle, il y avait un _allow ip from any to any_. Le second ensemble de règles a été conçu pour annuler la vérification de règle très rapidement : [.programlisting] .... ipfw add deny ip from 1.2.3.4 to 1.2.3.4 .... Les adresses IP des sources non correspondantes aux règles énoncées ci-dessus font que ces règles sont sautées très rapidement. Comme auparavant, la 1000eme règle était un _allow ip from any to any_. L'étude par paquet dans le premier cas a été approximativement de 2.703ms/paquet, soit en gros 2.7 microseconds par règle . Ainsi, la limite théorique d'étude de paquet avec ces règles est de 370 paquets par secondes. En supposant un éthernet 10Mbps et des paquets d'environ 1500 bytes, nous ne pourrons être capable que d'obtenir une utilisation de la bande passante de 55.5% Pour le dernier cas, chaque paquet a été étudié en approximativement 1.172ms, soit en gros 1.2 microseconds par règle. La limite théorique de l'étude des paquets ici, serait d'environ de 853 paquets par secondes, ce qui pourrait consommer une bande passante d'un éthernet 10Mbps. Le nombre excessif de règle testés, et la nature de ces règles ne fournissent pas un scénario du monde réel -- ils ont été utilisés que pour générer les informations de temps présentés ici.Voici certaines choses à garder à l'esprit pour construire un ensemble de règles efficaces : * Placer une règle d'établissement très tôt afin de pouvoir gérer la majorité du trafic TCP. Ne mettre aucun _allow tcp_ avant cette règle. * Placer les règles souvent sollicitées le plus au début de l'ensemble des règles plutôt que celles rarement utilisées (_sans changer la permissivité du firewall _, bien sûr). Vous pourrez voir quels sont les règles les plus souvent utilisées en examinant les statistiques des comptages des paquets avec _ipfw -a l_. === Comment puis-je rediriger les requêtes de services d'une machine vers une autre ? Vous pouvez rediriger des requêtes FTP (et autre services) avec le paquetage 'socket', disponible dans l'arbre des ports dans la catégorie 'sysutils'. Remplacer simplement la ligne de commande de service pour appeler socket à la place, ainsi: [.programlisting] .... ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.foo.com ftp .... où 'ftp.foo.com' et 'ftp' sont les hôtes et les ports où se diriger respectivement. == Communications par port série. **Mise à jour en cours** Cette section comporte les réponses aux différentes questions sur la communication par port série sur FreeBSD. Les protocoles PPP et SLIP sont couverts dans la section Réseaux. === Comment savoir si FreeBSD a trouvé mes ports séries ? Lorsque FreeBSD démarre, il recherche les ports série sur votre machine qui sont configurés dans le noyau. Vous pouvez voir ces ports en regardant avec attention au moment du démarrage les messages affichés, ou en lançant la commande suivante: [.programlisting] .... dmesg | grep sio .... Lorsque votre système a démarré. Voici quelques exemples de l'affichage de la commande précédente. [.programlisting] .... sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A .... Vous voyez alors apparaitre deux ports série. Le premier se trouve à l'adresse [.filename]#0x3f8# sur l'IRQ 4 et est composé d'une puce de type 16550A. Le second est de meme type que le premier, mais se trouve lui à l'adresse [.filename]#0x2f8# sur l'IRQ 3. Les cartes modems internes sont traités comme des ports série -- sauf qu'ils ont toujours un modem sur le port. Le noyau _GENERIC_ comprends le support pour deux ports série dont les adresses et les IRQ sont les memes que celles ci-dessus. Si ces valeurs ne vous conviennent pas, ou si vous avez des cartes modems additionnelles ou des cartes série, reconfigurez un noyau. Voyez la section sur la reconstruction d'un noyau pour plus de détails. === Comment savoir si FreeBSD a trouvé mes cartes modems Référez vous à la section précédente === Je viens de mettre à jour ma machine en 2.0.5 et mes _tty0x_ ont diparus ! Ne vous inquitez pas, ils sont été remplacés par les devices _ttydX_. Vous devrez donc changer toutes vos anciennes configurations pour utiliser ces devices. === Comment accéder aux ports série sous FreeBSD ? Le troisième port série http://www.freebsd.org/cgi/man.cgi?sio[sio2 ](aussi appelé COM3 sous DOS), s'appelle _ /dev/cuaa2_ en sortie, et _ /dev/ttyd2 _ en entrée. Quelle est la différence entre ces deux classes de devices ? Vous devez utiliser _ ttydX _ pour des appels sortants. Lorsque vous ouvrez _ /dev/ttydX _ en mode bloquant, un processus attend, sur le device _ cuaaX _ correspondant, qu'il soit inactif, et attends alors de détecter la porteuse sur la ligne. Lorsque vous ouvrez le port _ cuaaX _, un processus vérifie déjà que le port _ ttydX _ correspondant est disponible. Si le port est disponible, alors il se l'approprie depuis le port _ ttydX _. Le port _ cuaaXX _ ne tient pas compte de la détection de porteuse. Graçe a cette fonctionnalité et un modem, vous pouvez avoir des utilisateurs se logguant sur votre machine tout en vous laissant appeller via le meme modem, c'est le système qui se préocupera de gérer les conflits. === Comment activer le support pour les cartes séries multiports Encore une fois, reportez vous à la section sur la configuration du noyau. Pour une carte série multiports placez une ligne http://www.freebsd.org/cgi/man.cgi?sio[sio] pour chaque port série de la carte dans le fichier de configuration du noyau. Ne mettez pour une valeur l'irq et le vecteur d'adresse de la carte. Tous les ports de la cartes doivent partager la même irq. Pour des raisons de cohérence, spécifiez l'irq pour le dernier port. N'oubliez pas d'ajouter l'option _ COM_MULTIPORT _. L'example suivant correspond à une carte série 4ports AST sur l'irq 7 [.programlisting] .... options "COM_MULTIPORT" device sio4 at isa? port 0x2a0 tty flags 0x781 device sio5 at isa? port 0x2a8 tty flags 0x781 device sio6 at isa? port 0x2b0 tty flags 0x781 device sio7 at isa? port 0x2b8 tty flags 0x781 irq 7 vector siointr .... Les drapeaux (flags) indiquent que le port maitre à un nombre mineur de 7 (_0x700_), que nous désirons afficher les diagnostics (_0x080_) et que tous les ports partagent la même irq (_0x001_). === Est-ce que FreeBSD sait gérer les cartes séries multiports en partageant les IRQ ? Pas pour le moment. Vous devez utiliser une IRQ différente pour chaque carte. === Puis-je définir les paramètres par défaut de la liaison série pour un port? Les périphériques _ ttydX _ (ou _cuaaX_) sont des périphériques normaux que vous pouvez ouvrir dans vos applications. Lorsqu'un processus ouvre le périphérique, il utilise les paramètres par défaut d'entrées sorties de terminal. Vous pouvez voir ces paramètres en utilisant la commande: [.programlisting] .... stty -a -f /dev/ttyd1 .... Lorsque vous changez les paramètres du périphérique, ces paramètres sont effectifs jusqu'au moment ou vous arreterez de vous servir de ce périphérique. S'il est ouvert de nouveau, il reprendra les paramètres par défaut. Pour changer les paramètres par défaut , vous devez ouvrir le périphérique et changer les paramètres de l'état initial du périphérique. Par exemple pour définit un mode _LOCAL_, 8 bits et un controle de flux _ XON/XOFF _ par défaut sur le ttyd5, voud devez : [.programlisting] .... stty -f /dev/ttyd5 clocal cs8 ixon ixoff .... Le mailleur endroit pour effectuer ceci est le fichier de démarrage [.filename]#/etc/rc.serial#. Maintenant lorsqu'une application ovrira _ ttyd5_ elle obtiendra les valeurs ci-dessus. Vous pouvez empecher certaines valeurs d'etre modifiées en utilisant le fonction de lock du périphérique. Par exemple pour forcer la vitesse à 57600bauds sur _ ttyd5 _: [.programlisting] .... stty -f /dev/ttyd5 57600 .... Maintenant lorsqu'un programme ouvrira _ttyd5_ et tentera de changer la vitesse du port, il obtiendra toujours 57600 bauds. Bien sur, vous devez laisser la possibilité de changer les états initiaux et de lock que pour l'utilisateur root. Le script http://www.freebsd.org/cgi/man.cgi?MAKEDEV[ MAKEDEV ]_ ne le fait pas _ par défaut lorsqu'il crée les noeuds. === Comment mettre en place un login dialup sur mon modem? Vous voulez devenir fournisseur d'accès à l'Internet ? Pour commencer vous devez disposer de plus d'un modem pouvant répondre automatiquement. Votre modem doit pouvoir detecter une émission de porteuse lorsque qu'elle se présente et ne doit pas en détecter constemment. Il doit aussi etre capable de racrocher la ligne lorsqu'il détecte le passage de 1 à 0 du signal _DTR_. Il doit aussi utiliser un controle de flux de type _ RTS/CTS _ ou aucun controle de flus. Enfin, il doit etre capable de négocier la vitesse de transmission entre lui-même et le modem distant tout en gardant une vitesse constante vis à vis de l'ordinateur. Pour la plupart des modems comprennant les commande Hayes, cette commande met en place les bonnes valeurs et les enregistre en mémoire morte: [.programlisting] .... AT &C1 &D3 &K3 &Q6 S0=1 &W .... Voyez la section sur l'envoi direct de commandes AT, pour savoir comment les mettre en place sans avoir besoin de lancer un émulateur de terminal sous MS-DOS. Ensuite créez une entrée dans http://www.freebsd.org/cgi/man.cgi?ttys[ /etc/ttys ] pour le modem. Ce fichier comporte tous les ports sur lesquels le système d'exploitation attend des commandes de login. Ajoutez une ligne ressemblant à celle ci: [.programlisting] .... ttyd1 "/usr/libexec/getty std.57600" dialup on insecure .... Cette ligne indique que sur le deuxième port série (_/dev/ttyd1_) est attaché un modem dialoguant à 57600 bauds sans parité (_std.57600_) se trouvant dans le fichier http://www.freebsd.org/cgi/man.cgi?gettytab[ /etc/gettytab ]). Le type de terminal est dialup. Le port est on et insecure -- ce qui veut dire que les logins sous root ne sont pas autorisés sur ce port. Pour utiliser d'autres ports en entrée, utilisez les autres entrées _ ttydX _. Il est d'usage courant d'utiliser dialup comme type de terminal. Beaucoup d'utilisateurs affichent un prompt dans leur .profile ou .login si le type de terminal est dialup. L'exemple ci-dessus affecte au port le mode insecure. Pour passer root, vous devez donc vous logguer en temps qu'utilisateur ordinaire et utiliser la commande http://www.freebsd.org/cgi/man.cgi?su[ su ] pour devenir _root_. Si vous définissez le port en tant que secure, alors vous pourrez vous logguer sous _root _ directement. Après avoir effectué les modifications au fichier http://www.freebsd.org/cgi/man.cgi?ttys[ /etc/ttys ], vous devez envoyer un signal _ HUP _ au processus http://www.freebsd.org/cgi/man.cgi?init[ init ] [.programlisting] .... kill -HUP 1 .... Cela force le processus init à relire le fichier http://www.freebsd.org/cgi/man.cgi?ttys[ /etc/ttys]. Le processus init démarrera donc des processus getty sur tous les ports marqués comme "on". Vous pouvez alors vérifiez que le login est possible sur le port en tapant : [.programlisting] .... ps -ax | grep '[t]tyd1' .... Et vous devez voir apparaitre quelque chose comme ceci: [.programlisting] .... 747 ?? I 0:00.04 /usr/libexec/getty std.57600 ttyd1 .... === Comment connecter un terminal sur mon système FreeBSD? Si vous utilisez un autre ordinateur en tant que terminal, vous devez vous procurer un cable null modem pour relier les deux ports série. Si vous utilisez un vrai terminal (de type WYSE-50), suivez les instructions du manuel Ensuite, modifez http://www.freebsd.org/cgi/man.cgi?ttys[ /etc/ttys] comme expliqué à la section précedente. Par exemple, pour un terminal WYSE-50 connecté sur le 5ème port série, utilisez une entrée ressemblant à la suivante: [.programlisting] .... ttyd4 "/usr/libexec/getty std.38400" wyse50 on secure .... Cet exemple assume que le port [.filename]#/dev/ttyd4# est connecté sur un terminal wyse50 à la vitesse de 38400 bauds sans parité (_std.38400_ se trouvant dans le fichier http://www.freebsd.org/cgi/man.cgi?gettytab[/etc/gettytab]) et les logins root sont permis (mot clé secure) === Pourquoi ne puis-je pas executer [.filename]#tip# ou [.filename]#cu#? Sur votre système, les programmes http://www.freebsd.org/cgi/man.cgi?tip[tip] et http://www.freebsd.org/cgi/man.cgi?cu[cu] ne sont probablement executable que par l'utilisateur http://www.freebsd.org/cgi/man.cgi?uucp[uucp] et par le groupe [.filename]#dialer#. Le groupe [.filename]#dialer# vous permet de controler qui a accès à votre modem ainsi qu'aux systèmes distants. Ajoutez vous dans ce groupe pour pouvoir utiliser ces commandes. Sinon, vous pouvez autoriser tous les utilisateurs de votre système à utiliser les programmes [.filename]#tip# et [.filename]#cu# en tapant: [.programlisting] .... # chmod 4511 /usr/bin/cu # chmod 4511 /usr/bin/tip .... === Mon modem Hayes n'est pas supporté; que dois-je faire ? Pour l'instant la page de manuel de http://www.freebsd.org/cgi/man.cgi?tip[tip] n'est pas à jour. Il existe un support générique des commandes Hayes intégré dans le programme. Il suffit de mettre la ligne suivante [.filename]#ar=hayes# dans votre fichier http://www.freebsd.org/cgi/man.cgi?remote[/etc/remote] Le gestionnaire Hayes ne sait pas reconnaitre les fonctions avancées des nouveaux modems. Des messages comme [.filename]#BUSY, NO DIALTONE, CONNECT 115200# ne sont pas reconnus. Vous devez absolument désactiver ces messages lorsque vous utilisez http://www.freebsd.org/cgi/man.cgi?tip[tip] (en tapant [.filename]#ATX0&W#). De plus le timeout de [.filename]#tip# est de 60 secondes. Votre modem doit absolument utiliser une valeur plus faible, sinon [.filename]#tip# pensera qu'il y a un problème de communication. Essayez la commande [.filename]#ATS7=45&W# Le version de [.filename]#tip# livrée ne comporte pas toutes ces fonctionnalités. La solution est d'éditer le fichier [.filename]#tipconf.h# se trouvant dans le répertoire [.filename]#/usr/src/usr.bin/tip/tip#. Bien sur cela nécessite que vous ayez installé les sources. Remplacez alors la ligne [.filename]#define HAYES0# par [.filename]#define HAYES 1#. Puis tapez [.filename]#make# et [.filename]#make install#. Tout doit marcher correctement après cela. === Comment faire pour entrer certaines commandes AT ? Créez une entrée de type [.filename]#direct# dans votre fichier http://www.freebsd.org/cgi/man.cgi?remote[/etc/remote]. Par exemple, si votre modem est attaché sur le premier port série, [.filename]#/dev/cuaa0#, ajoutez la ligne suivante: [.programlisting] .... cuaa0:dv=/dev/cuaa0:br#19200:pa=none .... Utilisez le taux maximum, de transfert de votre modem, pour la fonctionnalitée br. Ensuite tapez http://www.freebsd.org/cgi/man.cgi?tip[tip cuaa0] et vous serez alors connecté sur votre modem. S'il n'existe pas de fichier [.filename]#/dev/cuaa0# sur votre système, executez la commande suivante: [.programlisting] .... # cd /dev # ./MAKEDEV cuaa0 .... Sinon utilisez la commande [.filename]#cu# sous root de la façon suivante. [.programlisting] .... # cu -l``port'' -s``vitesse'' .... Avec "port" le nom du port série(ex: [.filename]#/dev/cuaa0#) et "vitesse"(la vitesse maximum de votre modem)(ex: [.filename]#57600#). Lorsque vous avez entrer les commandes AT apropriées, tapez [.filename]#~.# pour quitter === Le symbole [.filename]#@# pour la fonctionnalité pn ne marche pas! Le symbole [.filename]#@# dans le numéro de téléphone demande à [.filename]#tip# de regarder dans le fichier http://www.freebsd.org/cgi/man.cgi?phones(5)[ /etc/phones ] pour trouver le numéro aproprié. Mais le symbole [.filename]#@# est aussi un caractère spécial pour le fichier http://www.freebsd.org/cgi/man.cgi?remote[/etc/remote]. Mettez un backslash devant pour qu'il soit correctement interprété. [.programlisting] .... pn=\@ .... === Comment composer un numéro de téléphone depuis la ligne de commande? Mettez une ligne "[.filename]#generic#" dans le fichier http://www.freebsd.org/cgi/man.cgi?remote[/etc/remote]. Par exemple: [.programlisting] .... tip115200|Dial any phone number at 115200 bps:\ :dv=/dev/cuaa0:br#115200:at=hayes:pa=none:du: tip57600|Dial any phone number at 57600 bps:\ :dv=/dev/cuaa0:br#57600:at=hayes:pa=none:du: .... Vous pourrez alors utilisez la commande suivante "[.filename]#tip -115200 5551234#". Si vous préferez http://www.freebsd.org/cgi/man.cgi?cu[cu] à http://www.freebsd.org/cgi/man.cgi?tip[tip], utilisez une ligne générique pour cu: [.programlisting] .... cu115200|Use cu to dial any number at 115200bps:\ :dv=/dev/cuaa1:br#57600:at=hayes:pa=none:du: .... et utilisez la commande "[.filename]#cu 5551234 -s 115200#". === Dois-je spécifier la vitesse en bauds à chaque connexion Mettez une ligne [.filename]#tip1200# ou [.filename]#cu1200#, mais mettez la vitesse que vous voulez pour la fonctionnalité br.http://www.freebsd.org/cgi/man.cgi?tip[tip] pense que la vitesse par défaut est de 1200 bauds, donc il cherche une entrée "[.filename]#tip1200#". Bien sur, vous n'etes pas obligez d'utiliser cette vitesse. === J'ai accès à plusieurs machines depuis mon serveur de terminal Plutot que d'attendre d'etre connecté et de taper la commande [.filename]#CONNECT # chaque fois, utilisez la fonctionnalité [.filename]#cm# de tip. Voyez, par exemple, les entrèes suivantes du fichier http://www.freebsd.org/cgi/man.cgi?remote[/etc/remote]: [.programlisting] .... pain|pain.deep13.com|Forrester's machine:\ :cm=CONNECT pain\n:tc=deep13: muffin|muffin.deep13.com|Frank's machine:\ :cm=CONNECT muffin\n:tc=deep13: deep13:Gizmonics Institute terminal server:\ :dv=/dev/cua02:br#38400:at=hayes:du:pa=none:pn=5551234: .... Cela vous permet de taper directement [.filename]#tip pain# ou [.filename]#tip muffin# pour vous connectez sur les machines pain ou muffin, et [.filename]#tip deep13# pour accéder au serveur de terminaux. === Est-ce que tip peut utiliser plusieurs numéros de téléphones pour se connecter à un site? C'est un problème courant lorsqu'une université a plusieurs lignes pour les modems et plusieurs milliers d'étudiants qui les utilisent. Créez une ligne pour votre université dans le fichier http://www.freebsd.org/cgi/man.cgi?remote[/etc/remote] et utilisez [.filename]#\@# comme valeur pour la fonctionnalité [.filename]#pn#. [.programlisting] .... big-university:\ :pn=\@:tc=dialout dialout:\ :dv=/dev/cuaa3:br#9600:at=courier:du:pa=none: .... Ensuite listez tous les numéros de téléphones de l'université dans le fichier http://www.freebsd.org/cgi/man.cgi?phones[/etc/phones] [.programlisting] .... big-university 5551111 big-university 5551112 big-university 5551113 big-university 5551114 .... http://www.freebsd.org/cgi/man.cgi?tip[tip] essaiera alors tous les numéros de téléphones dans l'ordre de la liste puis s'arretera. Si vous voulez qu'il réessaye à l'infini, lancez [.filename]#tip# dans une boucle sans fin === Pourquoi dois-je appuyer deux fois sur CTRL+P pour envoyer un CRTL+P? CTRL+P est le caractère par défaut pour http://www.freebsd.org/cgi/man.cgi?tip[tip], pour lui dire que le caractère suivant est une donnée brute. Vous pouvez changez ce caractère en n'importe quel autre en utilisant la séquence d'échappement [.filename]#~s#, qui équivaut à "set a variable". Tapez "[.filename]#~sforce=#" suivit d'un saut de ligne. [.filename]## correspondant à un simple caractère.Si vous laissez [.filename]## vide, alors le caractère de force est le caractère nul, que vous pouvez obtenir par CTRL+2 ou CTRL+SPACE. La meilleur valeur pour ce caractère est SHIFT+CTRL+6, que je n'ai vu que utilisé que sur peu de terminaux. Vous pouvez affecter la valeur que vous voulez pour ce caractère en le spécifiant dans le fichier [.filename]#$HOME/.tiprc#: [.programlisting] .... force= .... === Tout d'un coup, tout ce que je tape est en majuscule? Vous devez avoir pressé CTRL+A, le caractère raise de http://www.freebsd.org/cgi/man.cgi?tip[tip], spécialement concus pour les gens n'ayant pas de caps-lock. Utilisez comme auparavant, [.filename]#~s#, et fixez la variable "raisechar" a une valeur plus raisonnable. En fait, vous pouvez le mettre à la meme valeur que le caractère de force, si vous ne désirez jamais utiliser ces fonctionnalités. Voici un exemple de fichier [.filename]#.tiprc# pour les utilisateurs d'Emacs qui utilisent beaucoup CTRL+2 et CTRL+A: [.programlisting] .... force=^^ raisechar=^^ .... Le caractère [.filename]#^^# correspond à SHIFT+CTRL+6. === Comment effectuer des transferts de fichiers en utilisant [.filename]#tip#? Si vous dialoguez avec un autre système UNIX, vous pouvez envoyer et recevoir des fichiers en utilisant la commande [.filename]#~p#(put) et [.filename]#~t#(take). Ces commandes utilisent les commandes http://www.freebsd.org/cgi/man.cgi?cat[cat] et http://www.freebsd.org/cgi/man.cgi?echo[echo] sur le système distant pour recevoir et envoyer les fichiers. La syntaxe de ces commandes est: [.programlisting] .... ~p [] ~t [] .... Il n'y a aucun controle d'erreur, donc il vaut mieux utiliser un autre protocol comme zmodem. === Comment dialoguer en zmodem avec [.filename]#tip#? Il faut, pour commencer, installer un des programmes zmodem depuis les ports(un de ceux de la catégorie comms http://www.freebsd.org/cgi/ports.cgi?^lrzsz[lrzsz] ou http://www.freebsd.org/cgi/ports.cgi?^rzsz[rzsz]). Pour recevoir un fichier, démarrez le programme d'envoi des données sur le système distant. Ensuite pressez entrée puis tapez "[.filename]#~C rz#" (ou "[.filename]#~C lrz#" si vous avez installé lrzsz) pour recevoir le fichier. Pour envoyer des fichiers, démarrez le programme de réception sur le système distant. Ensuite tapez entrée et tapez "[.filename]#~C sz #"(ou "[.filename]#~C lsz #") pour envoyer le fichier. === FreeBSD ne trouve pas mes ports séries, même avec les bonnes valeurs de configuration . Certaines cartes mères et les cartes comportant des Composants UART Acer, ne sont pas reconnues correctement par le programme de détection de FreeBSD. Un patch est disponible à http://www.lemis.com/serial-port-patch.html[ www.lemis.com ] pour résoudre votre problème. == Questions diverses. **Mise à jour en cours** === FreeBSD utilise beaucoup plus d'espace swap que Linux. pourquoi ? Non. Vous voulez peut-être dire "pourquoi mon swap semble être plein ?". Si cela est vraiment ce que vous voulez dire, c'est en fait parce que mettre les choses dans le swap plutôt que les mettre de côté rend toujours plus facile sa récupération que si le pager devait aller chercher à travers tout le système de fichier afin de récupérer des blocs propres (non modifié) d'un exécutable. La quantité actuelle de pages "sales" que vous pouvez avoir dans le noyau en même temps n'est pas réduit, les pages propres sont déplacées si nécessaires. === Pourquoi utiliser (qu'est-ce) a.out et les formats exécutables ELF ? Afin de comprendre pourquoi FreeBSD utilise le format _a.out_, vous devez d'abord savoir quelques trucs sur les 3 formats exécutables courant "dominants" pour UNIX : * http://www.freebsd.org/cgi/man.cgi?a.out(5)[a.out ] Le vieux et classique format des objets unix. Il utilise un court et compact en-tête avec un nombre magique au début, qui est souvent utilisé pour caractériser le format (voir http://www.freebsd.org/cgi/man.cgi?a.out(5)[a.out(5)] pour plus de détails). Il contient trois segments chargés : .text, .data, et .bss plus une table de symboles et une table de chaînes. * _COFF_ Le formats des objets SVR3. L'en-tête comprend une table de section, de telle sorte que vous avez plus de sections que juste .text, .data, et .bss. * _ELF_ Le successeur de _COFF_, qui permet des sections multiples et des valeurs possibles de 32 bits et 64 bits. Un inconvénient majeur : _ELF_ a aussi été conçu en supposant le fait qu'il y qu'un seul ABI par architecture système. Cette hypothèse est assez incorrecte, et même dans le monde SYSV (qui a au moins 2 ABIs : SVR4, Solaris, SCO) cela ne se vérifie pas. + FreeBSD essaye de contourner ce problème en fournissant un utilitaire pour _marquer_ un exécutable connu _ELF_ avec des informations sur l'ABI qui va avec. Regardez la page de manuel pour http://www.freebsd.org/cgi/man.cgi?brandelf[brandelf] pour plus d'informations. FreeBSD vient du camp "classique" et utilise traditionnellement le format http://www.freebsd.org/cgi/man.cgi?a.out(5)[a.out], une technologie esssayée et éprouvée à travers des générations de releases BSD. Bien qu'il a aussi été quelques fois possible de construire et de lancer des binaires natifs _ELF_ (et noyau) sur un système FreeBSD, FreeBSD a initiallement résisté à la "pression" de passer à _ELF_ comme format par défaut. Pourquoi ? Bien, quand le camp Linux ont fait leur difficile transition vers _ELF_, il ne suffisait pas de fuir le format exécutable _a.out_. mais leur mécanisme de librairies partagées basé sur des table de sauts inflexible ce qui rendait la construction de librairies partagées difficiles pour les vendeurs et développeurs. Depuis comme les outils _ELF_ offrent une solution au problème des librairies partagées et semblent en général perçus comme "la voie du progrès" de toute façon, le coût de migration a été entendu comme nécessaire, et la transition a été réalisée. Dans le cas FreeBSD, notre mécanisme de librairie partagée se rapproche plus des style de mécanisme de librairie partagée des _SunOS_ de Sun, et de la sorte, est très simple à utiliser. Quoiqu'il en soit, à partir de 3.0, FreeBSD supportera officiellement les binaires _ELF_ comme format par défaut. Même si les formats exécutables _a.out_ nous ont beaucoup servis, les gens du GNU auteurs des outils de compilation que nous utilisons ont arrêté leur supports pour le format _a.out_. Cela nous a forcé à maintenir des versions divergentes du compilateur et de l'éditeur de liens, et nous a empêché de bénéficier des derniers efforts du développement GNU. Et puis, les demandes de ISO-C++, notemment pour les constructeurs et les destructeurs, nous ont aussi conduit à supporter de l' _ELF_ natif pour les futures release de FreeBSD. === Pourquoi chmod ne veulent pas changer les permissions sur les liens symboliques ? Vous devez utiliser soit _-H_ ou _-L_ ensemble avec l'option _-R_ pour que cela marche. Regardez les pages de manuels de http://www.freebsd.org/cgi/man.cgi?chmod[chmod] et http://www.freebsd.org/cgi/man.cgi?symlink[symlink]. _ATTENTION_ l'option _-R_ fait un chmod _RECURSIF__chmod_. Faites attention en spécifiant le répertoire ou les liens symboliques vers les repertoires où vous lancerez _chmod_. Si vous voulez changer les permissions d'un répertoire référencé par un symlink, utiliser http://www.freebsd.org/cgi/man.cgi?chmod[chmod] sans aucune option et suivre le lien symbolique avec un slash final (_/_). Par exemple, si _foo_ est un lien symbolique vers le répertoire _bar_, et que vous voulez changer les permissions de _foo_ (actuellement _bar_), vous devrez sans doute faire quelque chose comme : [.programlisting] .... chmod 555 foo/ .... Avec un slash final, http://www.freebsd.org/cgi/man.cgi?chmod[chmod] suivra le lien symbolique, _foo_, pour changer les droits sur le répertoire _bar_. === Pourquoi les noms de logins sont _encore_ restreints à 8 caractères ? Vous pouvez penser qu'il est assez simple de changer _UT_NAMESIZE_ et de reconstruire tout le monde, et que tout marcherait. Malheureusement, il y a souvent une escouade d'applications et d'utilitaires (y compris les outils systèmes) qui ont codé en dur les petits nombres (pas toujours "8" ou "9", mais d'autres plus étranges comme "15" ou "20") dans les structures et les buffers. Non seulement cela vous donnera des fichiers logs qui seront altérés (à cause des longueurs des variables enregistrés là où des enregistrement de taille fixées sont attendus), mais cela peut planter les clients NIS de Sun, et potentiellement causer d'autres problèmes lors de l'interaction avec d'autres systèmes UNIX. Dans FreeBSD 3.0 et plus, la longueur maximale des noms a été augmentée à 16 caractères et tous ces divers utilitaires avec des tailles de noms codés en dur ont été trouvés et corrigés. Le fait que cela touche tant de domaines du système explique en fait pourquoi le changement n'a pas été fait avant la 3.0. Si vous êtes absolument confiant dans votre habileté à trouver et à corriger ces sortes de problèmes par vous-même quand ils arrivent, vous pouvez augmenter la taille des noms de login dans les releases précédentes en éditant /usr/include/utmp.h et en changeant en fonction de la taille que vous voulez donner, la variable UT_NAMESIZE. Vous devez aussi mettre à jour la variable MAXLOGNAME dans /usr/include/sys/param.h pour correspondre au changement de UT_NAMESIZE. Au final, si vous construisez depuis les sources, n'oubliez pas que /usr/include est mis à jour à chaque fois ! Changer les fichiers appropriés dans /usr/src/... à la place. === Puis-je lancer des binaires DOS sous FreeBSD? Oui, à partir de la version 3.0, vous pouvez utiliser _rundos_ l'émulateur DOS de BSDI, qui a été intégré et perfectionné. Envoyez un courrier électronique à link:mailto:freebsd-emulation@freebsd.org[ la liste de discussion sur les émulations de FreeBSD] si cela vous interesse de vous joindre à cet effort en progression. Pour les systèmes pre-3.0, il y a un bel utiltaire appelé http://www.freebsd.org/cgi/ports.cgi?^pcemu[pcemu] dans la collection de pports, qui émule un 8088 et assez de services BIOS pour pouvoir lancer des applications DOS en mode texte. Cela requiert le système X Windows (fourni comme XFree86). === Qu'est ce _sup_, et comment l'utilise je ? http://www.freebsd.org/cgi/ports.cgi?^sup[SUP] veut dire Software Update Protocol, et a été développé par CMU pour pouvoir synchroniser leurs arbres de développement. Nous l'utilisons pour garder les sites distants en synchronisation avec nos sources centraux de développement SUP n'est pas très ami avec la bande passante et a été retiré. La méthode actuelle recommandé pour pouvoir garder vos sources à jour est link:{handbook}#synching[Handbook entry on CVSup] === Jusqu'à quel point FreeBSD est-il cool ? [qanda] Quelqu'un a-t-il déjà fait des tests de température de FreeBSD ? Je sais que Linux tourne moins chaudement que DOS, mais je n'ai jamais vu aucune mention sur FreeBSD. Ca semble tourner vraiment très chaudement:: Non, mais nous avons effectué de nombreux tests gustatifs sur des volontaires ayant les yeux bandés et aussi 250 microgrammes de LSD-25 administré préalablement. 35%des volontaires ont dit que FreeBSD avait un goût d'orange, alors que Linux avait un goût de purple haze. Aucun des groupes n'a mentionné une variance de température particulière (si je me souviens bien). Nous avons de toute façon dû jeter tous les résultats quand nous nous sommes aperçu que de nombreux volontaires s'étaient promené en dehors de la salle durant les tests, faussant ainsi les résultats. Je pense que la plupart des volontaires sont à présent chez Apple, travaillant pour leur nouveau GUI 'scratch and sniff'. C'est un drôle de monde dans lequel nous vivons ! Sérieusement, FreeBSD et Linux utilisent tous les deux l'instruction _HLT_ (halt) quand le système est idle de telle sorte à baisser leur consommation d'énergie et donc la chaleur que cela génère. Et aussi, si vous avez APM (automatic power management) configuré, alors FreeBSD peut aussi mettre le CPU dans un mode basse énergie. === Qui est-ce qui fait grésiller mes banques mémoires ? [qanda] Y a t il quelque chose d'"étrange" que fait FreeBSD quand il compile le noyau qui pourrait faire que la mémoire fasse un grésillement ? Quand ça compile (et pour un bref moment après avoir reconnu le lecteur de disquette au démarrage), un étrange grésillement émane depuis ce qui semble être les banques mémoire:: Oui! Vous verrez des fréquentes références aux "démons" dans la documentation BSD, et ce que les gens ne savent pas, c'est que cela se réfère aux entités non-corporelle qui possède à présent votre ordinateur. Le grésillement venant de la mémoire est en fait le murmure échangé entre les démons lorsqu'ils débattent sur les différentes tâches de l'administration système. Si le bruit vous parvient, un bon _fdisk /mbr_ depuis le DOS vous en débarassera, mais ne soyez pas surpris s'il réagissent et qu'ils essayent de vous contrer. De plus, si jamais à un moment de l'opération, vous entendez la voix satanique de Bill Gates vous parvenant du haut-parleur interne, continuez, et ne regardez jamais en arrière ! Délivré de l'influence contre-balançante des démons BSD, les démons jumeaux de DOS et Windows pourront alors prendre le contrôle totale de votre machine jusqu'à la damnation éternelle de votre âme. S'il fallait choisir, je pense que je préfèrerais m'habituer au grésillement ! === Que veut dire 'MFC' ? MFC est un acronyme pour 'Merged From -CURRENT.' C'est utilisés dans les logs CVS pour noter quand un changement a migré depuis un CURRENT vers une branche STABLE == Pour les passionnés. **Mise à jour en cours** === Que sont les SNAP et RELEASE Il y a actuellement 3 branches actives/semi-actives dans http://www.freebsd.org/cgi/cvsweb.cgi[l'entrepot CVS] des sources de FreeBSD: * RELENG_2_1_0 encore appelée 2.1-stable ou branche 2.1 * RELENG_2_2 encore appelée 2.2-stable ou branche 2.2 * HEAD encore appelée -current ou 3.0-current HEAD n'est pas vraiment une branche, comparée aux deux autres, c'est juste une valeur symbolique constante pour désigner le répertoire de la version courante(ou version de développement), auquel nous nous référerons sous le nom de -current. Actuellement -current est la branche de développement de la version 3.0 résultant de la séparation de la branche 2.2-stable(RELENG_2_2) en Novembre 1996. La branche 2.1-stable, RELENG_2_1_0, s'étant séparée de -current en Septembre 1994. === Comment créer ma propre version Pour créer votre propre version, vous devez effectuer trois choses. Premièrement, vous devez avoir un noyau contenant le gestionnaire http://www.freebsd.org/cgi/man.cgi?vn[vn]. Ajoutez la ligne suivante au fichier de configuration du noyau, puis reconstruisez le. [.programlisting] .... pseudo-device vn #Vnode driver (turns a file into a device) .... Ensuite, vous devez disposer de l'arbre CVS au complet. Pour l'obtenir, vous pouvez utiliser link:{handbook}#synching[CVSUP] et remplissez votre fichier de configuration de cvsup de la façon suivante: [.programlisting] .... *default prefix=/home/ncvs *default base=/a *default host=cvsup.FreeBSD.org *default release=cvs *default delete compress use-rel-suffix ## Main Source Tree src-all src-eBones src-secure # Other stuff ports-all www doc-all .... Ensuite lancez la commande [.filename]#cvsup -g fichier_de_configuration_de_cvsup# pour rapatrier tous les sources sur votre machine Pour finir, vous devez disposez de beaucoup de place sur vos disque pour compiler le tout. Disons que cela se trouve dans le répertoire [.filename]#/tres/gros/systeme/de/fichiers# et que l'arbre CVS se trouve dans [.filename]#/home/ncvs# [.programlisting] .... setenv CVSROOT /home/ncvs # ou export CVSROOT=/hom/ncvs (pour du sh) cd /usr/src/release make release BUILDNAME=3.0-MY-SNAP CHROOTDIR=/tres/gros/systeme/de/fichiers .... Une distribution complète sera alors crée dans le répertoire [.filename]#/tres/gros/systeme/de/fichiers# et vous disposerez d'un programme d'installation ftp utilisant ce répertoire par défaut. Vous pouvez aussi décider de compiler autre chose que la version -current en donnant au paramètre [.filename]#RELEASETAG# une autre valeur. Par exemple pour compiler une version 2.2, il suffit de passer la valeur [.filename]#RELEASETAG=RELENG_2_2# à la ligne de commande de make. === Comment créer une disquette d'installation personnalisée? Le processus de création, des disquettes d'installation ainsi que des archives binaires, est automatisé par différentes cibles dans le fichier [.filename]#/usr/src/release/Makefile#. Ce fichier doit etre votre point de départ pour plus d'informations. Bien sur, cela veut dire que vous devrez faire un "make world" et que cela demande beaucoup d'espace disque et de temps. === "make world" remplace-t-il tous les binaires déja installés? Oui.Comme son nom le suggère,"make world" recompile tout le système depuis les sources, donc vous pouvez etre sur d'avoir un système sain et cohérent à la fin (cela peut prendre énormément de temps pour y arriver). Si la variable [.filename]#DESTDIR# est définie lorsque vous éxecutez "make world" ou "make install", les binaires seront installés dans la même arborescence que votre système sauf que la racine du nouveau système sera [.filename]#${DESTDIR}#. Différentes combinations dans la modification des librairies partagées et dans les programmes, peut entrainer une erreur du "make world". === Lorsque le système démarre, il affiche "(bus speed defaulted)" Les cartes SCSI Adaptec 1542 permettent d'accéder à la configuration de la vitesse du bus par logiciel. Les anciennes versions du gestionnaire de périphérique 1542 essayaient de déterminer la vitesse maximale utiliable et de configurer la carte à cette valeur. Nous avons trouvé que cela pouvait casser certains systèmes, donc vous devez définir l'option [.filename]#TUNE_1542# dans le fichier de configuration du noyau, pour que cela soit actif. En l'utilisant sur des systèmes ou la carte le supporte, cela vous permettra d'avoir une meilleur vitesse pour vos disques, mais sur des système ne le supportant pas vous obtiendrez des données corrompues. === Puis-je me tenir à jour par rapport à -current si j'ai un accès limité à l'Internet? Oui, vous pouvez le faire sans télécharger l'arbre complet des sources en utilisant la fonctionnalitée link:{handbook}#synching[CTM] === Comment faire pour couper la distribution en fichiers de 240Ko? Les systèmes BSD récents diposent d'une option "[.filename]#-b#" pour vous permettre de découper les fichiers binaires en plusieurs parties Voici un exemple, tiré de [.filename]#/usr/src/Makefile#. [.programlisting] .... bin-tarball: (cd ${DISTDIR}; \ tar cf - . \ gzip --no-name -9 -c | \ split -b 240640 - \ ${RELEASEDIR}/tarballs/bindist/bin_tgz.) .... === J'ai écrit une extension pour le noyau, comment l'incorporer? Regardez la partie du handbook sur la façon de link:{handbook}#contrib[soumettre du code] Et encore merci pour tout. === Comment sont détectées les cartes plugs and play ISA? Contribution de link:mailto:uhclem@nemesis.lonestar.org[Frank Durda IV] Il y a un certains nombres de ports d'entrées/sorties sur lesquels la plupart des cartes PnP répondent lorsqu'une machine interroge le bus ISA. Donc, lorsque la routine de détection PnP s'execute, elle interroge les cartes PnP sur ces ports pour savoir lesquelles sont présentes. Dans ce cas toutes les cartes répondent en indiquant leur modèle et la routine de détection reçoit alors une valeur qui est soit "oui" soit rien. Au minimum un bit est mis à 1 lors de la réponse. Alors le code de détection peut essayer de dialoguer avec les cartes, graçe aux numéros de modèle de cartes (définis par Microsoft/Intel), inférieurs à X pour leur dire de s'arréter. Il vérifie alors qu'aucune autre carte ne répond à la question précedente. Si la réponse est _0_ alors il considère qu'aucune carte n'a d'ID au dessus de X. Ensuite il interroge le bus pour obtenir la liste des cartes sous "X". S'il en trouve alors il interroge le bus pour avoir la liste des celles ayant un ID supérieur à X-(limit/4). Et répète ainsi de suite l'algorithme, qui consiste à diviser l'intervalle de recherche par deux. Avec cet algorithme, les cartes seront découvertes avec un maximum d'itération de 2^64. Les Identifiants de cartes sont codés sur 32 bits + 8 bit de checksum. Les 32 premiers bits représentent le code de la carte pour le constructeur de cette carte. Il arrive de trouver plusieurs cartes du meme constructeur ayant différents code de carte. L'idée de coder sur 32 bits le nom du constructeur serait un peu excessif. Les 32 bits de poids faibles sont le numéro de série de la carte; l'adresse ethernet , ou quelque chose rendant la carte unique par ce numéro. Le constructeur ne doit jamais produire une deuxième carte ayant ce meme numéro tout en ayant le meme nombre représenté sur les 32 premiers bits. Vous pouvez dons avoir plusieurs cartes du meme type dans votre ordinateur , et l'ensemble des 64 bits permet de rendre chacune unique. Les groupes de 32 bits ne peuvent en aucun cas etre tous à zéro. Cela permet d'effectuer le "OU" pour afficher les bits non nuls lors de la première recherche dicotomique. Lorsque le système à détecter toutes les cartes présentes, ils les réactivent une à une, et recherche les ressources dont elles ont besoin, quels sont les choix possibles pour les interruptions, etc. Un "scan" de toutes les cartes est effectué pour collecter toutes ces informations. Cette information est combinée avec l'information recueillie des fichiers ECU se trouvant sur le disque dur ou dans le BIOS. Le support ECU et BIOS du plug-and-play pour le matériel est très simple, et les périphérique n'ont pas besoin d'etre vraiment PnP. Mais en examinant les informations du BIOS et des fichiers ECU, les routines d'interrogations peuvent permettre aux périphériques PnP "to avoid those devices the probe code cannot relocate. " Alors les périphériques PnP sont encore interrogés, et renvoient leur IRQ, adresse mémoire, ports d'entrée/sorties et DMA. Les périphériques sont alors activés, en prenant en compte ces valeurs, et le reste jusqu'au prochaine redémarrage du système. Bien sur rien de vous empeche de les retirer, si le matériel le permet :-). Ceci n'explique pas toute la complexité de détection, mais c'est une explication simple du processus de détection. === Est-ce que FreeBSD va supporter d'autres architectures matérielles? -Différentes personnes sont interressées sur un support multi-architecture pour FreeBSD, et certaines personnes sont en train de porter FreeBSD sur la plateforme ALPHA, en coopération avec DEC. Pour plus d'informations sur les nouvelles architectures utilisez la mailling liste link:mailto:[] +Différentes personnes sont interressées sur un support multi-architecture pour FreeBSD, et certaines personnes sont en train de porter FreeBSD sur la plateforme ALPHA, en coopération avec DEC. Pour plus d'informations sur les nouvelles architectures utilisez la mailling liste link:mailto:freebsd-platforms@FreeBSD.ORG[] === J'ai besoin d'un "major number" pour un gestionnaire de périphérique que je viens d'écrire -Ceci dépend du fait que vous vouliez ou non rendre public ce gestionnaire. Si vous le désirez, envoyez nous une copie code source du gestionnaire et les modifications nécessaires à apporter au fichier [.filename]#files.i386#, un fichier de configuration et le code du fichier http://www.freebsd.org/cgi/man.cgi?MAKEDEV[MAKEDEV]nécessaire pour créer les fichiers spéciaux dont le gestionnaire à besoin. Si vous ne désirez pas rendre plublic le code, ou si vous ne pouvez pas à cause de certaines restrictions de votre license, alors utilisez le "major number" 32 (pour les gestionnaires de type caractère) et le "major number" 8 (pour les gestionnaires de type blocs), qui sont réservés à ce type de chose. Dans les deux cas nous sommes interessés par votre gestionnaire, discutez à son propos sur la mailling liste link:mailto:[]. +Ceci dépend du fait que vous vouliez ou non rendre public ce gestionnaire. Si vous le désirez, envoyez nous une copie code source du gestionnaire et les modifications nécessaires à apporter au fichier [.filename]#files.i386#, un fichier de configuration et le code du fichier http://www.freebsd.org/cgi/man.cgi?MAKEDEV[MAKEDEV]nécessaire pour créer les fichiers spéciaux dont le gestionnaire à besoin. Si vous ne désirez pas rendre plublic le code, ou si vous ne pouvez pas à cause de certaines restrictions de votre license, alors utilisez le "major number" 32 (pour les gestionnaires de type caractère) et le "major number" 8 (pour les gestionnaires de type blocs), qui sont réservés à ce type de chose. Dans les deux cas nous sommes interessés par votre gestionnaire, discutez à son propos sur la mailling liste link:mailto:freebsd-hackers@FreeBSD.ORG[]. == REMERCIEMENTS. **Mise à jour en cours** _Si vous voyez un problème avec cette FAQ, ou que vous voulez rajouter une entrée, mailez nous à Nous apprécions tout commentaire, et seul votre aide nous permettra d'améliorer cette FAQ !_ [.programlisting] .... FreeBSD Core Team .... [.programlisting] .... Version originale .... * Jordan Hubbard : Ocasionnellement des mises à jour et des corrections de la FAQ * Doug White : Les services ci-dessus et plus qu'il n'en faut sur freebsd-questions * Joerg Wunsch : Les services ci-dessus et plus qu'il n'en faut sur Usenet * Garrett Wollman : Réseaux et format * Jim Lowe : Informations Multicast * Peter da Silva : Tapage de la FAQ FreeBSD. * The FreeBSD Team : Soumission d'information... [.programlisting] .... L'équipe de traduction Francaise: .... * link:mailto:renaudbreard@telegroupe.fr[Renaud BREARD ] * link:mailto:brive@mail.dotcom.fr[Robert Brive] * link:mailto:gioria@francenet.fr[Sébastien GIORIA] * link:mailto:fhaby@club-internet.fr[Frédéric Haby] * link:mailto:Stephane.Legrand@bigfoot.com[Stéphane LEGRAND ] * link:mailto:nolin@mail.dotcom.fr[Philippe Nolin] * link:mailto:regnauld@deepo.prosa.dk[Philippe REGNAULD ] * link:mailto:ritsch_p@epita.fr[Pierre Yves RITSCHARD] * link:mailto:dntt@prism.uvsq.fr[Tuyêt Trâm DANG NGOC] Et pour tous les autres que nous avons oubliés, mille excuses, et merci de tout coeur ! diff --git a/documentation/content/pt-br/books/porters-handbook/makefiles/chapter.adoc b/documentation/content/pt-br/books/porters-handbook/makefiles/chapter.adoc index 58ff21596d..1cab2511ca 100644 --- a/documentation/content/pt-br/books/porters-handbook/makefiles/chapter.adoc +++ b/documentation/content/pt-br/books/porters-handbook/makefiles/chapter.adoc @@ -1,4800 +1,4800 @@ --- title: Capítulo 5. Configurando o Makefile prev: books/porters-handbook/slow-porting next: books/porters-handbook/special --- [[makefiles]] = Configurando o Makefile :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :source-highlighter: rouge :experimental: :skip-front-matter: :xrefstyle: basic :relfileprefix: ../ :outfilesuffix: :sectnumoffset: 5 :g-plus-plus: g++ :toc-title: Índice :table-caption: Tabela :figure-caption: Figura :example-caption: Exemplo include::shared/mirrors.adoc[] include::shared/authors.adoc[] include::shared/releases.adoc[] include::shared/pt-br/mailing-lists.adoc[] include::shared/pt-br/teams.adoc[] include::shared/pt-br/urls.adoc[] toc::[] Configurar o [.filename]#Makefile# é bastante simples e, novamente, sugerimos examinar os exemplos existentes antes de começar. Além disso, há um <> neste manual, então dê uma olhada e por favor siga a ordem das variáveis ​​e seções naquele modelo para tornar o port mais fácil para os outros lerem. Considere estes problemas em sequência durante o projeto do novo [.filename]#Makefile#: [[makefile-source]] == O Código Fonte Original Ele está em `DISTDIR` como um tarball `gzip` e é chamado de algo como [.filename]#foozolix-1.2.tar.gz#? Se assim for, vá para o próximo passo. Caso contrário, o formato do arquivo de distribuição pode necessitar da substituição de uma ou mais das variáveis `DISTVERSION`, `DISTNAME`, `EXTRACT_CMD`, `EXTRACT_BEFORE_ARGS`, `EXTRACT_AFTER_ARGS`, `EXTRACT_SUFX` ou `DISTFILES`. Na pior das hipóteses, crie um target personalizado `do-extract` para substituir o padrão. Isso raramente é necessário. [[makefile-naming]] === Nomeando A primeira parte do [.filename]#Makefile# do port o nomeia, descreve seu número de versão e o lista na categoria correta. [[makefile-portname]] === `PORTNAME` Setar `PORTNAME` ao nome base do software. Isso é usado como base para o pacote do FreeBSD, e para o <>. [IMPORTANT] ==== O nome do pacote deve ser único em toda a árvore de ports. Certifique-se de que o `PORTNAME` já não está em uso por um port existente, e que nenhum outro port já tem o mesmo `PKGBASE`. Se o nome já tiver sido usado, adicione <>. ==== [[makefile-versions]] === Versões, `DISTVERSION` ou `PORTVERSION` Setar `DISTVERSION` para o número da versão do software. `PORTVERSION` é a versão usada para o pacote do FreeBSD. Será automaticamente derivado de `DISTVERSION` para ser compatível com o esquema de versionamento de pacotes do FreeBSD. Se a versão contiver _letras_, pode ser necessário definir `PORTVERSION` e não `DISTVERSION`. [IMPORTANT] ==== Não é possível utilizar `PORTVERSION` e `DISTVERSION` juntos, deve ser ser definido um de cada vez. ==== De tempos em tempos, alguns softwares usam um esquema de versão que não é compatível em como o `DISTVERSION` traduz a versão no `PORTVERSION`. [TIP] ==== Ao atualizar um port, é possível usar o man:pkg-version[8]`-t` para verificar se a nova versão é maior ou menor do que antes. Veja <>. ==== [[makefile-versions-ex-pkg-version]] .Usando man:pkg-version[8] para comparar versões. [example] ==== `pkg version -t` recebe duas versões como argumentos, responderá com `<`, `=` ou `>` se a primeira versão for menor, igual ou maior que a segunda versão, respectivamente. [source,shell] .... % pkg version -t 1.2 1.3 < <.> % pkg version -t 1.2 1.2 = <.> % pkg version -t 1.2 1.2.0 = <.> % pkg version -t 1.2 1.2.p1 > <.> % pkg version -t 1.2.a1 1.2.b1 < <.> % pkg version -t 1.2 1.2p1 < <.> .... <.> `1.2` é menor que `1.3`. <.> `1.2` e `1.2` são iguais, pois têm a mesma versão. <.> `1.2` e `1.2.0` são iguais, pois valor vazio é igual a zero. <.> `1.2` é maior que `1.2.p1` por causa do `.p1`, pense em "pre-release 1". <.> `1.2.a1` é menor que `1.2.b1`, pense em "alfa" e "beta" e `a` é menor que `b`. <.> `1.2` é menor que `1.2p1` por causa do `2p1`, pense em "2, nível de patch 1" que é uma versão depois de qualquer `2.X` mas antes de `3`. [NOTE] ====== Aqui, `a`, `b` e `p` são usados ​​como se significassem "alfa", "beta" ou "pre-release" e "nível de patch", mas elas são apenas letras e são classificados por ordem alfabética, portanto, qualquer letra pode ser utilizada, e elas serão ordenadas de forma adequada. ====== ==== .Exemplos de `DISTVERSION` e de Derivações `PORTVERSION` [cols="1,1", frame="none", options="header"] |=== | DISTVERSION | PORTVERSION |0.7.1d |0.7.1.d |10Alpha3 |10.a3 |3Beta7-pre2 |3.b7.p2 |8:f_17 |8f.17 |=== [[makefile-versions-ex1]] .Usando `DISTVERSION` [example] ==== Quando a versão contém apenas números separados por pontos, traços ou sublinhados, use `DISTVERSION`. [.programlisting] .... PORTNAME= nekoto DISTVERSION= 1.2-4 .... Isso irá gerar um `PORTVERSION 1.2.4`. ==== [[makefile-versions-ex2]] .Usando `DISTVERSION` Quando a Versão Começa com uma Letra ou um Prefixo [example] ==== Quando a versão começa ou termina com uma letra, um prefixo ou um sufixo que não faz parte da versão, use `DISTVERSIONPREFIX`, `DISTVERSION` e `DISTVERSIONSUFFIX`. Se a versão for `v1.2-4`: [.programlisting] .... PORTNAME= nekoto DISTVERSIONPREFIX= v DISTVERSION= 1_2_4 .... Algumas vezes, projetos usando GitHub usará seu nome em suas versões. Por exemplo, a versão pode ser `nekoto-1.2-4`: [.programlisting] .... PORTNAME= nekoto DISTVERSIONPREFIX= nekoto- DISTVERSION= 1.2_4 .... Esses projetos também usam algumas strings no final da versão, por exemplo,`1.2-4_RELEASE`: [.programlisting] .... PORTNAME= nekoto DISTVERSION= 1.2-4 DISTVERSIONSUFFIX= _RELEASE .... Ou eles fazem ambos, por exemplo,`nekoto-1.2-4_RELEASE`: [.programlisting] .... PORTNAME= nekoto DISTVERSIONPREFIX= nekoto- DISTVERSION= 1.2-4 DISTVERSIONSUFFIX= _RELEASE .... `DISTVERSIONPREFIX` e `DISTVERSIONSUFFIX` não serão usados durante a construção do `PORTVERSION`, mas usado apenas em `DISTNAME`. Todos exemplos irão gerar um `PORTVERSION` com valor `1.2.4`. ==== [[makefile-versions-ex3]] .Usando `DISTVERSION` Quando a Versão Contém Letras Significando "alpha", "beta" ou "pre-release" [example] ==== Quando a versão contém números separados por pontos, traços ou underlines, e letras são usadas para significar "alpha", "beta" ou "pre-release", no sentido de que vem antes das versões sem letras, use `DISTVERSION`. [.programlisting] .... PORTNAME= nekoto DISTVERSION= 1.2-pre4 .... [.programlisting] .... PORTNAME= nekoto DISTVERSION= 1.2p4 .... Ambos irão gerar um `PORTVERSION` com valor `1.2.p4` que é menor do que 1.2. man:pkg-version[8] pode ser usado para verificar esse fato: [source,shell] .... % pkg version -t 1.2.p4 1.2 < .... ==== [[makefile-versions-ex4]] .Não use `DISTVERSION` Quando a Versão Contém Letras que Significam "Nível de Patch" [example] ==== Quando a versão contém letras que não significam "alpha", "beta" ou "pre", e estão mais para um "nível de patch", no sentido de que vem depois da versão sem as letras, use `PORTVERSION`. [.programlisting] .... PORTNAME= nekoto PORTVERSION= 1.2p4 .... Neste caso, usar `DISTVERSION` não é possível porque geraria uma versão `1.2.p4` o que seria menor que `1.2` e não maior.man:pkg-version[8] irá constatar isso: [source,shell] .... % pkg version -t 1.2 1.2.p4 > <.> % pkg version -t 1.2 1.2p4 < <.> .... <.> `1.2` é maior que `1.2.p4`, o que é _errado_ nesse caso. <.> `1.2` é menor que `1.2p4`, que é o que era necessário. ==== Para alguns exemplos mais avançados de configuração do `PORTVERSION`, quando a versão do software não é realmente compatível com o FreeBSD, ou `DISTNAME` quando o arquivo de distribuição não contém a versão em si, consulte <>. [[makefile-naming-revepoch]] === `PORTREVISION` e `PORTEPOCH` [[makefile-portrevision]] ==== `PORTREVISION` `PORTREVISION` é um valor monotonicamente crescente que é redefinido para 0 com cada incremento de `DISTVERSION`, normalmente toda vez que houver uma nova versão oficial do fornecedor. E se `PORTREVISION` é diferente de zero, o valor é anexado ao nome do pacote. Mudanças em `PORTREVISION` são usadas ​​por ferramentas automatizadas como man:pkg-version[8] para determinar se um novo pacote está disponível. `PORTREVISION` deve ser incrementado toda vez que uma alteração for feita no port onde se altera o pacote gerado de alguma forma. Isso inclui alterações que afetam apenas um pacote compilado com <> não padrão. Exemplos de quando `PORTREVISION` deve ser alterado: * Adição de correções para corrigir vulnerabilidades de segurança, bugs ou para adicionar novas funcionalidades ao port. * Alterações no [.filename]#Makefile# do port para ativar ou desativar as opções de tempo de compilação no pacote. * Alterações na lista de empacotamento ou no comportamento de tempo de instalação do pacote. Por exemplo, uma alteração em um script que gera dados iniciais para o pacote, como chaves de host man:ssh[1]. * Bump de versão da dependência de biblioteca compartilhada de um port (nesse caso, alguém tentando instalar o pacote antigo depois de instalar uma versão mais nova da dependência falhará, pois procurará a libfoo.x antiga em vez da libfoo.(x+1)). * Mudanças silenciosas no distfile do port que possuem diferenças funcionais significativas. Por exemplo, mudanças no distfile que requerem uma correção para [.filename]#distinfo# sem alteração correspondente para `DISTVERSION`, onde um `diff -ru` das versões antiga e nova mostra mudanças não triviais no código. Exemplos de alterações que não requerem uma alteração no `PORTREVISION`: * Mudanças de estilo no esqueleto do port sem alteração funcional ao que aparece no pacote resultante. * Mudanças para `MASTER_SITES` ou outras alterações funcionais no port que não afetem o pacote resultante. * Patches triviais para o distfile, como correção de erros de digitação, que não são importantes o suficiente para que os usuários do pacote tenham que se dar ao trabalho de atualizar. * Correções de compilação que fazem com que um pacote se torne compilável onde antes estava falhando. Desde que as alterações não introduzam nenhuma mudança funcional em nenhuma outra plataforma na qual o port tenha sido compilado anteriormente. `PORTREVISION` reflete o conteúdo do pacote, se o pacote não foi compilado anteriormente, então não há necessidade de incrementar o `PORTREVISION` para registrar uma mudança. Uma regra geral é decidir se a mudança em um port é algo que _algumas_ pessoas se beneficiariam em ter. Por causa de um aprimoramento, conserto ou em virtude de que o novo pacote funcione de fato. Em seguida, pondere que, de fato, isso fará com que todos que regularmente atualizam sua árvore de ports sejam obrigados a atualiza-lo. Se sim, `PORTREVISION` deve ser incrementado. [NOTE] ==== Pessoas usando pacotes binários _nunca_ verão a atualização se `PORTREVISION` não for incrementado. Sem incrementar `PORTREVISION`, os package builders não têm como detectar a alteração e, portanto, não irão recompilar o pacote. ==== [[makefile-portepoch]] ==== `PORTEPOCH` De tempos em tempos, um fornecedor de software ou um mantenedor de port do FreeBSD fazem algo tolo e lançam uma versão de seu software que é numericamente menor que a versão anterior. Um exemplo disso é um port que vai de foo-20000801 para foo-1.0 ( o primeiro será incorretamente tratado como uma versão mais nova, já que 20000801 é um valor numericamente maior que 1). [TIP] ==== Os resultados das comparações de números de versão nem sempre são óbvios. `pkg version` (veja man:pkg-version[8]) pode ser usado para testar a comparação de duas sequências de números de versão. Por exemplo: [source,shell] .... % pkg version -t 0.031 0.29 > .... A saida `>` indica que a versão 0.031 é considerada maior que a versão 0.29, o que pode não ter sido óbvio para o mantenedor do port. ==== Em situações como essa, `PORTEPOCH` deve ser incrementado. E se `PORTEPOCH` é diferente de zero, ele é anexado ao nome do pacote conforme descrito na seção 0 acima. `PORTEPOCH` nunca deve ser diminuído ou redefinido para zero, porque isso faria com que a comparação com um pacote de uma época anterior falhasse. Por exemplo, o pacote não seria detectado como desatualizado. O novo número da versão, `1.0.1` no exemplo acima, ainda é numericamente menor que a versão anterior, 20000801, mas o sufixo `1` é tratado especialmente por ferramentas automatizadas e considerado maior que o sufixo `0` implícito no pacote anterior. Remover ou resetar o `PORTEPOCH` incorretamente conduz ao luto eterno. Se a discussão acima não foi clara o suficiente, por favor consulte a http://lists.FreeBSD.org/mailman/listinfo/freebsd-ports[ Lista de discussão de ports do FreeBSD]. É esperado que `PORTEPOCH` não seja utilizado na maioria dos ports, e que seja feito o uso sensato do `DISTVERSION`, ou que o `PORTVERSION` seja usado com cuidado também, isso muitas vezes pode evitar que uma versão futura do software altere a estrutura da versão. No entanto, é necessário que os porters do FreeBSD tenham cuidado quando uma versão do fornecedor é feita sem um número de versão oficial - como um código de release "snapshot". A tentação é rotular a release com a data de lançamento, o que causará problemas como no exemplo acima, quando um novo release "oficial" é feito. Por exemplo, se um snapshot de release é feito na data `20000917` e a versão anterior do software era a versão `1.2`, não use `20000917` no `DISTVERSION`. A maneira correta é um `DISTVERSION` com valor `1.2.20000917`, ou similar, para que a próxima versão, digamos `1.3`, ainda seja um valor numericamente maior. [[makefile-portrevision-example]] ==== Exemplo de Uso `PORTREVISION` e `PORTEPOCH` O port `gtkmumble`, versão `0.10` está comitado na coleção de ports: [.programlisting] .... PORTNAME= gtkmumble DISTVERSION= 0.10 .... `PKGNAME` torna-se `gtkmumble-0.10`. Uma falha de segurança é descoberta, o que requer um patch local do FreeBSD. `PORTREVISION` é alterado de acordo. [.programlisting] .... PORTNAME= gtkmumble DISTVERSION= 0.10 PORTREVISION= 1 .... `PKGNAME` torna-se `gtkmumble-0.10_1` Uma nova versão é lançada pelo fornecedor, numerada como `0.2` (acontece que o autor realmente pretendia que `0.10` significa-se realmente `0.1.0`, não "o que vem depois de 0.9" - oops, tarde demais agora). Como a nova versão secundária `2` é numericamente menor que a versão anterior `10`, `PORTEPOCH` deve ser incrementado para forçar manualmente que o novo pacote seja detectado como "mais recente". Como é uma nova versão do fornecedor, `PORTREVISION` é redefinido para 0 (ou removido do [.filename]#Makefile#). [.programlisting] .... PORTNAME= gtkmumble DISTVERSION= 0.2 PORTEPOCH= 1 .... `PKGNAME` torna-se `gtkmumble-0.2,1` O próximo lançamento é 0.3. Desde que `PORTEPOCH` nunca diminua, as variáveis ​​de versão são agora: [.programlisting] .... PORTNAME= gtkmumble DISTVERSION= 0.3 PORTEPOCH= 1 .... `PKGNAME` torna-se `gtkmumble-0.3,1` [NOTE] ==== E se `PORTEPOCH` for redefinido para `0` com esta atualização, alguém que instalou o `gtkmumble-0.10_1` não detectaria o `gtkmumble-0.3` como pacote mais novo, desde que `3` ainda é numericamente menor que `10`. Lembre-se, este é o ponto principal de `PORTEPOCH` em primeiro lugar. ==== [[porting-pkgnameprefix-suffix]] === `PKGNAMEPREFIX` e `PKGNAMESUFFIX` Duas variáveis ​​opcionais, `PKGNAMEPREFIX` e `PKGNAMESUFFIX`, são combinadas com `PORTNAME` e `PORTVERSION` para formar `PKGNAME` como `${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}`. Certifique-se de que isto está de acordo com as nossas <>. Em particular, o uso de um hífen (`-`) dentro de `PORTVERSION` _não é_ permitido. Além disso, se o nome do pacote tiver o _language-_ ou a parte _-compiled.specifics_ (veja abaixo), use `PKGNAMEPREFIX` e `PKGNAMESUFFIX`, respectivamente. Não os faça parte de `PORTNAME`. [[porting-pkgname]] === Convenções de Nomenclatura de Pacotes Estas são as convenções a serem seguidas ao nomear pacotes. Isso é para facilitar a varredura do diretório de pacotes, já que existem milhares de pacotes e os usuários irão pegar ranço se eles machucarem seus olhos! Nomes de pacotes tomam a forma de [.filename]#language_region-name-compiled.specifics-version.numbers#. O nome do pacote é definido como `${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}`. Certifique-se de definir as variáveis ​​para estar em conformidade com esse formato. [[porting-pkgname-language]] [.filename]#language_region-#:: O FreeBSD se esforça para suportar a linguagem nativa de seus usuários. A parte _language-_ é uma abreviação de duas letras da linguagem natural definida pela ISO-639 quando o port é específico para um determinado idioma. Exemplos são `ja` para japonês, `ru` para russo,`vi` para vietnamita, `zh` para o chinês, `ko` para coreano e `de` para alemão. + Se o port for específico de uma determinada região dentro da área de idioma, adicione também o código do país de duas letras. Exemplos são `en_US` para Inglês dos EUA e `fr_CH` para o Francês Suíço. + A parte _language-_ é definida em `PKGNAMEPREFIX`. [[porting-pkgname-name]] [.filename]#name#:: Certifique-se de que o nome e a versão do port estejam claramente separados e colocados em `PORTNAME` e `DISTVERSION`. A única razão para `PORTNAME` conter uma parte da versão é se a distribuição upstream é realmente chamada dessa forma, como no package:textproc/libxml2[] ou package:japanese/kinput2-freewnn[]. De outra forma, `PORTNAME` não pode conter informações específicas da versão. É normal que vários ports tenham o mesmo `PORTNAME`, como os ports package:www/apache*[] fazem; Nesse caso, versões diferentes (e entradas de índice diferentes) são distinguidas por valores `PKGNAMEPREFIX` e `PKGNAMESUFFIX`. + Há uma tradição de nomear módulos `Perl 5` com sufixo `p5-` e convertendo o separador de dois pontos para um hífen. Por exemplo, o modulo `Data::Dumper` torna-se `p5-Data-Dumper`. [[porting-pkgname-compiled-specifics]] [.filename]#-compiled.specifics#:: Se o port pode ser construído com diferentes <> (geralmente parte do nome do diretório em uma família de ports), a parte _-compiled.specifics_ indica os padrões compilados. O hífen é opcional. Exemplos são tamanho de papel e unidades de fonte. + A parte _-compiled.specifics_ é definida em `PKGNAMESUFFIX`. [[porting-pkgname-version-numbers]] [.filename]#-version.numbers#:: A string da versão segue um hífen (`-`) e é uma lista separada por pontos de números inteiros e letras minúsculas. Em particular, não é permitido ter outro hífen dentro da string de versão. A única exceção é a string `pl` (significando "patchlevel"), que pode ser usado _apenas_ quando não há números de versão maiores e menores no software. Se a versão do software tiver sequências como "alpha", "beta", "rc" ou "pre", use a primeira letra e coloque imediatamente após um ponto. Se a sequência da versão continuar após esses nomes, os números seguirão o alfabeto simples sem um ponto extra entre eles (por exemplo,`1.0b2`). + A ideia é facilitar a classificação dos ports observando a string de versão. Em particular, certifique-se de que os componentes do número da versão estejam sempre delimitados por um ponto e, se a data fizer parte da string, use o formato `dyyyy.mm.dd`, não `dd.mm.yyyy` ou o não compatível com o formato Y2K `yy.mm.dd`. É importante prefixar a versão com uma letra, aqui `d` (para data), no caso de uma versão com um número de versão real, que seria numericamente inferior a `_yyyy_`. [IMPORTANT] ==== O nome do pacote deve ser único entre todos os ports, verifique se ainda não existe um port com o mesmo `PORTNAME` e se houver, adicione um dos <>. ==== Aqui estão alguns exemplos (reais) de como converter o nome como chamado pelos autores do software para um nome de pacote adequado, para cada linha, apenas um dos `DISTVERSION` ou `PORTVERSION` está definido, dependendo de qual seria usado no [.filename]#Makefile#: .Exemplos de Nomes de Pacotes [cols="1,1,1,1,1,1,1", frame="none", options="header"] |=== | Nome da Distribuição | PKGNAMEPREFIX | PORTNAME | PKGNAMESUFFIX | DISTVERSION | PORTVERSION | Razão ou comentário |mule-2.2.2 |(vazio) |mule |(vazio) |2.2.2 | |Nenhuma alteração é necessária |mule-1.0.1 |(vazio) |mule |1 |1.0.1 | |Esta é a versão 1 do mule e a versão 2 já existe |EmiClock-1.0.2 |(vazio) |emiclock |(vazio) |1.0.2 | |Sem nomes em maiúsculas para programas individuais |rdist-1.3alpha |(vazio) |rdist |(vazio) |1.3alfa | |Versão será `1.3.a` |es-0.9-beta1 |(vazio) |es |(vazio) |0.9-beta1 | |Versão será `0.9.b1` |mailman-2.0rc3 |(vazio) |mailman |(vazio) |2.0rc3 | |Versão será `2.0.r3` |v3.3beta021.src |(vazio) |tiff |(vazio) | |3.3 |O que diabos foi isso afinal? |tvtwm |(vazio) |tvtwm |(vazio) | |p11 |Nenhuma versão no nome do arquivo, use o que o upstream diz que é |piewm |(vazio) |piewm |(vazio) |1.0 | |Nenhuma versão no nome do arquivo, use o que o upstream diz que é |xvgr-2.10pl1 |(vazio) |xvgr |(vazio) | |2.10.pl1 |Nesse caso,`pl1` significa nível de patch, então usar DISTVERSION não é possível. |gawk-2.15.6 |ja- |gawk |(vazio) |2.15.6 | |Versão em japonês |psutils-1.13 |(vazio) |psutils |-letter |1.13 | |Tamanho do papel codificado no tempo de compilação do pacote |pkfonts |(vazio) |pkfonts |300 |1.0 | |Pacote para fontes de 300dpi |=== Se não houver absolutamente nenhum rastro de informações de versão co código fonte original e é improvável que o autor original vá liberar outra versão, basta definir a string de versão para `1.0` (como o exemplo `piewm` acima). Caso contrário, pergunte ao autor original ou use a string de data com valor de quando a código fonte foi lançado como (`dyyyy.mm.dd` ou `dyyyymmdd`) como a versão. [TIP] ==== Use qualquer letra. Aqui,`d` significa data, se o código for um repositório do Git, `g` seguido pela data de commit é normalmente utilizado, `s` para snapshot também é comum. ==== [[makefile-categories]] == Categorização [[makefile-categories-definition]] === `CATEGORIES` Quando um pacote é criado, ele é colocado em [.filename]#/usr/ports/packages/All# e links são feitos de um ou mais subdiretórios de [.filename]#/usr/ports/packages#. Os nomes desses subdiretórios são especificados pela variável `CATEGORIES`. O objetivo é facilitar a vida do usuário quando ele estiver vasculhando a pilha de pacotes no site FTP ou no CD-ROM. Por favor, dê uma olhada na <> e escolha as que são adequadas para o port. Esta lista também determina de onde, na árvore de ports, o port será importado. Se houver mais de uma categoria aqui, os arquivos do port devem ser colocados no subdiretório com o nome da primeira categoria. Veja <> para mais informação sobre como escolher as categorias certas. [[porting-categories]] === Lista Atual de Categorias Aqui está a lista atual de categorias de ports. As marcadas com um asterisco (`*`) são categorias _virtuais_ - aquelas que não possuem um subdiretório correspondente na árvore de ports. Elas são usadas ​​apenas como categorias secundárias e apenas para fins de pesquisa. [NOTE] ==== Para categorias não virtuais, há uma descrição de uma linha em `COMMENT` no [.filename]#Makefile# desse subdiretório. ==== [.informaltable] [cols="1,1,1", frame="none", options="header"] |=== | Categoria | Descrição | Notas |[.filename]#accessibility# |Ports para ajudar usuários com deficiências. | |[.filename]#afterstep# `*` |Ports para apoiar o gerenciador de janelas http://www.afterstep.org[AfterStep]. | |[.filename]#arabic# |Suporte ao idioma árabe". | |[.filename]#archivers# |Ferramentas de arquivamento. | |[.filename]#astro# |Ports astronômicos. | |[.filename]#audio# |Suporte de som. | |[.filename]#benchmarks# |Utilitários de benchmarking. | |[.filename]#biology# |Software relacionado à biologia. | |[.filename]#cad# |Ferramentas de desenho assistidas por computador. | |[.filename]#chinese# |Suporte ao idioma chinês. | |[.filename]#comms# |Software de comunicação. |Principalmente software para falar com o port serial. |[.filename]#converters# |Conversores de código de caracteres. | |[.filename]#databases# |Bancos de dados. | |[.filename]#deskutils# |Coisas que costumavam estar na área de trabalho antes dos computadores serem inventados. | |[.filename]#devel# |Utilitários de desenvolvimento. |Não coloque bibliotecas aqui só porque são bibliotecas. Elas _não deveriam_ estar nesta categoria, a menos que elas realmente não pertençam a nenhum outro lugar. |[.filename]#dns# |Software relacionado ao DNS. | |[.filename]#docs# `*` |Meta-ports para documentação do FreeBSD. | |[.filename]#editors# |Editores gerais. |Editores especializados entram na seção para essas ferramentas. Por exemplo, um editor de fórmula matemática [.filename]#math#, e tem [.filename]#editores# como uma segunda categoria. |[.filename]#elisp# `*` |Emacs-lisp ports. | |[.filename]#emulators# |Emuladores para outros sistemas operacionais. |Emuladores de terminal _não_ estão aqui. Os baseados em X vão para o [.filename]#x11# e baseados em texto para qualquer [.filename]#comms# ou [.filename]#misc#, dependendo da funcionalidade exata. |[.filename]#enlightenment# `*` |Ports relacionados com o gerenciador de janelas Enlightenment. | |[.filename]#finance# |Aplicações monetárias, financeiras e relacionadas. | |[.filename]#french# |Suporte ao idioma francês. | |[.filename]#ftp# |Utilitários de cliente e servidor deFTP. |Se o port fala com FTP e HTTP, coloque-o em [.filename]#ftp# com uma categoria secundária de [.filename]#www#. |[.filename]#games# |Jogos. | |[.filename]#geography# `*` |Software relacionado à geografia. | |[.filename]#german# |Suporte ao idioma alemão. | |[.filename]#gnome# `*` |Ports do Projeto http://www.gnome.org[GNOME]. | |[.filename]#gnustep# `*` |Software relacionado ao ambiente de desktop GNUstep. | |[.filename]#graphics# |Utilitários gráficos. | |[.filename]#hamradio# `*` |Software para rádio amador. | |[.filename]#haskell# `*` |Software relacionado à linguagem Haskell. | |[.filename]#hebrew# |Suporte ao idioma hebraico. | |[.filename]#hungarian# |Suporte de idioma húngaro. | |[.filename]#irc# |Utilitários do Internet Relay Chat. | |[.filename]#japanese# |Suporte ao idioma japonês. | |[.filename]#java# |Software relacionado à linguagem Java(TM). |A categoria [.filename]#Java# não deve ser única para um port. Salvo para ports diretamente relacionadas à linguagem Java, os mantenedores de ports também são encorajados a não usar [.filename]#Java# como a principal categoria de um port. |[.filename]#kde# `*` |Ports do Projeto http://www.kde.org[KDE] (genérico). | |[.filename]#kde-applications# `*` |Aplicações do Projeto http://www.kde.org[KDE]. | |[.filename]#kde-frameworks# `*` |Bibliotecas add-on do Projeto http://www.kde.org[KDE] para programação com Qt. | |[.filename]#kde-plasma# `*` |Desktop do Projeto http://www.kde.org[KDE]. | |[.filename]#kld# `*` |Módulos carregáveis ​​do kernel. | |[.filename]#korean# |Suporte ao idioma coreano. | |[.filename]#lang# |Linguagens de programação. | |[.filename]#linux# `*` |Aplicações Linux e utilitários de suporte. | |[.filename]#lisp# `*` |Software relacionado à linguagem Lisp. | |[.filename]#mail# |Mail software. | |[.filename]#mate# `*` |Ports relacionado ao ambiente de desktop MATE, um fork do GNOME 2. | |[.filename]#math# |Software de computação numérica e outras utilidades para matemática. | |[.filename]#mbone# `*` |Aplicações MBone. | |[.filename]#misc# |Utilitários diversos |Coisas que não pertencem em nenhum outro lugar. Se possível, tente encontrar uma categoria melhor para o port do que `misc`, como os ports tendem a ser negligenciados aqui. |[.filename]#multimedia# |Software multimídia. | |[.filename]#net# |Software de rede diversos. | |[.filename]#net-im# |Software de mensagens instantâneas. | |[.filename]#net-mgmt# |Software de gerenciamento de rede. | |[.filename]#net-p2p# |Aplicativos de rede peer to peer. | |[.filename]#net-vpn# `*` |Aplicativos de Rede Privada Virtual. | |[.filename]#news# |Software de notícias USENET. | |[.filename]#parallel# `*` |Aplicativos que lidam com o paralelismo na computação. | |[.filename]#pear# `*` |Ports relacionados ao framework PHP Pear. | |[.filename]#perl5# `*` |Ports que exigem Perl versão 5 para rodar. | |[.filename]#plan9# `*` |Vários programas de http://www.cs.bell-labs.com/plan9dist/[Plan9]. | |[.filename]#polish# |Suporte ao idioma polonês". | |[.filename]#ports-mgmt# |Ports para gerenciar, instalar e desenvolver ports e pacotes do FreeBSD. | |[.filename]#portuguese# |Suporte ao idioma Português. | |[.filename]#print# |Software de Impressão. |As ferramentas de editoração eletrônica (pré-visualizadores etc.) também pertencem aqui. |[.filename]#python# `*` |Software relacionado a linguagem http://www.python.org/[Python]. | |[.filename]#ruby# `*` |Software relacionado a linguagem http://www.ruby-lang.org/[Ruby]. | |[.filename]#rubygems# `*` |Ports de pacotes http://www.rubygems.org/[RubyGems]. | |[.filename]#russian# |Suporte de idioma russo. | |[.filename]#scheme# `*` |Software relacionado à linguagem Scheme. | |[.filename]#science# |Ports científicos que não se encaixam em outras categorias, como [.filename]#astro#, [.filename]#biologia# e [.filename]#matemática#. | |[.filename]#security# |Utilitários de segurança. | |[.filename]#shells# |Linha de comando do shell. | |[.filename]#spanish# `*` |Suporte ao idioma espanhol. | |[.filename]#sysutils# |Utilidades do sistema. | |[.filename]#tcl# `*` |Ports que usam o Tcl para rodar. | |[.filename]#textproc# |Utilitários de processamento de texto. |Não inclui ferramentas de editoração eletrônica, que vão para [.filename]#print#. |[.filename]#tk# `*` |Ports que usam o Tk para rodar. | |[.filename]#ukrainian# |Suporte de idioma Ucraniano. | |[.filename]#vietnamese# |Suporte de idioma Vietnamita. | |[.filename]#wayland# `*` |Ports para suportar o servidor de display Wayland. | |[.filename]#windowmaker# `*` |Ports para suportar o gerenciador de janelas do WindowMaker. | |[.filename]#www# |Software relacionado à World Wide Web. |O suporte ao idioma HTML também pertence aqui. |[.filename]#x11# |O X Window System e seus amigos. |Esta categoria é apenas para software que suporta diretamente o sistema de janelas. Não coloque aplicativos regulares do X aqui. A maioria deles é usada em outras categorias [.filename]#x11- *# (veja abaixo). |[.filename]#x11-clocks# |X11 relógios. | |[.filename]#x11-drivers# |Drivers X11. | |[.filename]#x11-fm# |Gerentes de arquivos X11. | |[.filename]#x11-fonts# |Fontes X11 e utilitários de fonte. | |[.filename]#x11-servers# |Servidores X11. | |[.filename]#x11-themes# |X11 temas. | |[.filename]#x11-toolkits# |Kits de ferramentas X11. | |[.filename]#x11-wm# |Gerentes de janela do X11. | |[.filename]#xfce# `*` |Ports relacionados com o ambiente de trabalho http://www.xfce.org/[Xfce]. | |[.filename]#zope# `*` |http://www.zope.org/[Zope] suporte. | |=== [[choosing-categories]] === Escolhendo a Categoria Correta Como muitas das categorias se sobrepõem, escolher qual das categorias será a principal categoria do port pode ser entediante. Existem várias regras que governam essa questão. Aqui está a lista de prioridades, em ordem decrescente de precedência: * A primeira categoria deve ser uma categoria física (veja <>). Isso é necessário para o empacotamento funcionar. Categorias virtuais e categorias físicas podem ser misturadas depois disso. * As categorias específicas de idioma sempre vêm em primeiro lugar. Por exemplo, se o port instalar fontes X11 em japonês, a linha `CATEGORIES` deve ser [.filename]#japanese x11-fonts#. * Categorias específicas são listadas antes de outras menos específicas. Por exemplo, um editor de HTML é listado como [.filename]#www editors#, e não ao contrário. Além disso, não insira [.filename]#net# quando o port pertencer a qualquer uma das categorias [.filename]#irc#, [.filename]#mail#, [.filename]#news#, [.filename]#security# ou [.filename]#www#, pois [.filename]#net# está incluída implicitamente. * [.filename]#x11# é usado como uma categoria secundária somente quando a categoria principal é uma linguagem natural. Em particular, não coloque [.filename]#x11# na linha de categoria em aplicações X. * Os modes Emacs são colocados na mesma categoria de ports que a aplicação suportada pelo mode, e não em [.filename]#editors#. Por exemplo, um mode Emacs para editar código fonte de alguma linguagem de programação entra em [.filename]#lang#. * Ports que instalam módulos do kernel carregáveis ​​também têm a categoria virtual [.filename]#kld# na sua linha `CATEGORIES`. Esta é uma das coisas tratadas automaticamente adicionando `USES=kmod`. * [.filename]#misc# não aparece com nenhuma outra categoria não virtual. Se houver `misc` com outra categoria na linha `CATEGORIES`, isso significa que `misc` pode ser seguramente excluído e o port colocado apenas no outro subdiretório. * Se o port realmente não pertencer em nenhum outro lugar, coloque-o em [.filename]#misc#. Se a categoria não estiver claramente definida, por favor, insira um comentário sobre isso na submissão https://bugs.freebsd.org/submit/[do port] no banco de dados de bugs, para que possamos discuti-lo antes de importá-lo. Como committer, envie uma mensagem para a http://lists.FreeBSD.org/mailman/listinfo/freebsd-ports[lista de discussão de ports do FreeBSD], para podermos discutir isso primeiro. Com muita frequência, novos ports são importados na categoria errada, e depois são movidos imediatamente para a categoria correta. [[proposing-categories]] === Propondo uma Nova Categoria Como a Coleção de Ports vem crescendo com o tempo, várias novas categorias também são adicionadas. Novas categorias podem ser categorias _virtuais_- aquelas que não possuem um subdiretório correspondente na árvore de ports - ou _físicas_ - aquelas que possuem. Esta seção discute os problemas envolvidos na criação de uma nova categoria física. Leia atentamente antes de propor uma nova. Nossa prática atual tem sido a de evitar a criação de uma nova categoria física, a menos que um grande número de ports logicamente pertençam a ela, ou os ports que pertenceriam a ela sejam um grupo logicamente distinto de interesse geral limitado (por exemplo, categorias relacionadas com as línguas humanas faladas), ou de preferência ambas. A razão para isto é que tal mudança cria uma link:{committers-guide}#ports[quantidade grande de trabalho] tanto para os committers quanto para todos os usuários que rastreiam alterações na coleção de ports. Além disso, propostas de alteração de categorias parecem naturalmente atrair controvérsias. (Talvez isso seja porque não há um consenso claro sobre quando uma categoria é "grande o suficiente", nem quando as categorias devem ser apenas para propósitos de busca (e, portanto, qual número de categorias seria um número ideal), e assim por diante.) Aqui está o procedimento: [.procedure] ==== . Proponha a nova categoria na http://lists.FreeBSD.org/mailman/listinfo/freebsd-ports[lista de discussão de ports do FreeBSD]. Inclua uma justificativa detalhada para a nova categoria, incluindo por que as categorias existentes não são suficientes, e a lista de ports existentes propostos para a mudança. (Se houver novos ports pendentes no Bugzilla que caberia nessa categoria, liste-os também.) Se você for o mantenedor e/ou o apresentador, respectivamente, mencione isso, pois isso pode ajudar no caso. . Participe da discussão. . Se parecer que há apoio o suficiente para a ideia, registre um PR que inclua a lógica e a lista de ports existentes que precisam ser movidos. O ideal é que este PR também inclua essas alterações: ** [.filename]##Makefile##s para os novos ports, uma vez que sejam recopiados ** [.filename]#Makefile# para a nova categoria ** [.filename]#Makefile# para as categorias dos ports antigos ** [.filename]##Makefile##s para ports que dependem dos ports antigos ** (para crédito extra, inclua os outros arquivos que precisam ser alterados, conforme o procedimento no Guia do Committer.) . Como isso afeta a infraestrutura do ports e envolve a movimentação e alteração de vários ports, pode ser necessário executar testes de regressão no cluster de build, e portanto, atribua o PR para a Equipe de Gerenciamento de Ports mailto:portmgr@FreeBSD.org[portmgr@FreeBSD.org]. . Se esse PR for aprovado, um committer precisará seguir o restante do procedimento que é link:{committers-guide}#PORTS[descrito no Guia do Committer]. ==== A proposta de uma nova categoria virtual é semelhante à acima, mas muito menos trabalhoso, já que nenhum port terá que ser movido. Nesse caso, os únicos patches a serem incluídos no PR serão aqueles para adicionar a nova categoria na linha `CATEGORIES` dos ports afetados. [[proposing-reorg]] === Propondo Reorganizar Todas as Categorias Ocasionalmente alguém propõe reorganizar as categorias com uma estrutura de dois níveis, ou algum outro tipo de estrutura de palavras-chave. Até o momento, nada vem de nenhuma dessas propostas porque, embora sejam muito fáceis de fazer, o esforço envolvido com qualquer readequação de toda a coleção de ports existente é assustadora, para se dizer o mínimo. Por favor, leia o histórico dessas propostas nos arquivos da lista de discussão antes de postar essa idéia. Além disso, esteja preparado para ser desafiado a oferecer um protótipo funcional. [[makefile-distfiles]] == Os Arquivos de Distribuição A segunda parte do [.filename]#Makefile# descreve os arquivos que devem ser baixados para compilar o port e onde eles podem ser baixados. [[makefile-distname]] === `DISTNAME` `DISTNAME` é o nome do port, conforme chamado pelos autores do software. `DISTNAME` é derivado de `${PORTNAME}-${DISTVERSIONPREFIX}${DISTVERSION}${DISTVERSIONSUFFIX}`, e se não estiver definido, `DISTVERSION` é derivado de `${PORTVERSION}`, portanto altere `DISTNAME` somente se necessário. `DISTNAME` é usado apenas em dois lugares. Primeiro, na lista de arquivos de distribuição (`DISTFILES`) padrão para `${DISTNAME} ${EXTRACT_SUFX}`. Em segundo lugar, espera-se que o arquivo de distribuição seja extraído em um subdiretório denominado `WRKSRC`, cujo padrão é [.filename]#work/${DISTNAME}#. Alguns nomes de distribuição de fornecedores que não se encaixam no `${PORTNAME}-${PORTVERSION}`-scheme podem ser tratados automaticamente configurando `DISTVERSIONPREFIX`, `DISTVERSION` e `DISTVERSIONSUFFIX`. `PORTVERSION` será derivado de `DISTVERSION` automaticamente. [IMPORTANT] ==== Apenas um dos `PORTVERSION` e `DISTVERSION` pode ser definido de cada vez. E se `DISTVERSION` não derivar um `PORTVERSION` correto, não use `DISTVERSION`. ==== Se o esquema de versão upstream puder ser derivado em um esquema de versão compatível com o ports, defina uma variável para a versão upstream, _não_ use `DISTVERSION` como o nome da variável. Defina `PORTVERSION` para a versão computada com base na variável criada, e defina `DISTNAME` adequadamente. Se o esquema de versão upstream não puder ser facilmente configurado para um valor compatível com o ports, defina `PORTVERSION` para um valor sensato, e defina `DISTNAME` com `PORTNAME` com a versão literal do upstream. [[makefile-distname-ex1]] .Derivando `PORTVERSION` Manualmente [example] ==== BIND9 usa um esquema de versão que não é compatível com as versões de ports (tem `-` em suas versões) e não pode ser derivado usando `DISTVERSION` porque após a versão 9.9.9, será lançado "patchlevels" na forma `9.9.9-P1`. DISTVERSION iria traduzir isso para `9.9.9.p1`, que no esquema de versionamento de ports significa 9.9.9 pré-release 1, que vem antes de 9.9.9 e não depois. Assim `PORTVERSION` é derivado manualmente de uma variável `ISCVERSION` para retornar `9.9.9p1`. A ordem na qual o framework do ports e o pkg ordenará as versões, é verificada usando o argumento `-t` do man:pkg-version[8]: [source,shell] .... % pkg version -t 9.9.9 9.9.9.p1 > <.> % pkg version -t 9.9.9 9.9.9p1 < <.> .... <.> O sinal `>` significa que o primeiro argumento passado em `-t` é maior que o segundo argumento. `9.9.9` é maior que `9.9.9.p1`. <.> O sinal `<` significa que o primeiro argumento passado em `-t` é menor que o segundo argumento. `9.9.9` é menor que `9.9.9p1`. No [.filename]#Makefile# do port, por exemplo package:dns/bind99[], é alcançado por: [.programlisting] .... PORTNAME= bind PORTVERSION= ${ISCVERSION:S/-P/P/:S/b/.b/:S/a/.a/:S/rc/.rc/} <.> CATEGORIES= dns net MASTER_SITES= ISC/bind9/${ISCVERSION} <.> PKGNAMESUFFIX= 99 DISTNAME= ${PORTNAME}-${ISCVERSION} <.> MAINTAINER= mat@FreeBSD.org COMMENT= BIND DNS suite with updated DNSSEC and DNS64 LICENSE= ISCL # ISC releases things like 9.8.0-P1 or 9.8.1rc1, which our versioning does not like ISCVERSION= 9.9.9-P6 <.> .... <.> Defina a versão upstream em `ISCVERSION`, com um comentário dizendo _porque_ é necessário. <.> Use `ISCVERSION` para obter um `PORTVERSION` compatível com o ports. <.> Use `ISCVERSION` diretamente para obter a URL correta para baixar o arquivo de distribuição. <.> Use `ISCVERSION` diretamente para nomear o arquivo de distribuição. ==== [[makefile-distname-ex2]] .Derivar `DISTNAME` a partir de `PORTVERSION` [example] ==== De tempos em tempos, o nome do arquivo de distribuição tem pouca ou nenhuma relação com a versão do software. No package:comms/kermit[], apenas o último elemento da versão está presente no arquivo de distribuição: [.programlisting] .... PORTNAME= kermit PORTVERSION= 9.0.304 CATEGORIES= comms ftp net MASTER_SITES= ftp://ftp.kermitproject.org/kermit/test/tar/ DISTNAME= cku${PORTVERSION:E}-dev20 <.> .... <.> O modificador `:E` man:make[1] retorna o sufixo da variável, neste caso, `304`. O arquivo de distribuição `cku304-dev20.tar.gz` é gerado corretamente. ==== [[makefile-distname-ex3]] .Caso Exótico 1 [example] ==== Às vezes, não há relação entre o nome do software, sua versão e o arquivo de distribuição no qual ele é distribuído. Do package:audio/libworkman[]: [.programlisting] .... PORTNAME= libworkman PORTVERSION= 1.4 CATEGORIES= audio MASTER_SITES= LOCAL/jim DISTNAME= ${PORTNAME}-1999-06-20 .... ==== [[makefile-distname-ex4]] .Caso Exótico 2 [example] ==== No package:comms/librs232[], o arquivo de distribuição não é versionado, portanto, <> é necessário: [.programlisting] .... PORTNAME= librs232 PORTVERSION= 20160710 CATEGORIES= comms MASTER_SITES= http://www.teuniz.net/RS-232/ DISTNAME= RS-232 DIST_SUBDIR= ${PORTNAME}-${PORTVERSION} .... ==== [NOTE] ==== `PKGNAMEPREFIX` e `PKGNAMESUFFIX` não afetam o `DISTNAME`. Observe também que se `WRKSRC` for igual a [.filename]#${WRKDIR}/${DISTNAME}# enquanto o arquivo fonte original é nomeado para algo diferente de `${PORTNAME}-${PORTVERSION}${EXTRACT_SUFX}`, deixe `DISTNAME` sozinho-- definir apenas `DISTFILES` é mais fácil que ambos `DISTNAME` e `WRKSRC` (e possivelmente `EXTRACT_SUFX`). ==== [[makefile-master_sites]] === `MASTER_SITES` Grave a parte do diretório do FTP/HTTP-URL apontando para o tarball original em `MASTER_SITES`. Não esqueça a barra final ([.filename]#/#)! A macro `make` irá tentar usar esta especificação para baixar o arquivo de distribuição com `FETCH` se não for possível encontrá-lo já no sistema. Recomenda-se que vários sites sejam incluídos nesta lista, de preferência em diferentes continentes. Isso irá proteger contra problemas de rede amplos. [IMPORTANT] ==== `MASTER_SITES` não deve estar em branco. Ele deve apontar para o site real que hospeda os arquivos de distribuição. Ele não pode apontar para web archives ou para os sites de cache dos arquivos de distribuição do FreeBSD. A única exceção a essa regra são ports que não possuem arquivos de distribuição. Por exemplo, meta-ports não possuem arquivos de distribuição, assim o `MASTER_SITES` não precisa ser definido. ==== [[makefile-master_sites-shorthand]] ==== Usando Variáveis `MASTER_SITE_*`​​ Abreviações de atalhos estão disponíveis para arquivos populares como o SourceForge (`SOURCEFORGE`), GNU (`GNU`), ou Perl CPAN (`PERL_CPAN`). `MASTER_SITES` pode usá-los diretamente: [.programlisting] .... MASTER_SITES= GNU/make .... O antigo formato expandido ainda funciona, mas todos os ports foram convertidos para o formato compacto. O formato expandido se parece com isto: [.programlisting] .... MASTER_SITES= ${MASTER_SITE_GNU} MASTER_SITE_SUBDIR= make .... Estes valores e variáveis ​​são definidos em https://svnweb.freebsd.org/ports/head/Mk/bsd.sites.mk?view=markup[Mk/bsd.sites.mk]. Novas entradas são adicionadas com frequência, portanto, verifique a versão mais recente deste arquivo antes de enviar um port. [TIP] ==== Para qualquer variável `MASTER_SITE_FOO` , a versão abreviada `_FOO_` pode ser utilizada. Por exemplo, use: [.programlisting] .... MASTER_SITES= FOO .... E se `MASTER_SITE_SUBDIR` for necessário, use isso: [.programlisting] .... MASTER_SITES= FOO/bar .... ==== [NOTE] ==== Alguns nomes `MASTER_SITE_*` são bastante longos e, para facilitar o uso, foram definidos atalhos: [[makefile-master_sites-shortcut]] .Atalhos para Macros `MASTER_SITE_*` [cols="1,1", frame="none", options="header"] |=== | Macro | Atalho |`PERL_CPAN` |`CPAN` |`GITHUB` |`GH` |`GITHUB_CLOUD` |`GHC` |`LIBREOFFICE_DEV` |`LODEV` |`NETLIB` |`NL` |`RUBYGEMS` |`RG` |`SOURCEFORGE` |`SF` |=== ==== [[makefile-master_sites-magic]] ==== Macros Mágicas de MASTER_SITES Várias macros "mágicas" existem para sites populares com uma estrutura de diretórios previsível. Para isso, basta usar a abreviação e o sistema escolherá um subdiretório automaticamente. Para um port nomeado `Stardict`, de versão `1.2.3` e hospedado no SourceForge, adicione esta linha: [.programlisting] .... MASTER_SITES= SF .... Implica em um subdiretório chamado `/project/stardict/stardict/1.2.3`. Se o diretório estiver incorreto, ele poderá ser substituído: [.programlisting] .... MASTER_SITES= SF/stardict/WyabdcRealPeopleTTS/${PORTVERSION} .... Isso também pode ser escrito como [.programlisting] .... MASTER_SITES= SF MASTER_SITE_SUBDIR= stardict/WyabdcRealPeopleTTS/${PORTVERSION} .... [[makefile-master_sites-popular]] .Macros Mágicas de `MASTER_SITES` [cols="1,1", frame="none", options="header"] |=== | Macro | Subdiretório deduzido |`APACHE_COMMONS_BINARIES` |`${PORTNAME:S,commons-,,}` |`APACHE_COMMONS_SOURCE` |`${PORTNAME:S,commons-,,}` |`APACHE_JAKARTA` |`${PORTNAME:S,-,/,}/source` |`BERLIOS` |`${PORTNAME:tl}.berlios` |`CHEESESHOP` |`source/${DISTNAME:C/(.).\*/\1/}/${DISTNAME:C/(.*)-[0-9].*/\1/}` |`CPAN` |`${PORTNAME:C/-.*//}` |`DEBIAN` |`pool/main/${PORTNAME:C/^((lib)?.).*$/\1/}/${PORTNAME}` |`FARSIGHT` |`${PORTNAME}` |`FESTIVAL` |`${PORTREVISION}` |`GCC` |`releases/${DISTNAME}` |`GENTOO` |`distfiles` |`GIMP` |`${PORTNAME}/${PORTVERSION:R}/` |`GH` |`${GH_ACCOUNT}/${GH_PROJECT}/tar.gz/${GH_TAGNAME}?dummy=/` |`GHC` |`${GH_ACCOUNT}/${GH_PROJECT}/` |`GNOME` |`sources/${PORTNAME}/${PORTVERSION:C/^([0-9]+\.[0-9]+).*/\1/}` |`GNU` |`${PORTNAME}` |`GNUPG` |`${PORTNAME}` |`GNU_ALPHA` |`${PORTNAME}` |`HORDE` |`${PORTNAME}` |`LODEV` |`${PORTNAME}` |`MATE` |`${PORTVERSION:C/^([0-9]+\.[0-9]+).*/\1/}` |`MOZDEV` |`${PORTNAME:tl}` |`NL` |`${PORTNAME}` |`QT` |`archive/qt/${PORTVERSION:R}` |`SAMBA` |`${PORTNAME}` |`SAVANNAH` |`${PORTNAME:tl}` |`SF` |`${PORTNAME:tl}/${PORTNAME:tl}/${PORTVERSION}` |=== [[makefile-master_sites-github]] === `USE_GITHUB` Se o arquivo de distribuição vier de um commit ou tag específico no https://github.com[GitHub] para o qual não há arquivo lançado oficialmente, há uma maneira fácil de definir o `DISTNAME` e `MASTER_SITES` corretos automaticamente. Estas variáveis ​​estão disponíveis: [[makefile-master_sites-github-description]] .`USE_GITHUB` Descrição [cols="1,1,1", options="header"] |=== | Variável | Descrição | Padrão |`GH_ACCOUNT` |Nome da conta do usuário do GitHub que hospeda o projeto |`${PORTNAME}` |`GH_PROJECT` |Nome do projeto no GitHub |`${PORTNAME}` |`GH_TAGNAME` |Nome da tag para download (2.0.1, hash, ...) Usar o nome de uma branch aqui é errado. Também é possível usar o hash de um ID de commit para gerar um snapshot. |`${DISTVERSIONPREFIX}${DISTVERSION}${DISTVERSIONSUFFIX}` |`GH_SUBDIR` |Quando o software precisa que um arquivo de distribuição adicional seja extraído em `${WRKSRC}`, esta variável pode ser usada. Veja os exemplos em <> para maiores informações. |(none) |`GH_TUPLE` |`GH_TUPLE` permite colocar `GH_ACCOUNT`, `GH_PROJECT`, `GH_TAGNAME` e `GH_SUBDIR` em uma única variável. O formato é _conta_`:`_projeto_`:`_tagname_`:`_grupo_`/`_subdiretório_. O `/`_subdiretório _ é opcional. Isso é útil quando mais de um projeto no GitHub precisa ser utilizado. |=== [IMPORTANT] ==== Não use `GH_TUPLE` para o arquivo de distribuição padrão, já que não tem nenhum padrão. ==== [[makefile-master_sites-github-ex1]] .Uso Simples de `USE_GITHUB` [example] ==== Ao tentar fazer um port para a versão `1.2.7` do pkg do usuário FreeBSD no github, em https://github.com/freebsd/pkg[], O [.filename]#Makefile# acabaria ficando assim (levemente simplificado para o exemplo): [.programlisting] .... PORTNAME= pkg DISTVERSION= 1.2.7 USE_GITHUB= yes GH_ACCOUNT= freebsd .... `MASTER_SITES` será automaticamente definido como `GH GHC` e `WRKSRC` para `${WRKDIR}/pkg-1.2.7`. ==== [[makefile-master_sites-github-ex2]] .Uso Mais Completo de `USE_GITHUB` [example] ==== Ao tentar fazer um port para uma versão de desenvolvimento do pkg do usuário FreeBSD no github, em https://github.com/freebsd/pkg[], o [.filename]#Makefile# acaba ficando assim (levemente simplificado para o exemplo): [.programlisting] .... PORTNAME= pkg-devel DISTVERSION= 1.3.0.a.20140411 USE_GITHUB= yes GH_ACCOUNT= freebsd GH_PROJECT= pkg GH_TAGNAME= 6dbb17b .... `MASTER_SITES` será automaticamente definido para `GH GHC` e `WRKSRC` para `${WRKDIR}/pkg-6dbb17b`. [TIP] ====== `20140411` é a data do commit referenciada em `GH_TAGNAME`, não a data em que é editado o [.filename]#Makefile#, ou a data em que o commit é feito. ====== ==== [[makefile-master_sites-github-ex3]] .Uso de `USE_GITHUB` com `DISTVERSIONPREFIX` [example] ==== De tempos em tempos, `GH_TAGNAME` é uma ligeira variação de `DISTVERSION`. Por exemplo, se a versão for `1.0.2`, e a tag `v1.0.2`. Nesses casos, é possível usar `DISTVERSIONPREFIX` ou `DISTVERSIONSUFFIX`: [.programlisting] .... PORTNAME= foo DISTVERSIONPREFIX= v DISTVERSION= 1.0.2 USE_GITHUB= yes .... `GH_TAGNAME` será automaticamente definido para `v1.0.2`, enquanto `WRKSRC` será mantido como `${WRKDIR} /foo-1.0.2`. ==== [[makefile-master_sites-github-ex4]] .Usando `USE_GITHUB` Quando o Upstream Não Usa Versões [example] ==== Se nunca houve uma versão upstream, não invente uma como `0.1` ou `1.0`. Crie o port com um `DISTVERSION` de `gYYYYMMDD`, onde `g` é para Git e `YYYYMMDD` representa a data em que o commit é referenciado em `GH_TAGNAME`. [.programlisting] .... PORTNAME= bar DISTVERSION= g20140411 USE_GITHUB= yes GH_TAGNAME= c472d66b .... Isso cria um esquema de controle de versão que é incrementado com o tempo e que ainda é menor do que a versão `0` (veja <> para mais informações do man:pkg-version[8]): [source,shell] .... % pkg version -t g20140411 0 < .... Isso significa que não será necessário usar o `PORTEPOCH` caso o upstream decida lançar versões no futuro. ==== [[makefile-master_sites-github-ex5]] .Usando `USE_GITHUB` para Acessar um Commit Entre Duas Versões [example] ==== Se a versão atual do software usa uma tag Git, e o port precisa ser atualizado para uma versão mais recente e intermediária, sem uma tag, use man:git-describe[1] para descobrir a versão a ser utilizada: [source,shell] .... % git describe --tags f0038b1 v0.7.3-14-gf0038b1 .... `v0.7.3-14-gf0038b1` pode ser dividido em três partes: `v0.7.3`:: Este é a última tag Git que aparece no histórico de commits antes do commit solicitado. `-14`:: Isso significa que o commit solicitado, `f0038b1`, é o 14º commit após a tag `v0.7.3`. `-gf0038b1`:: O `-g` significa "Git", e o `f0038b1` é o commit hash referenciado. [.programlisting] .... PORTNAME= bar DISTVERSIONPREFIX= v DISTVERSION= 0.7.3-14 DISTVERSIONSUFFIX= -gf0038b1 USE_GITHUB= yes .... Isso cria um esquema de versionamento que é incrementado com o tempo (bem, em cima de commits), e não entra em conflito com a criação de uma versão `0.7.4`. (Veja <> para detalhes do man:pkg-version[8]): [source,shell] .... % pkg version -t 0.7.3 0.7.3.14 < % pkg version -t 0.7.3.14 0.7.4 < .... [NOTE] ====== Se o commit solicitado é o mesmo que uma tag, uma descrição mais curta é mostrada por padrão. A versão mais longa é equivalente: [source,shell] .... % git describe --tags c66c71d v0.7.3 % git describe --tags --long c66c71d v0.7.3-0-gc66c71d .... ====== ==== [[makefile-master_sites-github-multiple]] ==== Baixando Múltiplos Arquivos do GitHub O framework `USE_GITHUB` também suporta a obtenção de vários arquivos de distribuição de diferentes locais no GitHub. Ele funciona de uma forma muito semelhante ao <>. Vários valores são adicionados a `GH_ACCOUNT`, `GH_PROJECT` e `GH_TAGNAME`. Cada valor diferente é atribuído a um grupo. O valor principal pode não ter nenhum grupo ou grupo `:DEFAULT`. Um valor pode ser omitido se for o mesmo que o padrão listado em <>. `GH_TUPLE` também pode ser usado quando há muitos arquivos de distribuição. Isso ajuda a manter as informações de conta, projeto, tagname e grupo no mesmo lugar. Para cada grupo, uma variável auxiliar `${WRKSRC_group}` é criada, contendo o diretório no qual o arquivo foi extraído. As variáveis `${WRKSRC_group}` ​​podem ser usadas para mover diretórios durante o `post-extract`, ou para serem adicionadas em `CONFIGURE_ARGS`, ou o que for necessário para que o software seja compilado corretamente. [CAUTION] ==== A parte do `:group` _deve_ ser usada para _apenas um_ arquivo de distribuição. Ela é usado como uma chave única e usá-la mais de uma vez irá sobrescrever os valores anteriores. ==== [NOTE] ==== Como isso é apenas modificações de `DISTFILES` e `MASTER_SITES`, os nomes dos grupos devem obedecer às restrições de nomes de grupos descritas em <> ==== Ao buscar vários arquivos do GitHub, às vezes o arquivo de distribuição padrão não é buscado no GitHub. Para desabilitar a busca da distribuição padrão, defina: [.programlisting] .... USE_GITHUB= nodefault .... [IMPORTANT] ==== Ao utilizar `USE_GITHUB=nodefault`, o [.filename]#Makefile# deve ter `DISTFILES` em seu <>. A definição deve ser: [.programlisting] .... DISTFILES= ${DISTNAME}${EXTRACT_SUFX} .... ==== [[makefile-master_sites-github-multi]] .Uso de `USE_GITHUB` com Vários Arquivos de Distribuição [example] ==== De tempos em tempos é necessário baixar mais de um arquivo de distribuição. Por exemplo, quando o repositório git do upstream usa submódulos. Isso pode ser feito facilmente usando grupos nas variáveis `GH_*`: [.programlisting] .... PORTNAME= foo DISTVERSION= 1.0.2 USE_GITHUB= yes GH_ACCOUNT= bar:icons,contrib GH_PROJECT= foo-icons:icons foo-contrib:contrib GH_TAGNAME= 1.0:icons fa579bc:contrib GH_SUBDIR= ext/icons:icons CONFIGURE_ARGS= --with-contrib=${WRKSRC_contrib} .... Isso irá baixar três arquivos de distribuição do github. O padrão vem de [.filename]#foo/foo# versão `1.0.2`. O segundo, com o grupo `icons`, vem de [.filename]#bar/foo-icons# versão `1.0`. O terceiro vem de [.filename]#bar/foo-contrib# e usa o commit do Git `fa579bc`. Os arquivos de distribuição são nomeados [.filename]#foo-foo-1.0.2_GH0.tar.gz#, [.filename]#bar-foo-icons-1.0_GH0.tar.gz# e [.filename]#bar-foo-contrib-fa579bc_GH0.tar.gz#. Todos os arquivos de distribuição são extraídos em `${WRKDIR}` em seus respectivos subdiretórios. O arquivo padrão ainda é extraído em `${WRKSRC}`, nesse caso, [.filename]#${WRKDIR}/foo-1.0.2#. Cada arquivo de distribuição adicional é extraído em `${WRKSRC_group}`. Aqui, para o grupo `icons`, chamado de `${WRKSRC_icons}`, será [.filename]#${WRKDIR}/foo-icons-1.0#. O arquivo com o grupo `contrib` é chamado de `${WRKSRC_contrib}` e contém `${WRKDIR}/foo-contrib-fa579bc`. O sistema de compilação do software espera encontrar os ícones em um subdiretório [.filename]#ext/icons# em seus fontes, então `GH_SUBDIR` é usado. `GH_SUBDIR` garante que [.filename]#ext# exista, mas não que [.filename]#ext/icons# também exista. Então isso acontece: [.programlisting] .... post-extract: @${MV} ${WRKSRC_icons} ${WRKSRC}/ext/icons .... ==== [[makefile-master_sites-github-multi2]] .Uso de `USE_GITHUB` com Vários Arquivos de Distribuição Usando `GH_TUPLE` [example] ==== Isto é funcionalmente equivalente a <> mas usando `GH_TUPLE`: [.programlisting] .... PORTNAME= foo DISTVERSION= 1.0.2 USE_GITHUB= yes GH_TUPLE= bar:foo-icons:1.0:icons/ext/icons \ bar:foo-contrib:fa579bc:contrib CONFIGURE_ARGS= --with-contrib=${WRKSRC_contrib} .... Agrupamento foi usado no exemplo anterior com `bar:icons, contrib`. Algumas informações redundantes estão presentes com `GH_TUPLE` porque o uso de agrupamento não é possível. ==== [[makefile-master_sites-github-submodules]] .Como Usar `USE_GITHUB` com Submodulos Git? [example] ==== Ports com o GitHub como um repositório upstream às vezes usam submódulos. Veja man:git-submodule[1] para maiores informações. O problema com submódulos é que cada um é um repositório separado. Como tal, cada um deve ser buscado separadamente. Usando package:finances/moneymanagerex[] como exemplo, seu repositório GitHub é https://github.com/moneymanagerex/moneymanagerex[]. Tem um arquivo https://github.com/moneymanagerex/moneymanagerex/blob/master/.gitmodules[.gitmodules] na raiz. Este arquivo descreve todos os sub módulos usados neste repositório e lista os repositórios adicionais necessários. Este arquivo irá dizer quais repositórios adicionais são necessários: [.programlisting] .... [submodule "lib/wxsqlite3"] path = lib/wxsqlite3 url = https://github.com/utelle/wxsqlite3.git [submodule "3rd/mongoose"] path = 3rd/mongoose url = https://github.com/cesanta/mongoose.git [submodule "3rd/LuaGlue"] path = 3rd/LuaGlue url = https://github.com/moneymanagerex/LuaGlue.git [submodule "3rd/cgitemplate"] path = 3rd/cgitemplate url = https://github.com/moneymanagerex/html-template.git [...] .... A única informação que falta nesse arquivo é a hash ou tag de commit para usar na versão. Esta informação é encontrada após a clonagem do repositório: [source,shell] .... % git clone --recurse-submodules https://github.com/moneymanagerex/moneymanagerex.git Cloning into 'moneymanagerex'... remote: Counting objects: 32387, done. [...] Submodule '3rd/LuaGlue' (https://github.com/moneymanagerex/LuaGlue.git) registered for path '3rd/LuaGlue' Submodule '3rd/cgitemplate' (https://github.com/moneymanagerex/html-template.git) registered for path '3rd/cgitemplate' Submodule '3rd/mongoose' (https://github.com/cesanta/mongoose.git) registered for path '3rd/mongoose' Submodule 'lib/wxsqlite3' (https://github.com/utelle/wxsqlite3.git) registered for path 'lib/wxsqlite3' [...] Cloning into '/home/mat/work/freebsd/ports/finance/moneymanagerex/moneymanagerex/3rd/LuaGlue'... Cloning into '/home/mat/work/freebsd/ports/finance/moneymanagerex/moneymanagerex/3rd/cgitemplate'... Cloning into '/home/mat/work/freebsd/ports/finance/moneymanagerex/moneymanagerex/3rd/mongoose'... Cloning into '/home/mat/work/freebsd/ports/finance/moneymanagerex/moneymanagerex/lib/wxsqlite3'... [...] Submodule path '3rd/LuaGlue': checked out 'c51d11a247ee4d1e9817dfa2a8da8d9e2f97ae3b' Submodule path '3rd/cgitemplate': checked out 'cd434eeeb35904ebcd3d718ba29c281a649b192c' Submodule path '3rd/mongoose': checked out '2140e5992ab9a3a9a34ce9a281abf57f00f95cda' Submodule path 'lib/wxsqlite3': checked out 'fb66eb230d8aed21dec273b38c7c054dcb7d6b51' [...] % cd moneymanagerex % git submodule status c51d11a247ee4d1e9817dfa2a8da8d9e2f97ae3b 3rd/LuaGlue (heads/master) cd434eeeb35904ebcd3d718ba29c281a649b192c 3rd/cgitemplate (cd434ee) 2140e5992ab9a3a9a34ce9a281abf57f00f95cda 3rd/mongoose (6.2-138-g2140e59) fb66eb230d8aed21dec273b38c7c054dcb7d6b51 lib/wxsqlite3 (v3.4.0) [...] .... Também pode ser encontrado no GitHub. Cada subdiretório que é um submódulo é mostrado como _diretório_ `@` _hash_, por exemplo,`mongoose @ 2140e59`. [NOTE] ====== Embora a obtenção das informações pelo GitHub pareça mais fácil, as informações encontradas usando `git submodule status` fornecerá informações mais significativas. Por exemplo, o commit hash de `lib/wxsqlite3 fb66eb2` corresponde a `v3.4.0`. Ambos podem ser usados, mas quando uma tag estiver disponível, use-a. ====== Agora que todas as informações necessárias foram reunidas, o [.filename]#Makefile# pode ser escrito (somente as linhas relacionadas ao GitHub são mostradas): [.programlisting] .... PORTNAME= moneymanagerex DISTVERSIONPREFIX= v DISTVERSION= 1.3.0 USE_GITHUB= yes GH_TUPLE= utelle:wxsqlite3:v3.4.0:wxsqlite3/lib/wxsqlite3 \ moneymanagerex:LuaGlue:c51d11a:lua_glue/3rd/LuaGlue \ moneymanagerex:html-template:cd434ee:html_template/3rd/cgitemplate \ cesanta:mongoose:2140e59:mongoose/3rd/mongoose \ [...] .... ==== [[makefile-master_sites-gitlab]] === `USE_GITLAB` Semelhante ao GitHub, se o arquivo de distribuição vier de https://gitlab.com[gitlab.com] ou se estiver hospedado com o software GitLab, essas variáveis estão disponíveis para uso e talvez precisem ser definidas. [[makefile-master_sites-gitlab-description]] .`USE_GITLAB` Descrição [cols="1,1,1", options="header"] |=== | Variável | Descrição | Padrão |`GL_SITE` |Nome do site que hospeda o projeto GitLab |https://gitlab.com |`GL_ACCOUNT` |Nome da conta do usuário do GitLab hospedando o projeto |`${PORTNAME}` |`GL_PROJECT` |Nome do projeto em GitLab |`${PORTNAME}` |`GL_COMMIT` |O hash de commit para download. Deve ser o hash hex sha1 completo de 160 bits e 40 caracteres. Essa é uma variável obrigatória para GitLab. |`(none)` |`GL_SUBDIR` |Quando o software precisa de um arquivo de distribuição adicional para ser extraído com `${WRKSRC}`, esta variável pode ser usada. Veja os exemplos em <> para maiores informações. |(none) |`GL_TUPLE` |`GL_TUPLE` permite colocar `GL_SITE`, `GL_ACCOUNT`, `GL_PROJECT`, `GL_COMMIT`, e `GL_SUBDIR` dentro de uma única variável. O formato é _site_`:`_conta_`:`_projeto_`:`_commit_`:`_grupo_`/`_subdiretório_. O _site_`:` e `/`_subdiretório_ são opcionais. Isso ajuda quando é necessário baixar arquivos de mais de um projeto GitLab. |=== [[makefile-master_sites-gitlab-ex1]] .Uso Simples de `USE_GITLAB` [example] ==== Ao tentar fazer um port para a versão `1.14` do libsignon-glib do usuário accounts-sso do gitlab.com, em https://gitlab.com/accounts-sso/libsignon-glib[], O [.filename]#Makefile# acabaria ficando assim para buscar os arquivos de distribuição: [.programlisting] .... PORTNAME= libsignon-glib DISTVERSION= 1.14 USE_GITLAB= yes GL_ACCOUNT= accounts-sso GL_COMMIT= e90302e342bfd27bc8c9132ab9d0ea3d8723fd03 .... Ele terá automaticamente `MASTER_SITES` definido como https://gitlab.com[gitlab.com] e `WRKSRC` para `${WRKDIR}/libsignon-glib-e90302e342bfd27bc8c9132ab9d0ea3d8723fd03-e90302e342bfd27bc8c9132ab9d0ea3d8723fd03`. ==== [[makefile-master_sites-gitlab-ex2]] .Uso Mais Completo de `USE_GITLAB` [example] ==== Um uso mais completo do exemplo acima é se o port não tiver controle de versão e foobar do usuário foo no projeto bar em um GitLab auto hospedado em `https://gitlab.example.com`, o [.filename]#Makefile# acaba ficando assim para buscar os arquivos de distribuição: [.programlisting] .... PORTNAME= foobar DISTVERSION= g20170906 USE_GITLAB= yes GL_SITE= https://gitlab.example.com GL_ACCOUNT= foo GL_PROJECT= bar GL_COMMIT= 9c1669ce60c3f4f5eb43df874d7314483fb3f8a6 .... -Terá `MASTER_SITES` definido como "`https://gitlab.example.com`" e `WRKSRC` para `${WRKDIR}/bar-9c1669ce60c3f4f5eb43df874d7314483fb3f8a6-9c1669ce60c3f4f5eb43df874d7314483fb3f8a6`. +Terá `MASTER_SITES` definido como `"https://gitlab.example.com"` e `WRKSRC` para `${WRKDIR}/bar-9c1669ce60c3f4f5eb43df874d7314483fb3f8a6-9c1669ce60c3f4f5eb43df874d7314483fb3f8a6`. [TIP] ====== `20170906` é a data do commit referenciada em `GL_COMMIT`, não a data em que o [.filename]#Makefile# é editado, ou a data em que o commit para a árvore de ports do FreeBSD é feito. ====== [NOTE] ====== O protocolo, porta e webroot do `GL_SITE` podem ser modificados na mesma variável. ====== ==== [[makefile-master_sites-gitlab-multiple]] ==== Baixando Múltiplos Arquivos do GitLab O framework `USE_GITLAB` também suporta a busca de vários arquivos de distribuição de diferentes locais de GitLab e sites hospedados no GitLab. Ele funciona de uma forma muito semelhante ao <> e <>. Vários valores são adicionados a `GL_SITE`, `GL_ACCOUNT`, `GL_PROJECT` e `GL_COMMIT`. Cada valor diferente é atribuído a um grupo. <>. `GL_TUPLE` também pode ser usado quando há muitos arquivos de distribuição. Isso ajuda a manter as informações de site, conta, projeto, commit e grupo no mesmo local. Para cada grupo, uma variável auxiliar `${WRKSRC_group}` é criada, contendo o diretório no qual o arquivo foi extraído. As variáveis `${WRKSRC_group}` ​​podem ser usadas para mover diretórios durante o `post-extract`, ou para serem adicionadas em `CONFIGURE_ARGS`, ou o que for necessário para que o software seja compilado corretamente. [CAUTION] ==== A parte do `:group` _deve_ ser usada para _apenas um_ arquivo de distribuição. Ela é usado como uma chave única e usá-la mais de uma vez irá sobrescrever os valores anteriores. ==== [NOTE] ==== Como isso é apenas modificações de `DISTFILES` e `MASTER_SITES`, os nomes dos grupos devem obedecer às restrições de nomes de grupos descritas em <> ==== Ao buscar vários arquivos usando GitLab, às vezes, o arquivo de distribuição padrão não é obtido de um GitLab. Para desativar a busca do arquivo de distribuição padrão, defina: [.programlisting] .... USE_GITLAB= nodefault .... [IMPORTANT] ==== Ao utilizar `USE_GITLAB=nodefault`, o [.filename]#Makefile# deve ter `DISTFILES` em seu <>. A definição deve ser: [.programlisting] .... DISTFILES= ${DISTNAME}${EXTRACT_SUFX} .... ==== [[makefile-master_sites-gitlab-multi]] .Uso de `USE_GITLAB` com Vários Arquivos de Distribuição [example] ==== De tempos em tempos, é necessário buscar mais de um arquivo de distribuição. Por exemplo, quando o repositório git do upstream usa submódulos. Isso pode ser feito facilmente usando grupos nas variáveis `GL_*`: [.programlisting] .... PORTNAME= foo DISTVERSION= 1.0.2 USE_GITLAB= yes GL_SITE= https://gitlab.example.com:9434/gitlab:icons GL_ACCOUNT= bar:icons,contrib GL_PROJECT= foo-icons:icons foo-contrib:contrib GL_COMMIT= c189207a55da45305c884fe2b50e086fcad4724b ae7368cab1ca7ca754b38d49da064df87968ffe4:icons 9e4dd76ad9b38f33fdb417a4c01935958d5acd2a:contrib GL_SUBDIR= ext/icons:icons CONFIGURE_ARGS= --with-contrib=${WRKSRC_contrib} .... Isso irá buscar dois arquivos de distribuição do gitlab.com e um de `gitlab.example.com` hospedado com GitLab. O padrão vem de [.filename]#https://gitlab.com/foo/foo# e o commit é `c189207a55da45305c884fe2b50e086fcad4724b`. O segundo, com o grupo `icons`, vem de [.filename]#https://gitlab.example.com:9434/gitlab/bar/foo-icons# e o commit é `ae7368cab1ca7ca754b38d49da064df87968ffe4`. O terceiro vem de [.filename]#https://gitlab.com/bar/foo-contrib# e o commit é `9e4dd76ad9b38f33fdb417a4c01935958d5acd2a`. Os arquivos de distribuição são nomeados [.filename]#foo-foo-c189207a55da45305c884fe2b50e086fcad4724b_GL0.tar.gz#, [.filename]#bar-foo-icons-ae7368cab1ca7ca754b38d49da064df87968ffe4_GL0.tar.gz# e [.filename]#bar-foo-contrib-9e4dd76ad9b38f33fdb417a4c01935958d5acd2a_GL0.tar.gz#. Todos os arquivos de distribuição são extraídos no `${WRKDIR}` em seus respectivos subdiretórios. O arquivo padrão ainda é extraído no `${WRKSRC}`, nesse caso, [.filename]#${WRKDIR}/foo-c189207a55da45305c884fe2b50e086fcad4724b-c189207a55da45305c884fe2b50e086fcad4724b#. Cada arquivo de distribuição adicional é extraído em `${WRKSRC_group}`. Aqui, para o grupo `icons`, é chamado `${WRKSRC_icons}` e contém [.filename]#${WRKDIR}/foo-icons-ae7368cab1ca7ca754b38d49da064df87968ffe4-ae7368cab1ca7ca754b38d49da064df87968ffe4#. O arquivo com o grupo `contrib` é chamado `${WRKSRC_contrib}` e contém `${WRKDIR}/foo-contrib-9e4dd76ad9b38f33fdb417a4c01935958d5acd2a-9e4dd76ad9b38f33fdb417a4c01935958d5acd2a`. O sistema de compilação do software espera encontrar os ícones em um subdiretório [.filename]#ext/icons# em seus fontes, então `GL_SUBDIR` é usado.`GL_SUBDIR` garante que [.filename]#ext# existe, mas não que [.filename]#ext/icons# também exista. Então isso acontece: [.programlisting] .... post-extract: @${MV} ${WRKSRC_icons} ${WRKSRC}/ext/icons .... ==== [[makefile-master_sites-gitlab-multi2]] .Uso de `USE_GITLAB` com Vários Arquivos de Distribuição Usando `GL_TUPLE` [example] ==== Isto é funcionalmente equivalente a <> mas usando `GL_TUPLE`: [.programlisting] .... PORTNAME= foo DISTVERSION= 1.0.2 USE_GITLAB= yes GL_COMMIT= c189207a55da45305c884fe2b50e086fcad4724b GL_TUPLE= https://gitlab.example.com:9434/gitlab:bar:foo-icons:ae7368cab1ca7ca754b38d49da064df87968ffe4:icons/ext/icons \ bar:foo-contrib:9e4dd76ad9b38f33fdb417a4c01935958d5acd2a:contrib CONFIGURE_ARGS= --with-contrib=${WRKSRC_contrib} .... Agrupamento foi usado no exemplo anterior com `bar:icons,contrib`. Algumas informações redundantes estão presentes com `GL_TUPLE` porque o uso de agrupamento não é possível. ==== [[makefile-extract_sufx]] === `EXTRACT_SUFX` Se houver um arquivo de distribuição e ele usar um sufixo diferente para indicar o mecanismo de compactação, defina `EXTRACT_SUFX`. Por exemplo, se o arquivo de distribuição foi nomeado [.filename]#foo.tar.gzip# em vez do mais comum [.filename]#foo.tar.gz#, escreva: [.programlisting] .... DISTNAME= foo EXTRACT_SUFX= .tar.gzip .... O `USES=tar[:xxx]`, `USES=lha` ou `USES=zip` define automaticamente `EXTRACT_SUFX` com as extensões de arquivo mais comuns, conforme necessário, consulte <> para mais detalhes. Se nenhum destes estiver definido, o `EXTRACT_SUFX` padrão é `.tar.gz`. [NOTE] ==== Como `EXTRACT_SUFX` é usado apenas em `DISTFILES`, apenas defina um deles.. ==== [[makefile-distfiles-definition]] === `DISTFILES` Às vezes os nomes dos arquivos a serem baixados não têm semelhança com o nome do port. Por exemplo, pode ser chamado [.filename]#source.tar.gz# ou similar. Em outros casos, o código-fonte do aplicativo pode estar em vários arquivos diferentes, e todos eles devem ser baixados. Se este for o caso, defina `DISTFILES` para ser uma lista separada por espaços de todos os arquivos que devem ser baixados. [.programlisting] .... DISTFILES= source1.tar.gz source2.tar.gz .... Se não for definido explicitamente, o `DISTFILES` padrão é `${DISTNAME}${EXTRACT_SUFX}`. [[makefile-extract_only]] === `EXTRACT_ONLY` Se apenas alguns dos `DISTFILES` devem ser extraídos-- por exemplo, um deles é o código-fonte, enquanto outro é um documento não compactado - liste os nomes dos arquivos que devem ser extraídos em `EXTRACT_ONLY`. [.programlisting] .... DISTFILES= source.tar.gz manual.html EXTRACT_ONLY= source.tar.gz .... Quando nenhum dos `DISTFILES` precisam ser descompactados, deixe vazio o `EXTRACT_ONLY`. [.programlisting] .... EXTRACT_ONLY= .... [[porting-patchfiles]] === `PATCHFILES` Se o port requer alguns patches adicionais que estão disponíveis por FTP ou HTTP, defina `PATCHFILES` para os nomes dos arquivos e `PATCH_SITES` para a URL do diretório que os contém (o formato é o mesmo do `MASTER_SITES`). Se o patch não for relativo ao inicio da árvore do código fonte (isto é, `WRKSRC`) porque contém alguns pathnames extras, defina `PATCH_DIST_STRIP` adequadamente. Por exemplo, se todos os pathnames no patch tiverem um `foozolix-1.0 /` extra na frente dos nomes dos arquivos, então defina `PATCH_DIST_STRIP=-p1`. Não se preocupe se os patches estiverem compactados; eles serão descompactados automaticamente se os nomes dos arquivos terminarem com [.filename]#.Z#, [.filename]#.gz#, [.filename]#.bz2# ou [.filename]#.xz#. Se o patch for distribuído com alguns outros arquivos, como documentação, em um arquivo compactado, o uso de `PATCHFILES` não será possível. Se for esse o caso, adicione o nome e a localização do arquivo do patch em `DISTFILES` e `MASTER_SITES`. Então, use `EXTRA_PATCHES` para apontar para esses arquivos e o [.filename]#bsd.port.mk# irá aplicá-los automaticamente. Em particular, _não_ copie os arquivos de patch em [.filename]#${PATCHDIR}#. Esse diretório pode não ter permissão de escrita. [TIP] ==== Se houver vários patches e eles precisarem de valores mistos para o parâmetro strip, ele poderá ser adicionado ao lado do nome do patch em `PATCHFILES`, por exemplo: [.programlisting] .... PATCHFILES= patch1 patch2:-p1 .... Isto não entra em conflito com <>, adicionando um grupo também funciona: [.programlisting] .... PATCHFILES= patch2:-p1:source2 .... ==== [NOTE] ==== O arquivo será extraído junto com o arquivo de código fonte, então não há necessidade de explicitamente extraí-lo se ele for um arquivo compactado normal. Tome cuidado extra para não sobrescrever algo que já existe nesse diretório caso faça a extração manualmente. Também não se esqueça de adicionar um comando para remover o patch copiado no target `pre-clean`. ==== [[porting-master-sites-n]] === Múltiplos Arquivos de Distribuição ou Patches de Vários Locais (Considere isto como um "tópico avançado"; a princípio, aqueles que são novos neste documento podem desejar pular esta seção). Esta seção contém informações sobre o mecanismo de busca conhecido como `MASTER_SITES:n` e `MASTER_SITES_NN`. Vamos nos referir a este mecanismo como `MASTER_SITES:n`. Um pouco de background primeiro. O OpenBSD tem um ótimo recurso dentro do `DISTFILES` e `PATCHFILES` que permite que arquivos e pacthes sejam pós fixados com identificadores `:n`. Aqui, `n` pode ser qualquer palavra que contenha `[0-9a-zA-Z_]` e signifique uma designação de grupo. Por exemplo: [.programlisting] .... DISTFILES= alpha:0 beta:1 .... No OpenBSD, arquivo de distribuição [.filename]#alpha# será associado com a variável `MASTER_SITES0` em vez da nossa comum `MASTER_SITES` e [.filename]#beta# com `MASTER_SITES1`. Esta é uma característica muito interessante que pode diminuir a busca sem fim pelo site de download correto. Apenas imagine 2 arquivos em `DISTFILES` e 20 sites em `MASTER_SITES`, os sites são extremamente lentos e [.filename]#beta# é hospedado em todas as entradas do `MASTER_SITES` e [.filename]#alfa# só pode ser encontrado no 20º site. Seria um desperdício checar todos eles se o mantenedor soubesse isso de antemão, não seria? Não é um bom começo para aquele lindo fim de semana! Agora que você já tem uma ideia, imagine mais `DISTFILES` e mais `MASTER_SITES`. Certamente nosso "distfiles survey meister" irá ser apreciado pelo alívio nas conexões de rede que isso trará. Nas próximas seções, as informações seguirão a implementação do FreeBSD desta idéia. Nós melhoramos um pouco o conceito do OpenBSD. [IMPORTANT] ==== Os nomes dos grupos não podem ter traços neles (`-`), na verdade, eles não podem ter nenhum caractere fora do range `[a-zA-Z0-9_]`. Isso porque, enquantoman:make[1] está ok com nomes de variáveis ​​contendo traços, man:sh[1]não. ==== [[porting-master-sites-n-simplified]] ==== Informação Simplificada Esta seção explica como preparar rapidamente a busca de vários arquivos de distribuição e patches de diferentes sites e subdiretórios. Descrevemos aqui um caso de uso de `MASTER_SITES:n`. Isso será suficiente para a maioria dos cenários. Informações mais detalhadas estão disponíveis em <>. Alguns aplicativos consistem em vários arquivos de distribuição que devem ser baixados de vários sites diferentes. Por exemplo, Ghostscript consiste no núcleo do programa e, em seguida, um grande número de arquivos de driver que são usados dependendo da impressora do usuário. Alguns desses arquivos de driver são fornecidos com o núcleo, mas muitos outros devem ser baixados de uma variedade de sites diferentes. Para suportar isso, cada entrada no `DISTFILES` pode ser seguida por dois pontos e um "nome de grupo". Cada site listado em `MASTER_SITES` é então seguido por dois pontos, e o grupo que indica quais arquivos de distribuição são baixados deste site. Por exemplo, considere um aplicativo com a divisão do código fonte em duas partes, [.filename]#source1.tar.gz# e [.filename]#source2.tar.gz#, que deve ser baixado de dois sites diferentes. O [.filename]#Makefile# do port incluiria linhas como <>. [[ports-master-sites-n-example-simple-use-one-file-per-site]] .Uso Simplificado de `MASTER_SITES:n` com Um Arquivo Por Site [example] ==== [.programlisting] .... MASTER_SITES= ftp://ftp1.example.com/:source1 \ http://www.example.com/:source2 DISTFILES= source1.tar.gz:source1 \ source2.tar.gz:source2 .... ==== Vários arquivos de distribuição podem ter o mesmo grupo. Continuando o exemplo anterior, suponha que houvesse um terceiro distfile, [.filename]#source3.tar.gz#, que é baixado do `ftp.example2.com`. O [.filename]#Makefile# seria então escrito como <>. [[ports-master-sites-n-example-simple-use-more-than-one-file-per-site]] .Uso Simplificado de `MASTER_SITES:n` com Mais de Um Arquivo Por Site [example] ==== [.programlisting] .... MASTER_SITES= ftp://ftp.example.com/:source1 \ http://www.example.com/:source2 DISTFILES= source1.tar.gz:source1 \ source2.tar.gz:source2 \ source3.tar.gz:source2 .... ==== [[ports-master-sites-n-detailed]] ==== Informação Detalhada Ok, então o exemplo anterior não refletiu as necessidades do novo port? Nesta seção vamos explicar em detalhes como o mecanismo de busca avançado `MASTER_SITES:n` funciona e como ele pode ser usado. . Elementos podem ser pós-fixados com `:__n__` onde _n_ é `[^:,]+`, isso é, _n_ poderia conceitualmente ser qualquer string alfanumérica, mas vamos limitá-lo a `[a-zA-Z_][0-9a-zA-Z_]+` por enquanto. + Além disso, a verificação de strings é case sensitive, ou seja, `n` é diferente de `N`. + No entanto, essas palavras não podem ser usadas para finalidades de pós-fixação, pois elas produzem um significado especial: `default`, `all` e `ALL` (estes são usados ​​internamente no item <>). Além disso, `DEFAULT` é uma palavra de propósito especial (verifique o item <>). . Elementos pós-fixados com `:n` pertence ao grupo `n`, `:m` pertence ao grupo `m` e assim por diante. + [[porting-master-sites-n-DEFAULT-group]] . Elementos que não estão pós-fixados são desagrupados, todos eles pertencem ao grupo especial `DEFAULT`. Quaisquer elementos pós-fixados com `DEFAULT` estão apenas sendo redundantes, a menos que um elemento pertença a ambos `DEFAULT` e outros grupos ao mesmo tempo (verifique o item <>). + Esses exemplos são equivalentes, mas o primeiro é o preferido: + [.programlisting] .... MASTER_SITES= alpha .... + [.programlisting] .... MASTER_SITES= alpha:DEFAULT .... + . Grupos não são exclusivos, um elemento pode pertencer a vários grupos diferentes ao mesmo tempo e um grupo pode ter vários elementos diferentes ou nenhum. + [[porting-master-sites-n-comma-operator]] . Quando um elemento pertence a vários grupos ao mesmo tempo, use uma vírgula (`,`). + Em vez de repetir isso várias vezes, cada vez com uma pós-fixação diferente, podemos listar vários grupos de uma vez em uma única pós-fixação. Por exemplo, `:m,n,o` marca um elemento que pertence ao grupo `m`, `n` e `o`. + Todos esses exemplos são equivalentes, mas o último é o preferido: + [.programlisting] .... MASTER_SITES= alpha alpha:SOME_SITE .... + [.programlisting] .... MASTER_SITES= alpha:DEFAULT alpha:SOME_SITE .... + [.programlisting] .... MASTER_SITES= alpha:SOME_SITE,DEFAULT .... + [.programlisting] .... MASTER_SITES= alpha:DEFAULT,SOME_SITE .... + . Todos os sites dentro de um determinado grupo são ordernados de acordo com `MASTER_SORT_AWK`. Todos os grupos dentro de `MASTER_SITES` e `PATCH_SITES` são ordenados também. + [[porting-master-sites-n-group-semantics]] . A semântica de grupo pode ser usada em qualquer uma das variáveis `MASTER_SITES`, `PATCH_SITES`, `MASTER_SITE_SUBDIR`, `PATCH_SITE_SUBDIR`, `DISTFILES` e `PATCHFILES` de acordo com esta sintaxe: .. Todos elementos `MASTER_SITES`, `PATCH_SITES`, `MASTER_SITE_SUBDIR` e `PATCH_SITE_SUBDIR` devem ser terminados com o caractere barra `/`. Se algum elemento pertencer a algum grupo, o grupo de pós-fixação `:__n__` deve vir logo após o terminador `/`. O mecanismo `MASTER_SITES:n` depende da existência do terminador `/` para evitar confundir elementos onde um `:n` é uma parte válida do elemento com ocorrências em que `:n` denota grupo `n`. Para fins de compatibilidade, uma vez que o terminador `/` não for necessário antes em ambos elementos `MASTER_SITE_SUBDIR` e `PATCH_SITE_SUBDIR`, se o caractere precedente imediato da pós-fixação não for `/` então `:n` será considerada uma parte válida do elemento em vez de uma pós-fixação de grupo, mesmo que um elemento `n` seja pós-fixado. Veja ambos <> e <>. + [[ports-master-sites-n-example-detailed-use-master-site-subdir]] .Uso Detalhado de `MASTER_SITES:n` no `MASTER_SITE_SUBDIR` [example] ==== [.programlisting] .... MASTER_SITE_SUBDIR= old:n new/:NEW .... *** Diretórios dentro do grupo `DEFAULT` -> old:n *** Diretórios dentro do grupo `NEW` -> new ==== + [[ports-master-sites-n-example-detailed-use-complete-example-master-sites]] .Uso Detalhado de `MASTER_SITES:n` com Vírgula, Vários Arquivos, Vários Sites e Vários Subdiretórios [example] ==== [.programlisting] .... MASTER_SITES= http://site1/%SUBDIR%/http://site2/:DEFAULT \ http://site3/:group3 http://site4/:group4 \ http://site5/:group5 http://site6/:group6 \ http://site7/:DEFAULT,group6 \ http://site8/%SUBDIR%/:group6,group7 \ http://site9/:group8 DISTFILES= file1 file2:DEFAULT file3:group3 \ file4:group4,group5,group6 file5:grouping \ file6:group7 MASTER_SITE_SUBDIR= directory-trial:1 directory-n/:groupn \ directory-one/:group6,DEFAULT \ directory .... O exemplo anterior resulta em uma busca detalhada. Os sites são listados na ordem exata em que serão usados. *** [.filename]#arquivo1# será obtido a partir de **** `MASTER_SITE_OVERRIDE` **** http://site1/directory-trial:1/ **** http://site1/directory-one/ **** http://site1/directory/ **** http://site2/ **** http://site7/ **** `MASTER_SITE_BACKUP` *** [.filename]#arquivo2# será baixado exatamente como o [.filename]#arquivo1# já que ambos pertencem ao mesmo grupo **** `MASTER_SITE_OVERRIDE` **** http://site1/directory-trial:1/ **** http://site1/directory-one/ **** http://site1/directory/ **** http://site2/ **** http://site7/ **** `MASTER_SITE_BACKUP` *** [.filename]#arquivo3# será obtido a partir de **** `MASTER_SITE_OVERRIDE` **** http://site3/ **** `MASTER_SITE_BACKUP` *** [.filename]#arquivo4# será obtido a partir de **** `MASTER_SITE_OVERRIDE` **** http://site4/ **** http://site5/ **** http://site6/ **** http://site7/ **** http://site8/directory-one/ **** `MASTER_SITE_BACKUP` *** [.filename]#arquivo5# será obtido a partir de **** `MASTER_SITE_OVERRIDE` **** `MASTER_SITE_BACKUP` *** [.filename]#file6# será obtido a partir de **** `MASTER_SITE_OVERRIDE` **** http://site8/ **** `MASTER_SITE_BACKUP` ==== . Como posso agrupar uma das macros especiais de [.filename]#bsd.sites.mk#, por exemplo, SourceForge (`SF`)? + Isso foi simplificado o máximo possível. Veja <>. + [[ports-master-sites-n-example-detailed-use-master-site-sourceforge]] .Uso Detalhado de `MASTER_SITES:n` com SourceForge (`SF`) [example] ==== [.programlisting] .... MASTER_SITES= http://site1/SF/something/1.0:sourceforge,TEST DISTFILES= something.tar.gz:sourceforge .... [.filename]#something.tar.gz# será obtido por todos os sites do SourceForge. ==== . Como eu uso isso com `PATCH*`? + Todos os exemplos foram feitos com `MASTER*` mas eles funcionam exatamente da mesma forma com `PATCH*` como pode ser visto em <>. + [[ports-master-sites-n-example-detailed-use-patch-sites]] .Uso Simplificado de `MASTER_SITES:n` com `PATCH_SITES` [example] ==== [.programlisting] .... PATCH_SITES= http://site1/ http://site2/:test PATCHFILES= patch1:test .... ==== [[port-master-sites-n-what-changed]] ==== O que Muda para os Ports? O que Não Funciona? [lowerroman] . Todos os ports atuais permanecem os mesmos. A feature `MASTER_SITES:n` só é ativada se houver elementos pós-fixados com `:__n__` como elementos de acordo com as regras de sintaxe acima, especialmente como mostrado no item <>. [[porting-master-sites-n-what-changes-in-port-targets]] . Os targets de port permanecem os mesmos: `checksum`, `makesum`, `patch`, `configure`, `build`, etc. Com as exceções óbvias de `do-fetch`, `fetch-list`, `master-sites` e `patch-sites`. ** `do-fetch`: implementa o novo agrupamento pós-fixado `DISTFILES` e `PATCHFILES` com seus elementos de grupo correspondentes dentro de ambos `MASTER_SITES` e `PATCH_SITES` que usam elementos de grupo correspondentes dentro de ambos `MASTER_SITE_SUBDIR` e `PATCH_SITE_SUBDIR`. Verifique <>. ** `fetch-list`: funciona como o antigo `fetch-list`, com a exceção de que faz agrupamentos exatamente como o `do-fetch`. ** `master-sites` e `patch-sites`: (incompatível com versões mais antigas) somente retorna os elementos do grupo `DEFAULT`; na verdade, eles executam os targets `master-sites-default` e `patch-sites-default` respectivamente. + Além disso, usar o target `master-sites-all` ou `patch-sites-all` é o preferido para verificar diretamente `MASTER_SITES` ou `PATCH_SITES`. Além disso, não é garantido que a checagem direta funcione em versões futuras. Veja <> para obter mais informações sobre esses novos tagets de port. . Novos Targets de Port .. Existem targets `master-sites-_n_` e `patch-sites-_n_` que listarão os elementos do respectivo grupo _n_ dentro de `MASTER_SITES` e `PATCH_SITES` respectivamente. Por exemplo, ambos `master-sites-DEFAULT` e `patch-sites-DEFAULT` retornarão os elementos do grupo `DEFAULT`, `master-sites-test` e `patch-sites-test` do grupo `test`. [[porting-master-sites-n-new-port-targets-master-sites-all]] .. Há novos targets `master-sites-all` e `patch-sites-all` que fazem o trabalho dos antigos `master-sites` e `patch-sites`. Eles retornam os elementos de todos os grupos como se todos pertencessem ao mesmo grupo, com a ressalva de que lista tantos `MASTER_SITE_BACKUP` e `MASTER_SITE_OVERRIDE` como existem grupos definidos dentro de qualquer `DISTFILES` ou `PATCHFILES`; respectivamente para `master-sites-all` e `patch-sites-all`. [[makefile-dist_subdir]] === `DIST_SUBDIR` Não deixe o [.filename]#/usr/ports/distfiles# bagunçado. Se um port exigir que muitos arquivos sejam baixados, ou que contenha um arquivo que tenha um nome que possa entrar em conflito com outros ports (por exemplo, [.filename]#Makefile#), defina `DIST_SUBDIR` com o nome do port (`${PORTNAME}` ou `${PKGNAMEPREFIX}${PORTNAME}`). Isso vai mudar o `DISTDIR` do padrão [.filename]#/usr/ports/distfiles# para [.filename]#/usr/ports/distfiles/${DIST_SUBDIR}#,e assim, será colocado tudo o que é necessário para o port nesse subdiretório. Ele também examinará o subdiretório com o mesmo nome no site principal de backup em http://distcache.FreeBSD.org[http://distcache.FreeBSD.org] (Configurar o `DISTDIR` explicitamente no [.filename]#Makefile# não fará isso funcionar, então por favor use `DIST_SUBDIR`.) [NOTE] ==== Isso não afeta o `MASTER_SITES` definido no [.filename]#Makefile#. ==== [[makefile-maintainer]] == `MAINTAINER` Defina seu endereço de email aqui. Por favor. _:-)_ Apenas um único endereço sem a parte de comentário é permitido como um valor para `MAINTAINER`. O formato usado é `user@hostname.domain`. Por favor, não inclua nenhum texto descritivo, como um nome nesta entrada. Isso confunde a infraestrutura do Ports e a maioria das ferramentas que a usam. O mantenedor é responsável por manter o port atualizado e garantir que elo funcione corretamente. Para obter uma descrição detalhada das responsabilidades de um mantenedor de port, consulte link:{contributing}#maintain-port[O desafio para os mantenedores de port]. [NOTE] ==== Um mantenedor se voluntaria para manter um port em bom estado de funcionamento. Os mantenedores têm a responsabilidade primária por seus ports, mas não possuem propriedade exclusiva. Os ports existem para o benefício da comunidade e, na realidade, pertencem à comunidade. O que isso significa é que outras pessoas além do mantenedor, também podem fazer alterações em um port. Grandes mudanças na Coleção de Ports podem exigir mudanças em muitos ports. A Equipe de Gerenciamento do Ports do FreeBSD ou membros de outras equipes podem modificar ports para corrigir problemas de dependência ou outros problemas, como um bump de versão para uma atualização de biblioteca compartilhada. Alguns tipos de correções tem "aprovação implícita" da Equipe de Gerenciamento do Ports mailto:portmgr@FreeBSD.org[portmgr@FreeBSD.org], permitindo que qualquer committer conserte essas categorias de problemas em qualquer port. Essas correções não precisam da aprovação do mantenedor. Aprovação implícita para a maioria dos ports se aplicam para correções como mudanças de infraestrutura, trivialidades e correções _testadas_ de compilação e execução. A lista atual está disponibilizada em link:{committers-guide}#ports-qa-misc-blanket-approval[Seção Ports do Guia dos Committers]. ==== Outras alterações no port serão enviadas ao mantenedor para revisão e aprovação antes de se fazer o commit. Se o mantenedor não responder a uma solicitação de atualização após duas semanas (excluindo os principais feriados), isso será considerado como timeout do mantenedor, e a atualização poderá ser feita sem a aprovação explícita do mesmo. Se o mantenedor não responder dentro de três meses, ou se houver três timeouts consecutivos, então o mantenedor é considerado ausente, e todas os seus ports podem ser atribuídos de volta para à comunidade. Exceções para isso são quaisquer ports mantidos pela Equipe de Gerenciamento de Ports mailto:portmgr@FreeBSD.org[portmgr@FreeBSD.org] ou pela Equipe de Oficias de Segurança mailto:security-officer@FreeBSD.org[security-officer@FreeBSD.org]. Nenhum commit não autorizado pode ser feito em ports mantidos por esses grupos. Reservamo-nos o direito de modificar as submissões do mantenedor para melhor adequar as políticas e os estilos existentes da Coleção de Ports sem aprovação explicita do remetente ou do mantenedor. Além disso, grandes alterações de infraestrutura podem resultar na modificação de um port sem o consentimento do mantenedor. Estes tipos de alterações nunca irão afetar a funcionalidade do port. A Equipe de Gerenciamento de Ports mailto:portmgr@FreeBSD.org[portmgr@FreeBSD.org] reserva o direito de revogar ou substituir a propriedade de mantenedor de qualquer pessoa por qualquer motivo, e a Equipe de Oficiais de Segurança mailto:security-officer@FreeBSD.org[security-officer@FreeBSD.org] reserva o direito de revogar ou substituir a propriedade de mantenedor por razões de segurança. [[makefile-comment]] == `COMMENT` O comentário é uma descrição de uma linha de um port mostrada por `pkg info`. Por favor, siga estas regras ao compor: . A string COMMENT deve ter 70 caracteres ou menos. . _Não_ inclua o nome do pacote ou o número da versão do software. . O comentário deve começar com uma letra maiúscula e terminar sem um ponto final. . Não comece com um artigo indefinido (isto é, A ou Um). . Capitalize nomes como Apache, JavaScript ou Perl. . Use uma vírgula serial para listas de palavras: "verde, vermelho, e azul." . Verifique erros de ortografia. Aqui está um exemplo: [.programlisting] .... COMMENT= Cat chasing a mouse all over the screen .... A variável COMMENT vem depois da variável MAINTAINER no [.filename]#Makefile#. [[licenses]] == Licenças Cada port deve documentar a licença sob a qual está disponível. Se não for uma licença aprovada pelo OSI, também deve documentar quaisquer restrições à redistribuição. [[licenses-license]] === `LICENSE` Um nome abreviado para a licença ou licenças se mais de uma licença for aplicada. Se for uma das licenças listadas no <>, apenas as variáveis `LICENSE_FILE` e `LICENSE_DISTFILES` podem ser definidas. Se esta for uma licença que não tenha sido definida na infraestrutura de ports (veja <>), `LICENSE_PERMS` e `LICENSE_NAME` devem ser definidos, juntamente com `LICENSE_FILE` ou `LICENSE_TEXT`. `LICENSE_DISTFILES` e `LICENSE_GROUPS` também podem ser definidos, mas não é necessário. As licenças pré-definidas são mostradas em <>. A lista atual está sempre disponível em [.filename]#Mk/bsd.licenses.db.mk#. [[licenses-license-ex1]] .Uso Mais Simples, Licenças Predefinidas [example] ==== Quando o [.filename]#README# de algum software diz "This software is under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version." mas não fornece o arquivo de licença, use isto: [.programlisting] .... LICENSE= LGPL21+ .... Quando o software fornece o arquivo de licença, use isto: [.programlisting] .... LICENSE= LGPL21+ LICENSE_FILE= ${WRKSRC}/COPYING .... ==== Para as licenças predefinidas, as permissões padrão são `dist-mirror dist-sell pkg-mirror pkg-sell auto-accept`. [[licenses-license-list]] .Lista de Licenças Predefinidas [cols="1,1,1,1", frame="none", options="header"] |=== | Nome Curto | Nome | Grupo | Permissões |`AGPLv3` |GNU Affero General Public License version 3 |`FSF GPL OSI` |(padrão) |`AGPLv3+` |GNU Affero General Public License version 3 (ou maior) |`FSF GPL OSI` |(padrão) |`APACHE10` |Apache License 1.0 |`FSF` |(padrão) |`APACHE11` |Apache License 1.1 |`FSF OSI` |(padrão) |`APACHE20` |Apache License 2.0 |`FSF OSI` |(padrão) |`ART10` |Artistic License version 1.0 |`OSI` |(padrão) |`ART20` |Artistic License version 2.0 |`FSF GPL OSI` |(padrão) |`ARTPERL10` |Artistic License (perl) version 1.0 |`OSI` |(padrão) |`BSD` |BSD license Generic Version (deprecated) |`FSF OSI COPYFREE` |(padrão) |`BSD2CLAUSE` |BSD 2-clause "Simplified" License |`FSF OSI COPYFREE` |(padrão) |`BSD3CLAUSE` |BSD 3-clause "New" or "Revised" License |`FSF OSI COPYFREE` |(padrão) |`BSD4CLAUSE` |BSD 4-clause "Original" or "Old" License |`FSF` |(padrão) |`BSL` |Boost Software License |`FSF OSI COPYFREE` |(padrão) |`CC-BY-1.0` |Creative Commons Attribution 1.0 | |(padrão) |`CC-BY-2.0` |Creative Commons Attribution 2.0 | |(padrão) |`CC-BY-2.5` |Creative Commons Attribution 2.5 | |(padrão) |`CC-BY-3.0` |Creative Commons Attribution 3.0 | |(padrão) |`CC-BY-4.0` |Creative Commons Attribution 4.0 | |(padrão) |`CC-BY-NC-1.0` |Creative Commons Attribution Non Commercial 1.0 | |`dist-mirror pkg-mirror auto-accept` |`CC-BY-NC-2.0` |Creative Commons Attribution Non Commercial 2.0 | |`dist-mirror pkg-mirror auto-accept` |`CC-BY-NC-2.5` |Creative Commons Attribution Non Commercial 2.5 | |`dist-mirror pkg-mirror auto-accept` |`CC-BY-NC-3.0` |Creative Commons Attribution Non Commercial 3.0 | |`dist-mirror pkg-mirror auto-accept` |`CC-BY-NC-4.0` |Creative Commons Attribution Non Commercial 4.0 | |`dist-mirror pkg-mirror auto-accept` |`CC-BY-NC-ND-1.0` |Creative Commons Attribution Non Commercial No Derivatives 1.0 | |`dist-mirror pkg-mirror auto-accept` |`CC-BY-NC-ND-2.0` |Creative Commons Attribution Non Commercial No Derivatives 2.0 | |`dist-mirror pkg-mirror auto-accept` |`CC-BY-NC-ND-2.5` |Creative Commons Attribution Non Commercial No Derivatives 2.5 | |`dist-mirror pkg-mirror auto-accept` |`CC-BY-NC-ND-3.0` |Creative Commons Attribution Non Commercial No Derivatives 3.0 | |`dist-mirror pkg-mirror auto-accept` |`CC-BY-NC-ND-4.0` |Creative Commons Attribution Non Commercial No Derivatives 4.0 | |`dist-mirror pkg-mirror auto-accept` |`CC-BY-NC-SA-1.0` |Creative Commons Attribution Non Commercial Share Alike 1.0 | |`dist-mirror pkg-mirror auto-accept` |`CC-BY-NC-SA-2.0` |Creative Commons Attribution Non Commercial Share Alike 2.0 | |`dist-mirror pkg-mirror auto-accept` |`CC-BY-NC-SA-2.5` |Creative Commons Attribution Non Commercial Share Alike 2.5 | |`dist-mirror pkg-mirror auto-accept` |`CC-BY-NC-SA-3.0` |Creative Commons Attribution Non Commercial Share Alike 3.0 | |`dist-mirror pkg-mirror auto-accept` |`CC-BY-NC-SA-4.0` |Creative Commons Attribution Non Commercial Share Alike 4.0 | |`dist-mirror pkg-mirror auto-accept` |`CC-BY-ND-1.0` |Creative Commons Attribution No Derivatives 1.0 | |(padrão) |`CC-BY-ND-2.0` |Creative Commons Attribution No Derivatives 2.0 | |(padrão) |`CC-BY-ND-2.5` |Creative Commons Attribution No Derivatives 2.5 | |(padrão) |`CC-BY-ND-3.0` |Creative Commons Attribution No Derivatives 3.0 | |(padrão) |`CC-BY-ND-4.0` |Creative Commons Attribution No Derivatives 4.0 | |(padrão) |`CC-BY-SA-1.0` |Creative Commons Attribution Share Alike 1.0 | |(padrão) |`CC-BY-SA-2.0` |Creative Commons Attribution Compartilhar Alike 2.0 | |(padrão) |`CC-BY-SA-2.5` |Creative Commons Attribution Share Alike 2.5 | |(padrão) |`CC-BY-SA-3.0` |Creative Commons Attribution Share Alike 3.0 | |(padrão) |`CC-BY-SA-4.0` |Creative Commons Attribution Share Alike 4.0 | |(padrão) |`CC0-1.0` |Creative Commons Zero v1.0 Universal |`FSF GPL COPYFREE` |(padrão) |`CDDL` |Common Development and Distribution License |`FSF OSI` |(padrão) |`CPAL-1.0` |Common Public Attribution License |`FSF OSI` |(padrão) |`ClArtistic` |Clarified Artistic License |`FSF GPL OSI` |(padrão) |`EPL` |Eclipse Public License |`FSF OSI` |(padrão) |`GFDL` |GNU Free Documentation License |`FSF` |(padrão) |`GMGPL` |GNAT Modified General Public License |`FSF GPL OSI` |(padrão) |`GPLv1` |GNU General Public License version 1 |`FSF GPL OSI` |(padrão) |`GPLv1+` |GNU General Public License version 1 (or later) |`FSF GPL OSI` |(padrão) |`GPLv2` |GNU General Public License version 2 |`FSF GPL OSI` |(padrão) |`GPLv2+` |GNU General Public License version 2 (or later) |`FSF GPL OSI` |(padrão) |`GPLv3` |GNU General Public License version 3 |`FSF GPL OSI` |(padrão) |`GPLv3+` |GNU General Public License version 3 (or later) |`FSF GPL OSI` |(padrão) |`GPLv3RLE` |GNU GPL version 3 Runtime Library Exception |`FSF GPL OSI` |(padrão) |`GPLv3RLE+` |GNU GPL version 3 Runtime Library Exception (or later) |`FSF GPL OSI` |(padrão) |`ISCL` |Internet Systems Consortium License |`FSF GPL OSI COPYFREE` |(padrão) |`LGPL20` |GNU Library General Public License version 2.0 |`FSF GPL OSI` |(padrão) |`LGPL20+` |GNU Library General Public License version 2.0 (or later) |`FSF GPL OSI` |(padrão) |`LGPL21` |GNU Lesser General Public License version 2.1 |`FSF GPL OSI` |(padrão) |`LGPL21+` |GNU Lesser General Public License version 2.1 (or later) |`FSF GPL OSI` |(padrão) |`LGPL3` |GNU Lesser General Public License version 3 |`FSF GPL OSI` |(padrão) |`LGPL3+` |GNU Lesser General Public License version 3 (or later) |`FSF GPL OSI` |(padrão) |`LPPL10` |LaTeX Project Public License version 1.0 |`FSF OSI` |`dist-mirror dist-sell` |`LPPL11` |LaTeX Project Public License version 1.1 |`FSF OSI` |`dist-mirror dist-sell` |`LPPL12` |LaTeX Project Public License version 1.2 |`FSF OSI` |`dist-mirror dist-sell` |`LPPL13` |LaTeX Project Public License version 1.3 |`FSF OSI` |`dist-mirror dist-sell` |`LPPL13a` |LaTeX Project Public License version 1.3a |`FSF OSI` |`dist-mirror dist-sell` |`LPPL13b` |LaTeX Project Public License version 1.3b |`FSF OSI` |`dist-mirror dist-sell` |`LPPL13c` |LaTeX Project Public License version 1.3c |`FSF OSI` |`dist-mirror dist-sell` |`MIT` |MIT license / X11 license |`COPYFREE FSF GPL OSI` |(padrão) |`MPL10` |Mozilla Public License version 1.0 |`FSF OSI` |(padrão) |`MPL11` |Mozilla Public License version 1.1 |`FSF OSI` |(padrão) |`MPL20` |Mozilla Public License version 2.0 |`FSF OSI` |(padrão) |`NCSA` |University of Illinois/NCSA Open Source License |`COPYFREE FSF GPL OSI` |(padrão) |`NONE` |No license specified | |`none` |`OFL10` |SIL Open Font License version 1.0 (http://scripts.sil.org/OFL) |`FONTS` |(padrão) |`OFL11` |SIL Open Font License version 1.1 (http://scripts.sil.org/OFL) |`FONTS` |(padrão) |`OWL` |Open Works License (owl.apotheon.org) |`COPYFREE` |(padrão) |`OpenSSL` |Licença OpenSSL |`FSF` |(padrão) |`PD` |Public Domain |`GPL COPYFREE` |(padrão) |`PHP202` |PHP License version 2.02 |`FSF OSI` |(padrão) |`PHP30` |PHP License version 3.0 |`FSF OSI` |(padrão) |`PHP301` |PHP License versão 3.01 |`FSF OSI` |(padrão) |`PSFL` |Python Software Foundation License |`FSF GPL OSI` |(padrão) |`PostgreSQL` |PostgreSQL License |`FSF GPL OSI COPYFREE` |(padrão) |`RUBY` |Ruby License |`FSF` |(padrão) |`UNLICENSE` |The Unlicense |`COPYFREE FSF GPL` |(padrão) |`WTFPL` |Do What the Fuck You Want To Public License version 2 |`GPL FSF COPYFREE` |(padrão) |`WTFPL1` |Do What the Fuck You Want To Public License version 1 |`GPL FSF COPYFREE` |(padrão) |`ZLIB` |zlib License |`GPL FSF OSI` |(padrão) |`ZPL21` |Zope Public License version 2.1 |`GPL OSI` |(padrão) |=== [[licenses-license_perms]] === `LICENSE_PERMS` e `LICENSE_PERMS_NAME` Permissões. Use `none` se vazio. .Lista de Permissões de Licença [[licenses-license_perms-dist-mirror]] `dist-mirror`:: A redistribuição dos arquivos de distribuição é permitida. Os arquivos de distribuição serão adicionados ao FreeBSD CDN `MASTER_SITE_BACKUP`. [[licenses-license_perms-no-dist-mirror]] `no-dist-mirror`:: A redistribuição dos arquivos de distribuição é proibida. Isso é equivalente a <>. Os arquivos de distribuição _não_ serão adicionados ao FreeBSD CDN `MASTER_SITE_BACKUP`. [[licenses-license_perms-dist-sell]] `dist-sell`:: A venda de arquivos de distribuição é permitida. Os arquivos de distribuição estarão presentes nas imagens do instalador. [[licenses-license_perms-no-dist-sell]] `no-dist-sell`:: A venda de arquivos de distribuição é proibida. Isso é equivalente a <>. [[licenses-license_perms-pkg-mirror]] `pkg-mirror`:: É permitida a redistribuição gratuita do pacote. O pacote será distribuído na CDN de pacotes do FreeBSD https://pkg.freebsd.org/[https://pkg.freebsd.org/]. [[licenses-license_perms-no-pkg-mirror]] `no-pkg-mirror`:: É proibida a redistribuição gratuita do pacote. Equivalente à definir <>. O pacote _não_ será distribuído a partir da CDN de pacotes do FreeBSD https://pkg.freebsd.org/[https://pkg.freebsd.org/]. [[licenses-license_perms-pkg-sell]] `pkg-sell`:: A venda do pacote é permitida. O pacote estará presente nas imagens do instalador. [[licenses-license_perms-no-pkg-sell]] `no-pkg-sell`:: A venda de pacotes é proibida. Isso é equivalente a definir <>. O pacote _não_ estará presente nas imagens do instalador. [[licenses-license_perms-auto-accept]] `auto-accept`:: A licença é aceita por padrão. Os prompts para aceitar uma licença não são exibidos a menos que o usuário tenha definido `LICENSES_ASK`. Use isto, a menos que a licença indique que o usuário deve aceitar os termos da licença. [[licenses-license_perms-no-auto-accept]] `no-auto-accept`:: A licença não é aceita por padrão. O usuário sempre será solicitado a confirmar a aceitação desta licença. Isso deve ser usado se a licença declarar que o usuário deve aceitar seus termos. Quando ambos `_permission_` e `no-_permission_` estiverem presentes o `no-_permission_` vai cancelar a `_permission_`. Quando `_permission_` não estiver presente, é considerado uma `no-_permission_`. [WARNING] ==== Algumas permissões que estiverem faltando, impedirão que um port (e todos os ports dependendo dele) sejam utilizados pelos usuários do pacote: Um port sem a permissão `auto-accept` nunca será compilado e todos os ports dependendo dele serão ignorados. Um port sem a permissão `pkg-mirror` será removido, assim como todos os ports que dependam dele, isso depois da compilação e então eles nunca serão distribuídos. ==== [[licenses-license_perms-ex1]] .Licença Não Padrão [example] ==== Leia os termos da licença e traduza-os usando as permissões disponíveis. [.programlisting] .... LICENSE= UNKNOWN LICENSE_NAME= unknown LICENSE_TEXT= Esse programa NÃO é de domínio publico.\ pode ser distribuído livremente para propósitos não comerciais apenas,\ e NÃO HÁ GARANTIA PARA ESSE PROGRAMA. LICENSE_PERMS= dist-mirror no-dist-sell pkg-mirror no-pkg-sell auto-accept .... ==== [[licenses-license_perms-ex2]] .Licenças Padrão e Não Padrão [example] ==== Leia os termos da licença e expresse-os usando as permissões disponíveis. Em caso de dúvida, peça orientação na http://lists.FreeBSD.org/mailman/listinfo/freebsd-ports[lista de discussão de ports do FreeBSD]. [.programlisting] .... LICENSE= WARSOW GPLv2 LICENSE_COMB= multi LICENSE_NAME_WARSOW= Warsow Content License LICENSE_FILE_WARSOW= ${WRKSRC}/docs/license.txt LICENSE_PERMS_WARSOW= dist-mirror pkg-mirror auto-accept .... Quando as permissões das licenças GPLv2 e UNKNOWN são misturadas, o port termina com `dist-mirror dist-sell pkg-mirror pkg-sell auto-accept dist-mirror no-dist-sell pkg-mirror no-pkg-sell auto-accept`. O `no-_permissions_` cancela as _permissions_. A lista resultante de permissões é _dist-mirror pkg-mirror auto-accept_. Os arquivos de distribuição e os pacotes não estarão disponíveis nas imagens do instalador. ==== [[licenses-license_groups]] === `LICENSE_GROUPS` e `LICENSE_GROUPS_NAME` Grupos que a licença pertence. .Lista de Grupos de Licenças Predefinidas [[licenses-license_groups-FSF]] `FSF`:: Aprovada pela Free Software Foundation, veja http://www.fsf.org/licensing[FSF Licensing & Compliance Team]. [[licenses-license_groups-GPL]] `GPL`:: Compatível com GPL [[licenses-license_groups-OSI]] `OSI`:: Aprovado pelo OSI, veja a pagina Open Source Initiative http://opensource.org/licenses[Open Source Licenses]. [[licenses-license_groups-COPYFREE]] `COPYFREE`:: Segue a Copyfree Standard Definition, consulte a pagina http://copyfree.org/standard/licenses[Copyfree Licenses]. [[licenses-license_groups-FONTS]] `FONTS`:: Licenças de fonte [[licenses-license_name]] === `LICENSE_NAME` e `LICENSE_NAME_NAME` Nome completo da licença. [[licenses-license_name-ex1]] .`LICENSE_NAME` [example] ==== [.programlisting] .... LICENSE= UNRAR LICENSE_NAME= UnRAR License LICENSE_FILE= ${WRKSRC}/license.txt LICENSE_PERMS= dist-mirror dist-sell pkg-mirror pkg-sell auto-accept .... ==== [[licenses-license_file]] === `LICENSE_FILE` e `LICENSE_FILE_NOME` Caminho completo para o arquivo que contém o texto da licença, geralmente [.filename]#${WRKSRC}/some/file#. Se o arquivo não estiver no distfile e seu conteúdo for muito longo para ser colocado em <>, insira o texto em um novo arquivo em [.filename]#${FILESDIR}#. [[licenses-license_file-ex1]] .`LICENSE_FILE` [example] ==== [.programlisting] .... LICENSE= GPLv3+ LICENSE_FILE= ${WRKSRC}/COPYING .... ==== [[licenses-license_text]] === `LICENSE_TEXT` e `LICENSE_TEXT_NAME` Texto para usar como uma licença. Útil quando a licença não está nos arquivos de distribuição e seu texto é curto. [[licenses-license_text-ex1]] .`LICENSE_TEXT` [example] ==== [.programlisting] .... LICENSE= UNKNOWN LICENSE_NAME= unknown LICENSE_TEXT= This program is NOT in public domain.\ It can be freely distributed for non-commercial purposes only,\ and THERE IS NO WARRANTY FOR THIS PROGRAM. LICENSE_PERMS= dist-mirror no-dist-sell pkg-mirror no-pkg-sell auto-accept .... ==== [[licenses-license_distfiles]] === `LICENSE_DISTFILES` e `LICENSE_DISTFILES_NAME` Os arquivos de distribuição aos quais as licenças se aplicam. O padrão é para todos os arquivos de distribuição. [[licenses-license_distfiles-ex1]] .`LICENSE_DISTFILES` [example] ==== Usado quando os arquivos de distribuição não possuem a mesma licença. Por exemplo, um possui uma licença de código e outro possui alguns trabalhos de arte que não podem ser redistribuídos: [.programlisting] .... MASTER_SITES= SF/some-game DISTFILES= ${DISTNAME}${EXTRACT_SUFX} artwork.zip LICENSE= BSD3CLAUSE ARTWORK LICENSE_COMB= dual LICENSE_NAME_ARTWORK= The game artwork license LICENSE_TEXT_ARTWORK= The README says that the files cannot be redistributed LICENSE_PERMS_ARTWORK= pkg-mirror pkg-sell auto-accept LICENSE_DISTFILES_BSD3CLAUSE= ${DISTNAME}${EXTRACT_SUFX} LICENSE_DISTFILES_ARTWORK= artwork.zip .... ==== [[licenses-license_comb]] === `LICENSE_COMB` Defina como `multi` se todas as licenças se aplicarem. Defina como `dual` se qualquer uma das licenças se aplica. O padrão é definido para `single`. [[licenses-license_comb-ex1]] .Licenças Duplas [example] ==== Quando um port diz "This software may be distributed under the GNU General Public License or the Artistic License">, isso significa que qualquer licença pode ser usada. Use isto: [.programlisting] .... LICENSE= ART10 GPLv1 LICENSE_COMB= dual .... Se os arquivos de licença forem fornecidos, use assim: [.programlisting] .... LICENSE= ART10 GPLv1 LICENSE_COMB= dual LICENSE_FILE_ART10= ${WRKSRC}/Artistic LICENSE_FILE_GPLv1= ${WRKSRC}/Copying .... ==== [[licenses-license_comb-ex2]] .Múltiplas Licenças [example] ==== Quando parte de um port tem uma licença, e outra parte tem uma licença diferente, use `multi`: [.programlisting] .... LICENSE= GPLv2 LGPL21+ LICENSE_COMB= multi .... ==== [[makefile-portscout]] == `PORTSCOUT` Portscout é um utilitário de verificação de distfile automatizado para a Coleção de Ports do FreeBSD, descrito em detalhes em <>. `PORTSCOUT` define condições especiais dentro das quais o scanner distfile do Portscout é restrito. Situações em que o `PORTSCOUT` é configurado: * Quando distfiles precisam ser ignorados, seja para versões específicas, ou para pequenas revisões específicas. Por exemplo, para excluir a versão _8.2_ das verificações de versão de distfile porque é conhecido por estar quebrado, adicione: + [.programlisting] .... PORTSCOUT= ignore:8.2 .... * Quando versões específicas ou revisões maiores e menores específicas de um distfile devem ser verificadas. Por exemplo, se somente a versão _0.6.4_ deve ser monitorado porque versões mais recentes têm problemas de compatibilidade com o FreeBSD, adicione: + [.programlisting] .... PORTSCOUT= limit:^0\.6\.4 .... * Quando os URLs que listam as versões disponíveis diferem dos URLs de download. Por exemplo, para limitar as verificações de versão do arquivo distfile à página de download para o port package:databases/pgtune[], adicione: + [.programlisting] .... PORTSCOUT= site:http://pgfoundry.org/frs/?group_id=1000416 .... [[makefile-depend]] == Dependências Muitos ports dependem de outros ports. Esta é uma característica muito conveniente da maioria dos sistemas operacionais Unix-like, incluindo FreeBSD. Vários ports podem compartilhar uma dependência comum, ao invés de agrupar essa dependência com cada port ou pacote que precisa dela. Há sete variáveis ​​que podem ser usadas para garantir que todos os bits necessários estejam na máquina do usuário. Existem também algumas variáveis ​​de dependência pré-suportadas para casos comuns, além de algumas outras para controlar o comportamento das dependências. [IMPORTANT] ==== Quando o software possui dependências extras que fornecem recursos extras, as dependências básicas listadas em `*_DEPENDS` devem incluir as dependências extras que beneficiariam a maioria dos usuários. As dependências básicas nunca devem ser um conjunto de dependências "mínima". O objetivo não é incluir todas as dependências possíveis. Inclua apenas aquelas que beneficiarão a maioria das pessoas. ==== [[makefile-lib_depends]] === `LIB_DEPENDS` Esta variável especifica as bibliotecas compartilhadas das quais este port depende. É uma lista de tuplas _lib:dir_ onde _lib_ é o nome da biblioteca compartilhada, _dir_ é o diretório no qual encontrá-lo, caso não esteja disponível. Por exemplo, [.programlisting] .... LIB_DEPENDS= libjpeg.so:graphics/jpeg .... irá verificar se há uma biblioteca jpeg compartilhada com qualquer versão no subdiretório [.filename]#graphics/jpeg# da árvore de ports para compilar e instalar se não for encontrado. A dependência é verificada duas vezes, uma vez dentro do target `build` e depois dentro do target `install`. Além disso, o nome da dependência é colocado no pacote para que o `pkg-install` (veja man:pkg-install[8]) a instale automaticamente se a mesma não estiver no sistema do usuário. [[makefile-run_depends]] === `RUN_DEPENDS` Esta variável especifica arquivos executáveis ou arquivos para os quais este port depende durante o tempo de execução. É uma lista de tuplas path:dir:[``target``] onde _path_ é o nome do executável ou arquivo,_dir_ é o diretório no qual encontrá-lo, caso não esteja disponível, e o _target_ é o target para chamar nesse diretório. E se o _path_ começar com uma barra (`/`), ele será tratado como um arquivo e sua existência é testada com `test -e`; caso contrário, é assumido como um executável e `which -s` é usado para determinar se o programa existe no caminho de pesquisa. Por exemplo, [.programlisting] .... RUN_DEPENDS= ${LOCALBASE}/news/bin/innd:news/inn \ xmlcatmgr:textproc/xmlcatmgr .... irá verificar se o arquivo ou diretório [.filename]#/usr/local/news/bin/innd# existe, e compilar e instalá-lo a partir do subdiretório [.filename]#news/inn# da árvore de ports, caso não seja encontrado. Ele também verá se um executável chamado `xmlcatmgr` está no caminho de pesquisa em [.filename]#textproc/xmlcatmgr# para compilar e instalar se não for encontrado. [NOTE] ==== Nesse caso, `innd` é na verdade um executável; se um executável estiver em um local que não deve estar no caminho de pesquisa, use o nome do caminho completo. ==== [NOTE] ==== A pesquisa oficial `PATH` usado no cluster de construção de ports é [.programlisting] .... /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin .... ==== A dependência é verificada a partir do target `install`. Além disso, o nome da dependência é colocado no pacote para que o `pkg-install` (veja man:pkg-install[8]) a instale automaticamente se a mesma não estiver no sistema do usuário. A parte _target_ pode ser omitida se for igual a `DEPENDS_TARGET`. Uma situação bastante comum é quando `RUN_DEPENDS` é literalmente o mesmo que `BUILD_DEPENDS`, especialmente se o software portado é escrito em uma linguagem de script ou se requer o mesmo ambiente de compilação e tempo de execução. Neste caso, é tentador e intuitivo atribuir diretamente um ao outro: [.programlisting] .... RUN_DEPENDS= ${BUILD_DEPENDS} .... No entanto, essa atribuição pode poluir as dependências de tempo de execução com entradas não definidas no `BUILD_DEPENDS` original do port. Isso acontece por causa de uma avaliação preguiçosa de atribuição de variáveis do man:make[1]. Considere um [.filename]#Makefile# com `USES_*`, que são processados ​​por [.filename]#ports/Mk/bsd.*.mk# para aumentar as dependências iniciais de compilação. Por exemplo, `USES=gmake` adiciona package:devel/gmake[] para `BUILD_DEPENDS`. Para evitar que essas dependências adicionais poluam `RUN_DEPENDS`, crie outra variável com o conteúdo atual de `BUILD_DEPENDS` e atribua-a para ambos `BUILD_DEPENDS` e `RUN_DEPENDS`: [.programlisting] .... MY_DEPENDS= some:devel/some \ other:lang/other BUILD_DEPENDS= ${MY_DEPENDS} RUN_DEPENDS= ${MY_DEPENDS} .... [IMPORTANT] ==== _Não_ use `:=` para atribuir `BUILD_DEPENDS` para `RUN_DEPENDS` ou vice-versa. Todas as variáveis ​​são expandidas imediatamente, o que é exatamente a coisa errada a fazer e quase sempre um fracasso. ==== [[makefile-build_depends]] === `BUILD_DEPENDS` Esta variável especifica executáveis ​​ou arquivos que este port requer para ser compilado. Como `RUN_DEPENDS`, ela é uma lista de tuplas path:dir:[``target``]. Por exemplo, [.programlisting] .... BUILD_DEPENDS= unzip:archivers/unzip .... irá procurar por um executável chamado `unzip`, e ir para o subdiretório [.filename]#archivers/unzip# da árvore de ports para compilar e instalar se não for encontrado. [NOTE] ==== "build" aqui significa tudo, desde a extração até a compilação. A dependência é verificada a partir do target `extract`. A parte do _target_ pode ser omitida se for igual a `DEPENDS_TARGET` ==== [[makefile-fetch_depends]] === `FETCH_DEPENDS` Esta variável especifica executáveis ​​ou arquivos que este port requer para fazer os downloads. Como os dois anteriores, é uma lista de tuplas path:dir:[``target``]. Por exemplo, [.programlisting] .... FETCH_DEPENDS= ncftp2:net/ncftp2 .... irá procurar por um executável chamado `ncftp2` e ir para o subdiretório [.filename]#net/ncftp2# da árvore de ports para compilar e instalar se não for encontrado. A dependência é verificada a partir do target `fetch`. A parte _target_ pode ser omitida se for igual a `DEPENDS_TARGET`. [[makefile-extract_depends]] === `EXTRACT_DEPENDS` Esta variável especifica executáveis ​​ou arquivos que este port requer para extração. Como no anterior, é uma lista de tuplas path:dir:[``target``]. Por exemplo, [.programlisting] .... EXTRACT_DEPENDS= unzip:archivers/unzip .... irá procurar por um executável chamado `unzip`, e ir para o subdiretório [.filename]#archivers/unzip# da árvore de ports para compilar e instalar se não for encontrado. A dependência é verificada a partir do target `extract`. A parte _target_ pode ser omitida se for igual a `DEPENDS_TARGET`. [NOTE] ==== Use esta variável somente se a extração ainda não funcionar (o padrão usa `tar`) e não funciona com `USES=tar`, `USES=lha` ou `USES=zip` descrito em <>. ==== [[makefile-patch_depends]] === `PATCH_DEPENDS` Esta variável especifica executáveis ​​ou arquivos que este port requer para aplicar patches. Como no anterior, é uma lista de path:dir:[``target``]. Por exemplo, [.programlisting] .... PATCH_DEPENDS= ${NONEXISTENT}:java/jfc:extract .... vai descer para o subdiretório [.filename]#java/jfc# da árvore de ports para extraí-lo. A dependência é verificada a partir do target `patch`. A parte _target_ pode ser omitida se for igual a `DEPENDS_TARGET`. [[makefile-uses]] === `USES` Parâmetros podem ser adicionados para definir diferentes recursos e dependências usados ​​pelo port. Eles são especificados adicionando esta linha ao [.filename]#Makefile#: [.programlisting] .... USES= feature[:arguments] .... Para a lista completa de valores, por favor veja o <>. [WARNING] ==== `USES` não pode ser atribuído após a inclusão de [.filename]#bsd.port.pre.mk#. ==== [[makefile-use-vars]] == 0 `USE_*` Diversas variáveis ​​existem para definir dependências comuns compartilhadas por muitos ports. O uso é opcional, mas ajuda a reduzir a verbosidade dos [.filename]##Makefile##s de port . Cada um deles é denominado como `USES_*`. Essas variáveis ​​podem ser usadas apenas no [.filename]#Makefile# do port e [.filename]#ports/Mk/bsd.*.mk#. Elas não são destinadas a opções configuráveis ​​pelo usuário - use `PORT_OPTIONS` para esse propósito. [NOTE] ==== É _sempre_ incorreto definir qualquer `USE_*` dentro de [.filename]#/etc/make.conf#. Por exemplo, definindo [.programlisting] .... USE_GCC=X.Y .... (onde XY é o número da versão) adicionaria uma dependência do gccXY para cada port, incluindo `lang/gccXY` em si! ==== [[makefile-use-vars-table]] .`USE_*` [cols="1,1", frame="none", options="header"] |=== | Variável | Significa |`USE_GCC` a| O port requer GCC (gcc ou {gcc-plus-plus}) para compilar. Alguns ports precisam de qualquer versão do GCC, algumas exigem versões modernas e recentes. Normalmente, é configurado para `qualquer` (neste caso, o GCC da base seria usado em versões do FreeBSD que ainda o possuem, ou o port `lang/gcc` seria instalado quando o compilador C/C++ padrão for o Clang); ou `yes` (significa usar sempre GCC estável e moderno do port `lang/gcc`). A versão exata também pode ser especificada, com um valor como `4.7`. A versão mínima exigida pode ser especificada como `4.6+`. O GCC do sistema base é usado quando satisfaz a versão solicitada, caso contrário, um compilador apropriado é compilado a partir do port, e `CC` e `CXX` são ajustados em conformidade. [NOTE] ==== `USE_GCC` irá registrar uma dependência de tempo de compilação e uma de tempo de execução. ==== |=== Variáveis ​​relacionadas ao gmake e [.filename]#configure# são descritos em <>, enquanto autoconf, automake e libtool são descritos em <>. Variáveis relacionadas ao Perl ​são descritas em <>. Variáveis ​​X11 são listadas em <>. <> lida com o GNOME e <> com variáveis ​​relacionadas ao KDE. <> documenta variáveis ​​Java, enquanto <> contém informações sobre Apache, PHP e módulos PEAR. Python é discutido em <>, e Ruby em <>. <> fornece variáveis ​​usadas para aplicações SDL e, finalmente, <> contém informações sobre o Xfce. [[makefile-version-dependency]] === Versão Mínima de uma Dependência Uma versão mínima de uma dependência pode ser especificada em qualquer `*_DEPENDS`, exceto `LIB_DEPENDS`, usando esta sintaxe: [.programlisting] .... p5-Spiffy>=0.26:devel/p5-Spiffy .... O primeiro campo contém um nome de pacote dependente, que deve corresponder à entrada no banco de dados de pacotes, um sinal de comparação e uma versão do pacote. A dependência é satisfeita se o p5-Spiffy-0.26 ou mais recente estiver instalado na máquina. [[makefile-note-on-dependencies]] === Notas sobre Dependências Como mencionado acima, o target padrão para chamar quando uma dependência é necessária é o `DEPENDS_TARGET`. Seu padrão é o `install`. Esta é uma variável de usuário; nunca é definido em um [.filename]#Makefile# de port. Se o port precisar de uma maneira especial de lidar com uma dependência, use a parte `:target` de `*_DEPENDS` em vez de redefinir `DEPENDS_TARGET`. Quando rodar `make clean`, as dependências de port também são limpas automaticamente. Se isso não for desejável, defina `NOCLEANDEPENDS` no ambiente. Isto pode ser particularmente desejável se o port tiver algo que demore muito tempo para recompilar em sua lista de dependências, como o KDE, o GNOME ou o Mozilla. Para depender de outro port incondicionalmente, use a variável `${NONEXISTENT}` no primeiro campo do `BUILD_DEPENDS` ou `RUN_DEPENDS`. Use isto somente quando o código fonte do outro port for necessário. Tempo de compilação pode ser economizado especificando o target também. Por exemplo [.programlisting] .... BUILD_DEPENDS= ${NONEXISTENT}:graphics/jpeg:extract .... sempre descerá para o port `jpeg` e extrai-lo. [[makefile-circular-dependencies]] === Dependências Circulares são Fatais [IMPORTANT] ==== Não insira nenhuma dependência circular na árvore de ports! ==== A tecnologia de compilação de ports não tolera dependências circulares. Se uma for inserida, alguém, em algum lugar do mundo, terá sua instalação do FreeBSD quebrada quase que imediatamente, e muitos outros rapidamente terão o mesmo problema. Estes erros podem ser realmente difíceis de serem detectados. Em caso de dúvida, antes de fazer qualquer alteração, certifique-se de executar: `cd /usr/ports; make index`. Esse processo pode ser muito lento em máquinas mais antigas, mas pode evitar dor de cabeça para um grande número de pessoas, incluindo você. [[makefile-automatic-dependencies]] === Problemas Causados ​​por Dependências Automáticas Dependências devem ser declaradas explicitamente ou usando o <>. Usar outros métodos, como a detecção automática, dificulta a indexação, o que causa problemas para o gerenciamento de ports e pacotes. [[makefile-automatic-dependencies-bad]] .Declaração Errada de uma Dependência Opcional [example] ==== [.programlisting] .... .include .if exists(${LOCALBASE}/bin/foo) LIB_DEPENDS= libbar.so:foo/bar .endif .... ==== O problema em tentar adicionar dependências automaticamente é que os arquivos e configurações fora de um port individual podem ser alterados a qualquer momento. Por exemplo: um índice é construído, depois um lote de ports é instalado. Mas um dos ports instala o arquivo testado. O índice então fica incorreto, porque um port instalado inesperadamente tem uma nova dependência. O índice ainda pode estar errado mesmo após a recriação, se outros ports também determinarem a necessidade de dependências com base na existência de outros arquivos. [[makefile-automatic-dependencies-good]] .Declaração Correta de uma Dependência Opcional [example] ==== [.programlisting] .... OPTIONS_DEFINE= BAR BAR_DESC= Calling cellphones via bar BAR_LIB_DEPENDS= libbar.so:foo/bar .... ==== Testar variáveis ​​de opções é o método correto. Ele não causará inconsistências no índice de um lote de ports, desde que as opções tenham sido definidas antes da construção do índice. Scripts simples podem ser usados ​​para automatizar a compilação, instalação e atualização desses ports e seus pacotes. [[makefile-masterdir]] == Ports Slaves e `MASTERDIR` Se o port precisar criar versões ligeiramente diferentes de pacotes fazendo com que uma variável (por exemplo, resolução ou tamanho de papel) assuma valores diferentes, crie um subdiretório por pacote para facilitar aos usuários a visualização do que fazer, mas tente compartilhar o máximo possível de arquivos entre os ports. Normalmente, usando variáveis ​​inteligentemente, apenas um [.filename]#Makefile# bem curto será necessário em todos, exceto em um dos diretórios. No [.filename]#Makefile# solitário, use `MASTERDIR` para especificar o diretório onde o restante dos arquivos estão. Além disso, use uma variável como parte de <> para que os pacotes tenham nomes diferentes. Isso será melhor demonstrado por um exemplo. Isso é parte de [.filename]#print/pkfonts300/Makefile#; [.programlisting] .... PORTNAME= pkfonts${RESOLUTION} PORTVERSION= 1.0 DISTFILES= pk${RESOLUTION}.tar.gz PLIST= ${PKGDIR}/pkg-plist.${RESOLUTION} .if !defined(RESOLUTION) RESOLUTION= 300 .else .if ${RESOLUTION} != 118 && ${RESOLUTION} != 240 && \ ${RESOLUTION} != 300 && ${RESOLUTION} != 360 && \ ${RESOLUTION} != 400 && ${RESOLUTION} != 600 .BEGIN: @${ECHO_MSG} "Error: invalid value for RESOLUTION: \"${RESOLUTION}\"" @${ECHO_MSG} "Possible values are: 118, 240, 300, 360, 400 and 600." @${FALSE} .endif .endif .... package:print/pkfonts300[] também tem todos os patches, arquivos de pacotes, etc. Rodando `make` nele, será assumido o valor padrão para a resolução (300) e o port será compilado normalmente. Quanto às outras resoluções, este é o [.filename]#print/pkfonts360/Makefile#_completo_: [.programlisting] .... RESOLUTION= 360 MASTERDIR= ${.CURDIR}/../pkfonts300 .include "${MASTERDIR}/Makefile" .... ([.filename]#print/pkfonts118/Makefile#, [.filename]#print/pkfonts600/Makefile#, e todos os outros são semelhantes). A definição de `MASTERDIR` diz ao [.filename]#bsd.port.mk# que o conjunto regular de subdiretórios como `FILESDIR` e `SCRIPTDIR` podem ser encontrados em [.filename]#pkfonts300#. A linha `RESOLUTION=360` irá substituir a linha `RESOLUTION=300` em [.filename]#pkfonts300/Makefile# e o port será compilado com a resolução definida para 360. [[makefile-manpages]] == Páginas de Manual Se o port instala a sua árvore de manuais em outro lugar diferente de `PREFIX`, use `MANDIRS` para especificar esses diretórios. Note que os arquivos correspondentes às páginas de manual devem ser colocados no [.filename]#pkg-plist# junto com o resto dos arquivos. O propósito do `MANDIRS` é ativar a compactação automática de páginas de manual, portanto, os nomes dos arquivos são sufixados com [.filename]#.gz#. [[makefile-info]] == Arquivos de Informação Se o pacote precisar instalar arquivos de informações GNU, liste-os na variável `INFO` (sem o sufixo `.info`), uma entrada por documento. Presume-se que esses arquivos estejam instalados em [.filename]#PREFIX/INFO_PATH#. Mude `INFO_PATH` se o pacote usa um local diferente. Contudo, isto não é recomendado. Essas entradas contêm apenas o caminho relativo para [.filename]#PREFIX/INFO_PATH#. Por exemplo, package:lang/gcc34[] instala arquivos de informações em [.filename]#PREFIX/INFO_PATH/gcc34# e `INFO` será algo assim: [.programlisting] .... INFO= gcc34/cpp gcc34/cppinternals gcc34/g77 ... .... O código apropriado de instalação/desinstalação será automaticamente adicionado ao arquivo [.filename]#pkg-plist# temporário antes do registro do pacote. [[makefile-options]] == Opções do Makefile Muitas aplicações podem ser compiladas com configurações opcionais ou diferentes. Exemplos podem ser a escolha de linguagem natural (humana), GUI versus linha de comando ou qual tipo de banco de dados será suportado. Os usuários podem precisar de uma configuração diferente do padrão, portanto o sistema de ports fornece ganchos em que o autor do port pode usar para controlar qual variante será compilada. Suportar essas opções corretamente fará com que os usuários fiquem felizes, e efetivamente forneça dois ou mais ports pelo preço de um. [[makefile-options-options]] === `OPTIONS` [[makefile-options-background]] ==== Background `OPTIONS_*` fornece ao usuário que está instalando o port uma caixa de diálogo mostrando as opções disponíveis e, em seguida, salva essas opções em [.filename]#${PORT_DBDIR}/${OPTIONS_NAME}/options#. Na próxima vez que o port for compilado, as opções serão reutilizadas. O padrão de `PORT_DBDIR` é [.filename]#/var/db/ports#. `OPTIONS_NAME` é a origem do port com um underline como o separador de espaço, por exemplo, package:dns/bind99[] será `dns_bind99`. Quando o usuário executa `make config` (ou executa `make build` pela primeira vez), o framework verifica [.filename]#${PORT_DBDIR}/${OPTIONS_NAME}/options#. Se esse arquivo não existir, os valores de `OPTIONS_*` são usados ​​e uma caixa de diálogo é exibida onde as opções podem ser ativadas ou desativadas. Então as [.filename]#options# são salvas e as variáveis ​​configuradas são utilizadas ao compilar o port. Se uma nova versão do port adicionar novas `OPTIONS`, a caixa de diálogo será apresentada ao usuário, já preenchido com os valores salvos das antigas `OPTIONS`. `make showconfig` mostra a configuração salva. Use `make rmconfig` para remover a configuração salva. [[makefile-options-syntax]] ==== Sintaxe `OPTIONS_DEFINE` contém uma lista de `OPTIONS` para serem utilizadas. Elas são independentes umas das outras e não são agrupadas: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT2 .... Uma vez definido, as `OPTIONS` são descritas (opcionalmente, mas fortemente recomendado): [.programlisting] .... OPT1_DESC= Describe OPT1 OPT2_DESC= Describe OPT2 OPT3_DESC= Describe OPT3 OPT4_DESC= Describe OPT4 OPT5_DESC= Describe OPT5 OPT6_DESC= Describe OPT6 .... [.filename]#ports/Mk/bsd.options.desc.mk# possui descrições para muitas `OPTIONS` comuns. Geralmente são úteis, mas podem ser substituas se a descrição for insuficiente para o port. [TIP] ==== Ao descrever as opções, visualize-as da perspectiva do usuário: "Qual funcionalidade ela muda?" e "Por que eu iria querer habilitar ela?" Não repita apenas o nome. Por exemplo, descrever a opção `NLS` como "incluir suporte NLS" não ajuda o usuário, que já pode ver o nome da opção, mas pode não saber o que isso significa. Descrevendo-a como "Suporte a idiomas nativos por meio de utilitários gettext" é muito mais útil. ==== [IMPORTANT] ==== Os nomes das opções são sempre em letras maiúsculas. Não podem estar misturadas ou apenas em minúsculo. ==== `OPTIONS` podem ser agrupadas como opções radio, onde apenas uma escolha de cada grupo é permitida: [.programlisting] .... OPTIONS_SINGLE= SG1 OPTIONS_SINGLE_SG1= OPT3 OPT4 .... [WARNING] ==== _Deve_ estar sempre selecionada uma de cada `OPTIONS_SINGLE` para as opções serem válidas. Uma opção de cada grupo _deve_ ser adicionada a `OPTIONS_DEFAULT`. ==== `OPTIONS` podem ser agrupadas como opções radio, onde nenhuma ou apenas uma escolha de cada grupo é permitida: [.programlisting] .... OPTIONS_RADIO= RG1 OPTIONS_RADIO_RG1= OPT7 OPT8 .... `OPTIONS` também pode ser agrupadas como listas de "múltipla-escolha", onde _pelo menos uma_ opção deve estar habilitada: [.programlisting] .... OPTIONS_MULTI= MG1 OPTIONS_MULTI_MG1= OPT5 OPT6 .... `OPTIONS` também pode ser agrupadas como listas de "múltipla-escolha", onde nenhuma ou qualquer opção pode ser ativada: [.programlisting] .... OPTIONS_GROUP= GG1 OPTIONS_GROUP_GG1= OPT9 OPT10 .... `OPTIONS` são desativadas por padrão, a menos que estejam listadas em `OPTIONS_DEFAULT`: [.programlisting] .... OPTIONS_DEFAULT= OPT1 OPT3 OPT6 .... Definições de `OPTIONS` devem aparecer antes da inclusão de [.filename]#bsd.port.options.mk#. Valores de `PORT_OPTIONS` só podem ser testados após a inclusão de [.filename]#bsd.port.options.mk#. Inclusão de [.filename]#bsd.port.pre.mk# pode ser usado também, e ainda é amplamente usado em ports escritos antes da introdução de [.filename]#bsd.port.options.mk#. Mas esteja ciente de que algumas variáveis não funcionarão como esperado após a inclusão de [.filename]#bsd.port.pre.mk#, tipicamente algumas flags `USE_*`. [[ports-options-simple-use]] .Uso Simples de `OPTIONS` [example] ==== [.programlisting] .... OPTIONS_DEFINE= FOO BAR OPTIONS_DEFAULT=FOO FOO_DESC= Option foo support BAR_DESC= Feature bar support # Will add --with-foo / --without-foo FOO_CONFIGURE_WITH= foo BAR_RUN_DEPENDS= bar:bar/bar .include .... ==== [[ports-options-check-unset]] .Verificar `OPTIONS` Desmacadas [example] ==== [.programlisting] .... .if ! ${PORT_OPTIONS:MEXAMPLES} CONFIGURE_ARGS+=--without-examples .endif .... O formato acima não é recomendado. O método preferido é usar um configure knob para realmente ativar e desativar o recurso coincidindo com a opção: [.programlisting] .... # Will add --with-examples / --without-examples EXAMPLES_CONFIGURE_WITH= examples .... ==== [[ports-options-practical-use]] .Uso Prático de `OPTIONS` [example] ==== [.programlisting] .... OPTIONS_DEFINE= EXAMPLES OPTIONS_DEFAULT= PGSQL LDAP SSL OPTIONS_SINGLE= BACKEND OPTIONS_SINGLE_BACKEND= MYSQL PGSQL BDB OPTIONS_MULTI= AUTH OPTIONS_MULTI_AUTH= LDAP PAM SSL EXAMPLES_DESC= Install extra examples MYSQL_DESC= Use MySQL as backend PGSQL_DESC= Use PostgreSQL as backend BDB_DESC= Use Berkeley DB as backend LDAP_DESC= Build with LDAP authentication support PAM_DESC= Build with PAM support SSL_DESC= Build with OpenSSL support # Will add USE_PGSQL=yes PGSQL_USE= pgsql=yes # Will add --enable-postgres / --disable-postgres PGSQL_CONFIGURE_ENABLE= postgres ICU_LIB_DEPENDS= libicuuc.so:devel/icu # Will add --with-examples / --without-examples EXAMPLES_CONFIGURE_WITH= examples # Check other OPTIONS .include .... ==== [[makefile-options-default]] ==== Opções Padrão Essas opções estão sempre ativadas por padrão. * `DOCS` -- build and install documentation. * `NLS` -- Native Language Support. * `EXAMPLES` -- build and install examples. * `IPV6` -- IPv6 protocol support. [NOTE] ==== Não há necessidade de adicioná-las em `OPTIONS_DEFAULT`. Para ativá-las e mostra-las na caixa de diálogo de seleção de opções, elas devem ser adicionadas em `OPTIONS_DEFINE`. ==== [[makefile-options-auto-activation]] === Feature de Ativação Automática Ao usar um script configure GNU, fique de olho em quais recursos opcionais são ativados por detecção automática. Desative explicitamente os recursos opcionais que não são necessários, adicionando `--without-xxx` ou `--disable-xxx` em `CONFIGURE_ARGS`. [[makefile-options-auto-activation-bad]] .Manipulação Incorreta de uma Opção [example] ==== [.programlisting] .... .if ${PORT_OPTIONS:MFOO} LIB_DEPENDS+= libfoo.so:devel/foo CONFIGURE_ARGS+= --enable-foo .endif .... ==== No exemplo acima, imagine que uma biblioteca libfoo está instalada no sistema. O usuário não quer que este aplicativo use libfoo, então ele desabilitou a opção na caixa de diálogo do `make config`. Mas o script configure do aplicativo detecta a biblioteca presente no sistema e inclui seu suporte no executável resultante. Agora, quando o usuário decide remover libfoo do sistema, o sistema de ports não protesta (nenhuma dependência de libfoo foi registrada), e então o aplicativo quebra. [[makefile-options-auto-activation-good]] .Manuseio Correto de uma Opção [example] ==== [.programlisting] .... FOO_LIB_DEPENDS= libfoo.so:devel/foo # Will add --enable-foo / --disable-foo FOO_CONFIGURE_ENABLE= foo .... ==== [NOTE] ==== Sob algumas circunstâncias, a sintaxe condicional abreviada pode causar problemas com construções complexas. Os erros são geralmente `Malformed conditional`, e uma sintaxe alternativa pode ser usada. [.programlisting] .... .if !empty(VARIABLE:MVALUE) .... como uma alternativa para [.programlisting] .... .if ${VARIABLE:MVALUE} .... ==== [[options-helpers]] === Assistentes de Opções Existem algumas macros para ajudar a simplificar valores condicionais que diferem com base nas opções definidas. Para facilitar o acesso, é fornecida uma lista abrangente: `PLIST_SUB`, `SUB_LIST`:: Para geração automática de `%%_OPT_%%` e `%%NO_OPT%%`, veja <>. + Para uso mais complexo, veja <>. `CONFIGURE_ARGS`:: Para `--enable-_x_` e `--disable-_x_`, veja <>. + Para `--with-_x_` e `--without-_x_`, veja <>. + Para todos os outros casos, veja <>. `CMAKE_ARGS`:: Para argumentos que são booleanos (`on`, `off`, `true`, `false`, `0`, `1`) veja <>. + Para todos os outros casos, veja <>. `MESON_ARGS`:: Para argumentos que precisam de `true` ou `false`, veja <>. + Para argumentos que precisam de `yes` ou `no`, use <>. + Para argumentos que precisam de `true` ou `false`, veja <>. + Para todos os outros casos, use <>. `QMAKE_ARGS`:: Veja <>. `USE_*`:: Veja <>. `*_DEPENDS`:: Veja <>. _*_ (Qualquer variável):: As variáveis ​​mais usadas possuem assistentes diretos, veja <>. + Para qualquer variável sem um assistente específico, veja <>. Dependências de opções:: Quando uma opção precisa de outra opção para funcionar, veja <>. Conflitos de opções:: Quando uma opção não funciona se outra também estiver ativada, consulte <>. Targets para Build:: Quando uma opção precisa de algum processamento extra, veja <>. [[options_sub]] ==== `OPTIONS_SUB` Se `OPTIONS_SUB` está definido com `yes` então cada uma das opções adicionadas a `OPTIONS_DEFINE` será adicionada em `PLIST_SUB` e `SUB_LIST`, por exemplo: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPTIONS_SUB= yes .... é equivalente a: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} PLIST_SUB+= OPT1="" NO_OPT1="@comment " SUB_LIST+= OPT1="" NO_OPT1="@comment " .else PLIST_SUB+= OPT1="@comment " NO_OPT1="" SUB_LIST+= OPT1="@comment " NO_OPT1="" .endif .... [NOTE] ==== O valor de `OPTIONS_SUB` é ignorado. Definindo-o com qualquer valor irá adicionar entradas `PLIST_SUB` e `SUB_LIST` para _todas_ as opções. ==== [[options-use]] ==== `OPT_USE` e `OPT_USE_OFF` Quando a opção _OPT_ é selecionada, para cada par `_key=value_` em `OPT_USE`, _value_ é anexado ao `USE_KEY` correspondente. E se _value_ tiver espaços, substitua-os por vírgulas e eles serão alterados de volta para espaços durante o processamento. `OPT_USE_OFF` funciona da mesma maneira, quando `OPT` _não for_ selecionada. Por exemplo: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_USES= xorg OPT1_USE= mysql=yes xorg=x11,xextproto,xext,xrandr OPT1_USE_OFF= openssl=yes .... é equivalente a: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} USE_MYSQL= yes USES+= xorg USE_XORG= x11 xextproto xext xrandr .else USE_OPENSSL= yes .endif .... [[options-configure-helpers]] ==== Assistentes `CONFIGURE_ARGS` [[options-configure_enable]] ===== `OPT_CONFIGURE_ENABLE` Quando a opção _OPT_ é selecionada, para cada _valor_ em `OPT_CONFIGURE_ENABLE`, `--enable-_valor_` será anexado a `CONFIGURE_ARGS`. Quando a opção OPT _não for_ selecionada, `--disable-_valor_` será anexado a `CONFIGURE_ARGS`. Um argumento opcional pode ser especificado com um símbolo `=`. Este argumento é apenas anexado na entrada de opção do script configure `--enable-_valor_`. Por exemplo: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT2 OPT1_CONFIGURE_ENABLE= test1 test2 OPT2_CONFIGURE_ENABLE= test2=exhaustive .... é equivalente a: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} CONFIGURE_ARGS+= --enable-test1 --enable-test2 .else CONFIGURE_ARGS+= --disable-test1 --disable-test2 .endif .if ${PORT_OPTIONS:MOPT2} CONFIGURE_ARGS+= --enable-test2=exhaustive .else CONFIGURE_ARGS+= --disable-test2 .endif .... [[options-configure_with]] ===== `OPT_CONFIGURE_WITH` Quando a opção _OPT_ é selecionada, para cada _valor_ em `OPT_CONFIGURE_WITH`, `--with-_valor_` será anexado a `CONFIGURE_ARGS`. Quando a opção OPT_não for_ selecionada, `--without-_valor_` será anexado a `CONFIGURE_ARGS`. Um argumento opcional pode ser especificado com um símbolo `=`. Este argumento é apenas anexado na entrada de opção do script configure `--with-_valor_`. Por exemplo: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT2 OPT1_CONFIGURE_WITH= test1 OPT2_CONFIGURE_WITH= test2=exhaustive .... é equivalente a: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT2 .include .if ${PORT_OPTIONS:MOPT1} CONFIGURE_ARGS+= --with-test1 .else CONFIGURE_ARGS+= --without-test1 .endif .if ${PORT_OPTIONS:MOPT2} CONFIGURE_ARGS+= --with-test2=exhaustive .else CONFIGURE_ARGS+= --without-test2 .endif .... [[options-configure_on]] ===== `OPT_CONFIGURE_ON` e `OPT_CONFIGURE_OFF` Quando a opção _OPT_ é selecionada, o valor de `OPT_CONFIGURE_ON`, se definido, é anexado a `CONFIGURE_ARGS`. `OPT_CONFIGURE_OFF` funciona da mesma maneira, quando `OPT` _não for_ selecionada. Por exemplo: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_CONFIGURE_ON= --add-test OPT1_CONFIGURE_OFF= --no-test .... é equivalente a: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} CONFIGURE_ARGS+= --add-test .else CONFIGURE_ARGS+= --no-test .endif .... [TIP] ==== Na maioria das vezes, os assistentes em <> e <> fornecem uma funcionalidade mais curta e abrangente. ==== [[options-cmake-helpers]] ==== Assistentes `CMAKE_ARGS` [[options-cmake_on]] ===== `OPT_CMAKE_ON` e `OPT_CMAKE_OFF` Quando a opção _OPT_ é selecionada, o valor de `OPT_CMAKE_ON`, se definido, é anexado a `CMAKE_ARGS`. `OPT_CMAKE_OFF` funciona da mesma maneira, mas quando `OPT` _não for_ selecionada. Por exemplo: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_CMAKE_ON= -DTEST:BOOL=true -DDEBUG:BOOL=true OPT1_CMAKE_OFF= -DOPTIMIZE:BOOL=true .... é equivalente a: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} CMAKE_ARGS+= -DTEST:BOOL=true -DDEBUG:BOOL=true .else CMAKE_ARGS+= -DOPTIMIZE:BOOL=true .endif .... [TIP] ==== Veja <> para um assistente mais curto quando o valor for booleano. ==== [[options-cmake_bool]] ===== `OPT_CMAKE_BOOL` e `OPT_CMAKE_BOOL_OFF` Quando a opção _OPT_ é selecionada, para cada _valor_ em `OPT_CMAKE_BOOL`, `-Dvalor:BOOL=true` será anexado a `CMAKE_ARGS`. Quando a opção OPT_não for_ selecionada, `-Dvalor:BOOL=false` será anexado a `CONFIGURE_ARGS`. O `OPT_CMAKE_BOOL_OFF` é o oposto, `-Dvalor:BOOL=false` será anexado a `CMAKE_ARGS` quando a opção é selecionada, e a entrada `-Dvalor:BOOL=true` quando a opção _não for_ selecionada. Por exemplo: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_CMAKE_BOOL= TEST DEBUG OPT1_CMAKE_BOOL_OFF= OPTIMIZE .... é equivalente a: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} CMAKE_ARGS+= -DTEST:BOOL=true -DDEBUG:BOOL=true \ -DOPTIMIZE:BOOL=false .else CMAKE_ARGS+= -DTEST:BOOL=false -DDEBUG:BOOL=false \ -DOPTIMIZE:BOOL=true .endif .... [[options-meson-helpers]] ==== Assistentes `MESON_ARGS` [[options-meson_on]] ===== `OPT_MESON_ON` e `OPT_MESON_OFF` Quando a opção _OPT_ é selecionada, o valor de `OPT_MESON_ON`, se definido, é anexado a `MESON_ARGS`. `OPT_MESON_OFF` funciona da mesma maneira, quando `OPT` _não for_ selecionada. Por exemplo: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_MESON_ON= -Dopt=1 OPT1_MESON_OFF= -Dopt=2 .... é equivalente a: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} MESON_ARGS+= -Dopt=1 .else MESON_ARGS+= -Dopt=2 .endif .... [[options-meson_true]] ===== `OPT_MESON_TRUE` e `OPT_MESON_FALSE` Quando a opção _OPT_ é selecionada, para cada _valor_ em `OPT_MESON_TRUE`, `-Dvalor=true` será anexado a `MESON_ARGS`. Quando a opção OPT_não for_ selecionada, `-Dvalor=false` será anexado a `MESON_ARGS`. O `OPT_MESON_FALSE` é o oposto, a entrada `-Dvalor=false` será anexado a `MESON_ARGS` quando a opção for selecionada e a entrada `-Dvalor=true` quando a opção _não for_ selecionada. Por exemplo: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_MESON_TRUE= test debug OPT1_MESON_FALSE= optimize .... é equivalente a: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} MESON_ARGS+= -Dtest=true -Ddebug=true \ -Doptimize=false .else MESON_ARGS+= -Dtest=false -Ddebug=false \ -Doptimize=true .endif .... [[options-meson_yes]] ===== `OPT_MESON_YES` e `OPT_MESON_NO` Quando a opção _OPT_ é selecionada, para cada _entrada_ dentro da variável `OPT_MESON_YES` a entrada `-D__=yes` é anexada a variável `MESON_ARGS`. Quando a opção OPT _não é_ selecionada, então a entrada `-D=no` é anexada a variável `MESON_ARGS`. O `OPT_MESON_NO` é o oposto, a entrada `-D=no` é anexada a variável `MESON_ARGS` quando a opção é selecionada e a entrada `-D=yes` quando a opção _não é_ selecionada. Por exemplo: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_MESON_YES= test debug OPT1_MESON_NO= optimize .... é equivalente a: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} MESON_ARGS+= -Dtest=yes -Ddebug=yes \ -Doptimize=no .else MESON_ARGS+= -Dtest=no -Ddebug=no \ -Doptimize=yes .endif .... [[options-meson_enabled]] ===== `OPT_MESON_ENABLED` e `OPT_MESON_DISABLED` Quando a opção _OPT_ é selecionada, para cada _valor_ em `OPT_MESON_ENABLED`, `-Dvalor=enabled` será anexado a `MESON_ARGS`. Quando a opção OPT_não for_ selecionada, `-Dvalor=disabled` será anexado a `MESON_ARGS`. O `OPT_MESON_DISABLED` é o oposto, a entrada `-Dvalor=disabled` será anexado a `MESON_ARGS` quando a opção for selecionada e a entrada `-Dvalor=enabled` quando a opção _não for_ selecionada. Por exemplo: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_MESON_ENABLED= test OPT1_MESON_DISABLED= debug .... é equivalente a: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} MESON_ARGS+= -Dtest=enabled -Ddebug=disabled .else MESON_ARGS+= -Dtest=disabled -Ddebug=enabled .endif .... [[options-qmake_on]] ==== `OPT_QMAKE_ON` e `OPT_QMAKE_OFF` Quando a opção _OPT_ é selecionada, o valor de `OPT_QMAKE_ON`, se definido, é anexado a `QMAKE_ARGS`. `OPT_QMAKE_OFF` funciona da mesma maneira, quando `OPT` _não for_ selecionada. Por exemplo: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_QMAKE_ON= -DTEST:BOOL=true OPT1_QMAKE_OFF= -DPRODUCTION:BOOL=true .... é equivalente a: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} QMAKE_ARGS+= -DTEST:BOOL=true .else QMAKE_ARGS+= -DPRODUCTION:BOOL=true .endif .... [[options-implies]] ==== `OPT_IMPLIES` Fornece uma maneira de adicionar dependências entre as opções. Quando _OPT_ for selecionada, todas as opções listadas nesta variável também serão selecionadas. Usando o <> descrito anteriormente para demonstrar: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT2 OPT1_IMPLIES= OPT2 OPT1_CONFIGURE_ENABLE= opt1 OPT2_CONFIGURE_ENABLE= opt2 .... É equivalente a: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT2 .include .if ${PORT_OPTIONS:MOPT1} CONFIGURE_ARGS+= --enable-opt1 .else CONFIGURE_ARGS+= --disable-opt1 .endif .if ${PORT_OPTIONS:MOPT2} || ${PORT_OPTIONS:MOPT1} CONFIGURE_ARGS+= --enable-opt2 .else CONFIGURE_ARGS+= --disable-opt2 .endif .... [[options-implies-ex1]] .Uso Simples de `OPT_IMPLIES` [example] ==== Este port tem uma opção `X11` e uma opção `GNOME` que precisa da opção `X11` selecionada para poder compilar. [.programlisting] .... OPTIONS_DEFINE= X11 GNOME OPTIONS_DEFAULT= X11 X11_USES= xorg X11_USE= xorg=xi,xextproto GNOME_USE= gnome=gtk30 GNOME_IMPLIES= X11 .... ==== [[options-prevents]] ==== `OPT_PREVENTS` e `OPT_PREVENTS_MSG` Fornece uma maneira de adicionar conflitos entre as opções. Quando _OPT_ for selecionada, todas as opções listadas em `OPT_PREVENTS` devem estar desmarcadas. Se `OPT_PREVENTS_MSG` estiver definido e um conflito for acionado, seu conteúdo será exibido explicando o por que do conflito. Por exemplo: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT2 OPT1_PREVENTS= OPT2 OPT1_PREVENTS_MSG= OPT1 and OPT2 enable conflicting options .... É aproximadamente equivalente a: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT2 .include .if ${PORT_OPTIONS:MOPT2} && ${PORT_OPTIONS:MOPT1} BROKEN= Option OPT1 conflicts with OPT2 (select only one) .endif .... A única diferença é que o primeiro irá apresentar um erro depois de executar `make config`, sugerindo alterar as opções selecionadas. [[options-prevents-ex1]] .Uso Simples de `OPT_PREVENTS` [example] ==== Este port tem as opções `X509` e `SCTP`. Ambas as opções adicionam patches, mas os patches entram em conflito uns com os outros, então eles não podem ser selecionados ao mesmo tempo. [.programlisting] .... OPTIONS_DEFINE= X509 SCTP SCTP_PATCHFILES= ${PORTNAME}-6.8p1-sctp-2573.patch.gz:-p1 SCTP_CONFIGURE_WITH= sctp X509_PATCH_SITES= http://www.roumenpetrov.info/openssh/x509/:x509 X509_PATCHFILES= ${PORTNAME}-7.0p1+x509-8.5.diff.gz:-p1:x509 X509_PREVENTS= SCTP X509_PREVENTS_MSG= X509 and SCTP patches conflict .... ==== [[options-vars]] ==== `OPT_VARS` e `OPT_VARS_OFF` Fornece uma maneira genérica de definir e acrescentar valores em variáveis. [WARNING] ==== Antes de usar `OPT_VARS` e `OPT_VARS_OFF`, veja se já não existe um assistente mais específico disponível em <>. ==== Quando a opção _OPT_ está selecionada e `OPT_VARS` definido, os pares `_chave_=_valor_` e `_chave_+=_valor_` são avaliados a partir da variável `OPT_VARS`. Um `=` sobrescreve o valor existente da `CHAVE`, um `+=` acrescenta o valor a chave. `OPT_VARS_OFF` funciona da mesma maneira, quando a opção `OPT` _não for_ selecionada. [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT2 OPT3 OPT1_VARS= also_build+=bin1 OPT2_VARS= also_build+=bin2 OPT3_VARS= bin3_build=yes OPT3_VARS_OFF= bin3_build=no MAKE_ARGS= ALSO_BUILD="${ALSO_BUILD}" BIN3_BUILD="${BIN3_BUILD}" .... é equivalente a: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT2 MAKE_ARGS= ALSO_BUILD="${ALSO_BUILD}" BIN3_BUILD="${BIN3_BUILD}" .include .if ${PORT_OPTIONS:MOPT1} ALSO_BUILD+= bin1 .endif .if ${PORT_OPTIONS:MOPT2} ALSO_BUILD+= bin2 .endif .if ${PORT_OPTIONS:MOPT2} BIN3_BUILD= yes .else BIN3_BUILD= no .endif .... [IMPORTANT] ==== Valores contendo espaços em branco devem ser colocados entre aspas: [.programlisting] .... OPT_VARS= foo="bar baz" .... Isso se deve ao jeito que a variável de expansão man:make[1] lida com espaço em branco. Quando a opção `OPT_VARS=foo=bar baz` é expandida, a variável acaba contendo duas strings, `foo=bar` e `baz`. Mas quem está submetendo o código provavelmente pretendia que houvesse apenas uma string, `foo=bar baz`. Inserir o valor entre aspas impede que o espaço em branco seja usado como um delimitador. Além disso, _não_ adicione espaços extras após o símbolo `_var_=` e antes do valor, pois assim também seria dividido o valor em duas strings. _Isso não irá funcionar_: [.programlisting] .... OPT_VARS= foo= bar .... ==== [[options-dependencies]] ==== Dependências, `OPT_DEPTYPE_` e `OPT_DEPTYPE_OFF` Para qualquer um desses tipos de dependência: * `PKG_DEPENDS` * `EXTRACT_DEPENDS` * `PATCH_DEPENDS` * `FETCH_DEPENDS` * `BUILD_DEPENDS` * `LIB_DEPENDS` * `RUN_DEPENDS` Quando opção _OPT_ é selecionada, o valor de `OPT_DEPTYPE`, se definido, é anexado a `_DEPTYPE_`. `OPT_DEPTYPE_OFF` funciona da mesma forma, quando `OPT` _não for_ selecionada. Por exemplo: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_LIB_DEPENDS= liba.so:devel/a OPT1_LIB_DEPENDS_OFF= libb.so:devel/b .... é equivalente a: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} LIB_DEPENDS+= liba.so:devel/a .else LIB_DEPENDS+= libb.so:devel/b .endif .... [[options-variables]] ==== Substituição de Variáveis ​​Genéricas, `OPT_VARIABLE_` e `OPT_VARIABLE_OFF` Para qualquer uma destas variáveis: * `ALL_TARGET` * `BINARY_ALIAS` * `BROKEN` * `CATEGORIES` * `CFLAGS` * `CONFIGURE_ENV` * `CONFLICTS` * `CONFLICTS_BUILD` * `CONFLICTS_INSTALL` * `CPPFLAGS` * `CXXFLAGS` * `DESKTOP_ENTRIES` * `DISTFILES` * `EXTRACT_ONLY` * `EXTRA_PATCHES` * `GH_ACCOUNT` * `GH_PROJECT` * `GH_SUBDIR` * `GH_TAGNAME` * `GH_TUPLE` * `GL_ACCOUNT` * `GL_COMMIT` * `GL_PROJECT` * `GL_SITE` * `GL_SUBDIR` * `GL_TUPLE` * `IGNORE` * `INFO` * `INSTALL_TARGET` * `LDFLAGS` * `LIBS` * `MAKE_ARGS` * `MAKE_ENV` * `MASTER_SITES` * `PATCHFILES` * `PATCH_SITES` * `PLIST_DIRS` * `PLIST_FILES` * `PLIST_SUB` * `PORTDOCS` * `PORTEXAMPLES` * `SUB_FILES` * `SUB_LIST` * `TEST_TARGET` * `USES` Quando a opção _OPT_ é selecionada, o valor da variável `OPT_ABOVEVARIABLE`, se definido, é anexado a `_ABOVEVARIABLE_`. `OPT_ABOVEVARIABLE_OFF` funciona da mesma maneira, quando `OPT` _não for_ selecionada. Por exemplo: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_USES= gmake OPT1_CFLAGS_OFF= -DTEST .... é equivalente a: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} USES+= gmake .else CFLAGS+= -DTEST .endif .... [NOTE] ==== Algumas variáveis ​​não estão nesta lista, em particular `PKGNAMEPREFIX` e `PKGNAMESUFFIX`. Isso é intencional. Um port _não deve_ mudar seu nome quando alguma de suas opções forem alteradas. ==== [WARNING] ==== Algumas dessas variáveis, pelo menos `ALL_TARGET`, `DISTFILES` e `INSTALL_TARGET`, tem seus valores padrão definidos _depois_ das opções serem processadas. Com estas linhas no [.filename]#Makefile#: [.programlisting] .... ALL_TARGET= all DOCS_ALL_TARGET= doc .... Se a opção `DOCS` estiver ativada, `ALL_TARGET` terá o valor `all doc`; se a opção estiver desativada, ela terá o valor `all`. Com apenas a linha do assistente de opções no [.filename]#Makefile#: [.programlisting] .... DOCS_ALL_TARGET= doc .... Se a opção `DOCS` estiver ativada, `ALL_TARGET` terá o valor `doc`; se a opção estiver desativada, ela terá o valor `all`. ==== [[options-targets]] ==== Targets Adicionais de Compilação, `_target_-_OPT_-on` e `_target_-_OPT_-off` Estes targets de [.filename]#Makefile# podem aceitar targets extras de compilação: * `pre-fetch` * `do-fetch` * `post-fetch` * `pre-extract` * `do-extract` * `post-extract` * `pre-patch` * `do-patch` * `post-patch` * `pre-configure` * `do-configure` * `post-configure` * `pre-build` * `do-build` * `post-build` * `pre-install` * `do-install` * `post-install` * `post-stage` * `pre-package` * `do-package` * `post-package` Quando a opção _OPT_ é selecionada, o target `_TARGET_-_OPT_-on`, se definido, é executado após `_TARGET_`. `_TARGET_-_OPT_-off` funciona da mesma maneira, quando `OPT` _não for_ selecionada. Por exemplo: [.programlisting] .... OPTIONS_DEFINE= OPT1 post-patch-OPT1-on: @${REINPLACE_CMD} -e '/opt1/s|/usr/bin/|${EXAMPLESDIR}/|' ${WRKSRC}/Makefile post-patch-OPT1-off: @${REINPLACE_CMD} -e '/opt1/s|/usr/bin/|${PREFIX}/bin/|' ${WRKSRC}/Makefile .... é equivalente a: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include post-patch: .if ${PORT_OPTIONS:MOPT1} @${REINPLACE_CMD} -e '/opt1/s|/usr/bin/|${EXAMPLESDIR}/|' ${WRKSRC}/Makefile .else @${REINPLACE_CMD} -e '/opt1/s|/usr/bin/|${PREFIX}/bin/|' ${WRKSRC}/Makefile .endif .... [[makefile-wrkdir]] == Especificando o Diretório de Trabalho Cada port é extraído em um diretório de trabalho, que deve ter permissão de escrita. O sistema de ports tem por padrão os `DISTFILES` descompactado em um diretório chamado `${DISTNAME}`. Em outras palavras, se o [.filename]#Makefile# tem: [.programlisting] .... PORTNAME= foo DISTVERSION= 1.0 .... então os arquivos de distribuição do port contêm um diretório de nível superior, [.filename]#foo-1.0#, e o resto dos arquivos estão localizados nesse diretório. Diversas variáveis ​​podem ser substituídas se não for esse o caso. [[makefile-wrksrc]] === `WRKSRC` A variável lista o nome do diretório que é criado quando os distfiles do aplicativo são extraídos. Se o exemplo anterior for extraído em um diretório chamado [.filename]#foo# (e não [.filename]#foo-1.0#) escreva: [.programlisting] .... WRKSRC= ${WRKDIR}/foo .... ou possivelmente [.programlisting] .... WRKSRC= ${WRKDIR}/${PORTNAME} .... [[makefile-wrksrc_subdir]] === `WRKSRC_SUBDIR` Se o código fonte necessário para o port estiver em um subdiretório do arquivo de distribuição extraído, defina `WRKSRC_SUBDIR` para esse diretório. [.programlisting] .... WRKSRC_SUBDIR= src .... [[makefile-no_wrksubdir]] === `NO_WRKSUBDIR` Se o port não extrair para nenhum subdiretório, então configure `NO_WRKSUBDIR` para indicar isso. [.programlisting] .... NO_WRKSUBDIR= yes .... [NOTE] ==== Porque `WRKDIR` é o único diretório que deve ter permissão de escrita durante a compilação e é usado para armazenar muitos arquivos que registram o status da compilação, a extração do port será forçada para um subdiretório. ==== [[conflicts]] == Manipulando Conflitos Existem três variáveis ​​diferentes para registrar um conflito entre pacotes e ports: `CONFLICTS`, `CONFLICTS_INSTALL` e `CONFLICTS_BUILD`. [NOTE] ==== As variáveis ​​de conflito definem automaticamente a variável `IGNORE`, que é mais amplamente documentada em <>. ==== Ao remover um dos vários ports conflitados, é aconselhável reter `CONFLICTS` nos outros ports por alguns meses para atender usuários que apenas fazem atualizações de vez em quando. [[conclicts-conflicts_install]] `CONFLICTS_INSTALL`:: Se o pacote não puder coexistir com outros pacotes (devido a conflitos de arquivos, incompatibilidades de tempo de execução, etc.). A checagem `CONFLICTS_INSTALL` é feita após o estágio de compilação e antes do estágio de instalação. [[conclicts-conflicts_build]] `CONFLICTS_BUILD`:: Se o port não puder ser compilado quando outros ports específicos já estiverem instalados. Conflitos de compilação não serão registrados no pacote final. [[conclicts-conflicts]] `CONFLICTS`:: Se o port não puder ser compilado quando um certo port estiver instalado e o pacote final não puder coexistir com o outro pacote. A checagem `CONFLICTS` é feita antes do estágio de compilação e antes do estágio de instalação. O conteúdo mais comum de uma dessas variáveis ​​é o pacote base de outro port. O pacote base é o nome do pacote sem a versão, ele pode ser obtido executando `make -V PKGBASE`. [[conflicts-ex1]] .Uso básico de `CONFLICTS_*` [example] ==== package:dns/bind99[] não pode ser instalado se package:dns/bind910[] está presente porque eles instalam os mesmos arquivos. Primeiro, reúna o pacote base para usar: [source,shell] .... % make -C dns/bind99 -V PKGBASE bind99 % make -C dns/bind910 -V PKGBASE bind910 .... Então adicione ao [.filename]#Makefile# do package:dns/bind99[]: [.programlisting] .... CONFLICTS_INSTALL= bind910 .... E adicione ao [.filename]#Makefile# do package:dns/bind910[]: [.programlisting] .... CONFLICTS_INSTALL= bind99 .... ==== Às vezes, apenas uma versão de outro port é incompatível, neste caso, use o nome completo do pacote, com a versão, e use shell globs, como `*` e `?` para garantir que todas as versões possíveis sejam correspondidas. [[conflicts-ex2]] .Usando `CONFLICTS_*` Com Globs. [example] ==== Nas versões 2.0 até 2.4.1_2, package:deskutils/gnotime[] instalava uma versão integrada de package:databases/qof[]. Para refletir este passado, o [.filename]#Makefile# do package:database/qof[] contém: [.programlisting] .... CONFLICTS_INSTALL= gnotime-2.[0-3]* \ gnotime-2.4.0* gnotime-2.4.1 \ gnotime-2.4.1_[12] .... As primeira entrada corresponde as versões `2.0` até `2.3`, a segunda corresponde todas as revisões de `2.4.0`, a terceira corresponde a versão exata `2.4.1`, e a última corresponde a primeira e segunda revisão da versão `2.4.1`. package:deskutils/gnotime[] não possui nenhuma linha de conflitos porque sua versão atual não conflita com mais nada. ==== [[install]] == Instalando Arquivos [IMPORTANT] ==== O estágio `install` é muito importante para o usuário final porque ele adiciona arquivos ao sistema. Todos os comandos adicionais de estágios `*-install` dos [.filename]#Makefile#'s de port devem ser mostrados na tela. _Não_ silencie esses comandos com `@` ou `.SILENT`. ==== [[install-macros]] === Macros `INSTALL_*` Use as macros fornecidas em [.filename]#bsd.port.mk# para garantir a propriedade correta dos arquivos nos targets `*-install` do port. Defina a propriedade diretamente em [.filename]#pkg-plist# com as entradas correspondentes, como `@(_owner_,_group_,)`, `@owner _owner_`, e `@group _group_`. Esses operadores funcionam até serem substituídos, ou até o final do [.filename]#pkg-plist#, lembre-se de redefini-los depois que eles não forem mais necessários. O valor de propriedade padrão é `root:wheel`. Veja <> para maiores informações. * `INSTALL_PROGRAM` é um comando para instalar executáveis ​​binários. * `INSTALL_SCRIPT` é um comando para instalar scripts executáveis. * `INSTALL_LIB` é um comando para instalar bibliotecas compartilhadas (mas não bibliotecas estáticas). * `INSTALL_KLD` é um comando para instalar módulos carregáveis ​​do kernel. Algumas arquiteturas não gostam de ter os módulos otimizados (stripped), então use este comando em vez de `INSTALL_PROGRAM`. * `INSTALL_DATA` é um comando para instalar dados compartilháveis, incluindo bibliotecas estáticas. * `INSTALL_MAN` é um comando para instalar manpages e outras documentações (ele não realiza nenhuma compactação). Estas variáveis ​​parametrizam o comando man:install[1] com as flags apropriadas para cada situação. [IMPORTANT] ==== Não use `INSTALL_LIB` para instalar bibliotecas estáticas, porque otimiza-las (strip) torna-as sem utilidade. Use `INSTALL_DATA` neste caso. ==== [[install-strip]] === Otimizando (Stripping) Binários e Bibliotecas Compartilhadas Os binários instalados devem ser otimizados (stripped). Não otimize (strip) os binários manualmente, a menos que seja absolutamente necessário. A macro `INSTALL_PROGRAM` instala e otimiza (strip) o binário ao mesmo tempo. A macro `INSTALL_LIB` faz o mesmo com as bibliotecas compartilhadas. Quando um arquivo deve ser otimizado (stripped), mas as macros `INSTALL_PROGRAM` e `INSTALL_LIB` não são desejadas, `${STRIP_CMD}` otimiza (strips) o programa ou a biblioteca compartilhada. Isso geralmente é feito no target `post-install`. Por exemplo: [.programlisting] .... post-install: ${STRIP_CMD} ${STAGEDIR}${PREFIX}/bin/xdl .... Quando vários arquivos precisam ser otimizados (stripped): [.programlisting] .... post-install: .for l in geometry media body track world ${STRIP_CMD} ${STAGEDIR}${PREFIX}/lib/lib${PORTNAME}-${l}.so.0 .endfor .... Use man:file[1] em um arquivo para determinar se ele foi otimizado (stripped). Binários são relatados por man:file[1] como `stripped` ou `not stripped`. Além disso,man:strip[1] irá detectar programas que já foram otimizados (stripped) e retornar o comando sem erros. [IMPORTANT] ==== Quando `WITH_DEBUG` estiver definido, os arquivos elf _não devem_ ser otimizados (stripped). As variáveis ​​(`STRIP_CMD`, `INSTALL_PROGRAM`, `INSTALL_LIB`, ...) e <> fornecidas pelo framework lidam com isso automaticamente. Alguns softwares, adicionam `-s` em seus `LDFLAGS`, neste caso, ou remova o `-s` se `WITH_DEBUG` estiver definido, ou remova o incondicionalmente e use `STRIP_CMD` em `post-install`. ==== [[install-copytree]] === Instalando uma Árvore Inteira de Arquivos Às vezes, um grande número de arquivos devem ser instalados preservando sua organização hierárquica. Por exemplo, copiando de uma árvore de diretórios inteira do `WRKSRC` para um diretório de destino sob `PREFIX`. Observe que `PREFIX`, `EXEMPLESDIR`, `DATADIR` e outras variáveis ​​de caminho sempre devem ser precedidas por `STAGEDIR` para respeitar o staging (ver <>). Existem duas macros para essa situação. A vantagem de usar essas macros em vez de `cp` é que elas garantem a propriedade e permissão adequada dos arquivos nos arquivos de destino. A primeira macro, `COPYTREE_BIN`, irá definir todos os arquivos instalados como sendo executáveis, sendo assim, adequado para instalações em [.filename]#PREFIX/bin#. A segunda macro,`COPYTREE_SHARE`, não define permissões de execução nos arquivos e, portanto, é adequado para instalar arquivos sob o destino [.filename]#PREFIX/share#. [.programlisting] .... post-install: ${MKDIR} ${STAGEDIR}${EXAMPLESDIR} (cd ${WRKSRC}/examples && ${COPYTREE_SHARE} .${STAGEDIR}${EXAMPLESDIR}) .... Este exemplo irá instalar o conteúdo do diretório [.filename]#exemples# do distfile do fornecedor para o local de exemplos apropriado do port. [.programlisting] .... post-install: ${MKDIR} ${STAGEDIR}${DATADIR}/summer (cd ${WRKSRC}/temperatures && ${COPYTREE_SHARE} "June July August" ${STAGEDIR}${DATADIR}/summer) .... E este exemplo irá instalar os dados dos meses de verão no subdiretório [.filename]#summer# de um [.filename]#DATADIR#. Argumentos `find` adicionais podem ser passados através do terceiro argumento para `COPYTREE_*`. Por exemplo, para instalar todos os arquivos do primeiro exemplo, exceto Makefiles, é possível usar esses comandos. [.programlisting] .... post-install: ${MKDIR} ${STAGEDIR}${EXAMPLESDIR} (cd ${WRKSRC}/examples && \ ${COPYTREE_SHARE} .${STAGEDIR}${EXAMPLESDIR} "! -name Makefile") .... Essas macros não adicionam os arquivos instalados em [.filename]#pkg-plist#. Eles devem ser adicionados manualmente. Para documentação opcional (`PORTDOCS`, veja <>) e exemplos (`PORTEXAMPLES`), os prefixos `%%PORTDOCS%%` ou `%%PORTEXAMPLES%%` devem ser prefixados no [.filename]#pkg-plist#. [[install-documentation]] === Instalar Documentação Adicional Se o software tiver alguma documentação diferente do manual padrão e páginas de informações úteis para o usuário, instale-os em `DOCSDIR`. Isso pode ser feito como no item anterior, no target `post-install`. Crie um novo diretório para o port. O nome do diretório é `DOCSDIR`. Isso geralmente é igual a `PORTNAME`. No entanto, se o usuário desejar que versões diferentes do port sejam instaladas ao mesmo tempo, `PKGNAME` pode ser usado. Já que apenas os arquivos listados no [.filename]#pkg-plist# são instalados, é seguro sempre instalar documentações no `STAGEDIR` (veja <>). Por isso, blocos `.if` são necessários apenas quando os arquivos forem grandes o suficiente para causarem sobrecarga significativa de I/O. [.programlisting] .... post-install: ${MKDIR} ${STAGEDIR}${DOCSDIR} ${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${STAGEDIR}${DOCSDIR} .... Por outro lado, se houver uma opção DOCS no port, instale a documentação em um taget `post-install-DOCS-on`. Esses targets são descritos em <>. Aqui estão algumas variáveis úteis e como elas são expandidas por padrão quando usadas no [.filename]#Makefile#: * `DATADIR` é expandido para [.filename]#PREFIX/shared/PORTNAME#. * `DATADIR_REL` é expandido para [.filename]#share/PORTNAME#. * `DOCSDIR` é expandido para [.filename]#PREFIX/shared/doc/PORTNAME#. * `DOCSDIR_REL` é expandido para [.filename]#share/doc/PORTNAME#. * `EXEMPLESDIR` é expandido para [.filename]#PREFIX/shared/examples/PORTNAME#. * `EXAMPLESDIR_REL` é expandido para [.filename]#share/examples/PORTNAME#. [NOTE] ==== A opção `DOCS` controla apenas a documentação adicional instalada em `DOCSDIR`. Não se aplica a páginas de manual e páginas de informações padrão. Arquivos instalados em `EXEMPLESDIR` são controlados pela opção `EXEMPLES`. ==== Essas variáveis são exportadas para `PLIST_SUB`. Quando possível, seus valores aparecerão como nomes de caminho relativos ao [.filename]#PREFIX#. Isso é, por padrão [.filename]#share/doc/PORTNAME# será substituído por `%%DOCSDIR%%` na lista de empacotamento e assim por diante. (Saiba mais sobre substituições [.filename]#pkg-plist#<>.) Todos os arquivos e diretórios de documentação instalados condicionalmente são incluídos no [.filename]#pkg-plist# com o prefixo `%%PORTDOCS%%`, por exemplo: [.programlisting] .... %%PORTDOCS%%%%DOCSDIR%%/AUTHORS %%PORTDOCS%%%%DOCSDIR%%/CONTACT .... Como uma alternativa para listar os arquivos de documentação em [.filename]#pkg-plist#, um port pode definir a variável `PORTDOCS` com uma lista de nomes de arquivo e padrões shell glob para adicionar à lista de empacotamento final. Os nomes serão relativos a `DOCSDIR`. Portanto, um port que utiliza `PORTDOCS` e usa um local não padrão para sua documentação, deve definir `DOCSDIR` adequadamente. Se um diretório estiver listado em `PORTDOCS` ou ser correspondido por um padrão glob dessa variável, toda a sub árvore de arquivos e diretórios contidos serão registrados na lista final de empacotamento. Se a opção `DOCS` estiver desmarcada, os arquivos e diretórios listados em `PORTDOCS` não serão instalados ou adicionados à lista de empacotamento do port. A instalação da documentação em `PORTDOCS` como mostrado acima fica a cargo do port. Um exemplo típico de utilização `PORTDOCS`: [.programlisting] .... PORTDOCS= README.* ChangeLog docs/* .... [NOTE] ==== O equivalente de `PORTDOCS` para arquivos instalados em `DATADIR` e `EXEMPLESDIR` são `PORTDATA` e `PORTEXAMPLES`, respectivamente. O conteúdo de [.filename]#pkg-message# é exibido na instalação. Veja <> para mais detalhes. [.filename]#pkg-message# não precisa ser adicionado ao [.filename]#pkg-plist#. ==== [[install-subdirs]] === Subdiretórios Sob `PREFIX` Tente deixar o port colocar os arquivos nos subdiretórios corretos de `PREFIX`. Alguns ports juntam tudo e colocam os arquivos em um subdiretório com o nome do port, o que é incorreto. Além disso, muitos ports colocam todos arquivos, exceto binários, arquivos header e páginas de manual, em um subdiretório de [.filename]#lib#, o que não funciona bem com o paradigma BSD. Muitos dos arquivos devem ser movidos para um desses diretórios: [.filename]#etc#(setup/arquivos de configuração), [.filename]#libexec# (executáveis ​​iniciados internamente), [.filename]#sbin# (executáveis ​​para super-usuários/gerentes), [.filename]#info# (documentação para o navegador de informações) ou [.filename]#share# (arquivos independentes de arquitetura). Veja man:hier[7] para detalhes; as regras que regem [.filename]#/usr# praticamente se aplicam a [.filename]#/usr/local# também. A exceção são os ports que lidam com "notícias" USENET. Eles podem usar [.filename]#PREFIX/news# como um destino para seus arquivos. [[binary-alias]] == Use `BINARY_ALIAS` para Renomear Comandos Em Vez de Aplicar Patch na Compilação Quando `BINARY_ALIAS` é definido, ele criará links simbólicos dos comandos fornecidos, em um diretório que será prefixado para o `PATH`. Use-o para substituir comandos codificados na fase de compilação sem ter aplicar nenhum patch nos arquivos de compilação. [[binary-alias-ex1]] .Usando `BINARY_ALIAS` para Deixar `gsed` Disponível como `sed` [example] ==== Alguns ports esperam que o `sed` se comporte como o GNU sed e utilizam recursos que o man:sed[1] não possui. GNU sed está disponível em package:textproc/gsed[] no FreeBSD. Use `BINARY_ALIAS` para substituir `sed` com `gsed` durante a compilação: [.programlisting] .... BUILD_DEPENDS= gsed:textproc/gsed ... BINARY_ALIAS= sed=gsed .... ==== [[binary-alias-ex2]] .Usando `BINARY_ALIAS` Para Fornecer Aliases para Comandos `python3` Codificado [example] ==== Um port que possui uma referência codificada para `python3` em seus scripts de compilação precisará ter ele disponível no `PATH` em tempo de compilação. Use `BINARY_ALIAS` para criar um alias que aponte para o binário certo do Python 3: [.programlisting] .... USES= python:3.4+,build ... BINARY_ALIAS= python3=${PYTHON_CMD} .... Veja <> para mais informações sobre `USES=python`. ==== [NOTE] ==== Aliases binários são criados após as dependências fornecidas via `BUILD_DEPENDS` e `LIB_DEPENDS` serem processadas e antes do target `configure`. Isso leva a várias limitações. Por exemplo, os programas instalados via `TEST_DEPENDS` não podem ser usados para criar um alias binário, pois as dependências de teste especificadas desta forma são processadas após a criação dos aliases binários. ==== diff --git a/documentation/content/ru/books/developers-handbook/secure/chapter.adoc b/documentation/content/ru/books/developers-handbook/secure/chapter.adoc index 0c78e275d2..0d2a138544 100644 --- a/documentation/content/ru/books/developers-handbook/secure/chapter.adoc +++ b/documentation/content/ru/books/developers-handbook/secure/chapter.adoc @@ -1,168 +1,170 @@ --- title: Глава 3. Безопасное программирование authors: - author: Murray Stokely --- [[secure]] = Безопасное программирование :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :source-highlighter: rouge :experimental: :skip-front-matter: :toc-title: Содержание :table-caption: Таблица :figure-caption: Рисунок :example-caption: Пример :xrefstyle: basic :relfileprefix: ../ :outfilesuffix: [[secure-synopsis]] == Обзор Эта глава описывает некоторые из проблем обеспечения безопасности, которые десятилетиями преследовали программистов UNIX(R), а также несколько новых доступных инструментов, помогающих программистам избежать написания небезопасного кода. [[secure-philosophy]] == Методология обеспечения безопасности Написание безопасных приложений требует весьма критического и пессимистического взгляда на жизнь. Приложения должны работать по принципу "наименьших привилегий", при котором никакой процесс не должен работать с привилегиями, превышающими минимально необходимый для выполнения своих функций минимум. Ранее проверенный код должен использоваться там, где только это возможно для избежания общих ошибок, которые могли быть уже исправлены другими. Одной из неприятностей в среде UNIX(R) является легкость в предположении безопасности этого окружения. Приложения никогда не должны верить пользовательскому вводу (во всех его формах), ресурсам системы, межпроцессному взаимодействию или времени выполнения событий. Процессы UNIX(R) выполняются не синхронно, так что логические операции редко бывают атомарными. [[secure-bufferov]] == Переполнения буфера Переполнения буфера появились вместе с появление архитектуры Фон-Неймана <> Самые современные вычислительные системы используют стек для передачи аргументов процедурам и сохранения локальных переменных. Стек является буфером типа LIFO (последним вошел первым вышел) в верхней части области памяти процесса. Когда программа вызывает функцию, создается новая "граница стека". Эта граница состоит из аргументов, переданных в функцию, а также динамического количества пространства локальных переменных. "Указатель стека" является регистром, хранящим текущее положение вершины стека. Так как это значение постоянно меняется вместе с помещением новых значений на вершину стека, многие реализации также предусматривают "указатель границы", который расположен около начала стека, так что локальные переменные можно легко адресовать относительно этого значения. <> Хотя атаки с переполнением стека являются самыми распространенными, стек можно также перезаписать при помощи атаки, основанной на выделении памяти (malloc/free) из "кучи". Как и во многих других языках программирования, в C не выполняется автоматической проверки границ в массивах или указателях. Кроме того, стандартная библиотека C полна очень опасных функций. +//// [.informaltable] [cols="", frame="none"] |=== |=== +//// == Пример переполнения буфера В следующем примере кода имеется ошибка переполнения буфера, предназначенная для перезаписи адреса возврата и обхода инструкции, следующей непосредственно за вызовом функции. (По мотивам <> [.programlisting] .... #include stdio.h void manipulate(char *buffer) { char newbuffer[80]; strcpy(newbuffer,buffer); } int main() { char ch,buffer[4096]; int i=0; while ((buffer[i++] = getchar()) != '\n') {}; i=1; manipulate(buffer); i=2; printf("The value of i is : %d\n",i); return 0; } .... Давайте посмотрим, как будет выглядеть образ процесса, если в нашу маленькую программу мы введем 160 пробелов. [XXX figure here!] Очевидно, что для выполнения реальных инструкций (таких, как exec(/bin/sh)), может быть придуман более вредоносный ввод. === Как избежать переполнений буфера Самым прямолинейным решением проблемы переполнения стека является использование только памяти фиксированного размера и функций копирования строк. Функции `strncpy` и `strncat` являются частью стандартной библиотеки C. Эти функции будут копировать не более указанного количества байт из исходной строки в целевую. Однако у этих функций есть несколько проблем. Ни одна из них не гарантирует наличие символа NUL, если размер входного буфера больше, чем целевого. Параметр длины также по-разному используется в strncpy и strncat, так что для программистов легко запутаться в правильном использовании. Есть также и значительная потеря производительности по сравнению с `strcpy` при копировании короткой строки в большой буфер, потому что `strncpy` заполняет символами NUL пространство до указанной длины. Для избежания этих проблем в OpenBSD была сделана другая реализация копирования памяти. Функции `strlcpy` и `strlcat` гарантируют, что они они всегда терминируют целевую строку нулевым символом, если им будет передан аргумент ненулевой длины. Более подробная информация об этом находится здесь <> ==== Вкомпилированная проверка границ во время выполнения К сожалению, все еще широко используется очень большой объём кода, который слепо копирует память без использования только что рассмотренных функций с проверкой границ. Однако есть другое решение. Существует несколько расширений к компилятору и библиотек для выполнения контроля границ во время выполнения (C/C++). Одним из таких добавлений является StackGuard, который реализован как маленький патч к генератору кода gcc. Согласно http://immunix.org/stackguard.html[web сайту StackGuard]: "StackGuard распознает и защищает стек от атак, не позволяя изменять адрес возврата в стеке. При вызове функции StackGuard помещает вслед за адресом возврата сигнальное слово. Если после возврата из функции оно оказывается измененным, то была попытка выполнить атаку на стек, и программа отвечает на это генерацией сообщения о злоумышленнике в системном журнале, а затем прекращает работу." "StackGuard реализован в виде маленького патча к генератору кода gcc, а именно процедур function_prolog() и function_epilog(). function_prolog() усовершенствована для создания пометок в стеке при начале работы функции, а function_epilog() проверяет целостность пометки при возврате из функции. Таким образом, любые попытки изменения адреса возврата определяются до возврата из функции." Перекомпиляция вашего приложения со StackGuard является эффективным способом остановить большинство атак переполнений буфера, но все же полностью это проблемы не решает. ==== Проверка границ во время выполнения с использованием библиотек. Механизмы на основе компилятора полностью бесполезны для программного обеспечения, поставляемого в двоичном виде, которое вы не можете перекомпилировать. В этих ситуациях имеется некоторое количество библиотек, в которых реализованы небезопасные функции библиотеки C (`strcpy`, `fscanf`, `getwd`, и так далее..), обеспечивающие невозможность записи после указателя стека. * libsafe * libverify * libparanoia К сожалению, эти защиты имеют некоторое количество недостатков. Эти библиотеки могут защитить только против малого количества проблем, и не могут исправить реальные проблемы. Эти защиты могут не сработать, если приложение скомпилировано с параметром -fomit-frame-pointer. К тому же переменные окружения LD_PRELOAD и LD_LIBRARY_PATH могут быть переопределены/сняты пользователем. [[secure-setuid]] == Проблемы с установленным битом UID Имеется по крайней мере 6 различных идентификаторов (ID), связанных с любым взятым процессом. Поэтому вы должны быть очень осторожны с тем, какие права имеет ваш процесс в каждый момент времени. В частности, все seteuid-приложения должны понижать свои привилегии, как только в них отпадает необходимость. Реальный ID пользователя может быть изменен только процессом администратора. Программа login устанавливает его, когда пользователь входит в систему, и он редко меняется. Эффективный ID пользователя устанавливается функциями `exec()`, если у программы установлен бит seteuidt. Приложение может выполнить вызов `seteuid()` в любой момент для установки эффективного ID пользователя в значение реального ID пользователя или сохраняемого set-user-ID. Когда эффективный ID пользователя устанавливается функциями `exec()`, его предыдущее значение сохраняется в сохраняемом set-user-ID. [[secure-chroot]] == Ограничение среды работы вашей программы Традиционно используемым методом ограничения процесса является использование системного вызова `chroot()`. Этот системный вызов меняет корневой каталог, относительно которого определяются все остальные пути в самом процессе и всех порожденных ими процессах. Для того, чтобы этот вызов был выполнен успешно, процесс должен иметь право на выполнение (поиск) каталога, о котором идет речь. Новая среда реально не вступит в силу, пока вы не выполните вызов `chdir()` в вашей новой среде. Следует также отметить, что процесс может с легкостью выйти из chroot-среды, если он имеет привилегии администратора. Это может быть достигнуто созданием файлов устройств для чтения памяти ядра, подключением отладчика к процессу вне узницы и многими другими способами. Поведение системного вызова `chroot()` можно некоторым образом контролировать `sysctl`-переменной kern.chroot_allow_open_directories. Когда эта переменная установлена в 0, `chroot()` не сработает с ошибкой EPERM, если есть какие-либо открытые каталоги. Если она установлена в значение по умолчанию, равное 1, то `chroot()` не сработает с ошибкой EPERM, если есть какие-либо открытые каталоги и процесс уже подвергнут вызову `chroot()`. Для всех других значений проверка открытости каталогов будет полностью опущена. === Функциональность джейлов (jail) во FreeBSD Концепция джейлов (Jail) расширяет возможности `chroot()`, ограничивая власть администратора созданием настоящих `виртуальных серверов'. Как только тюремная камера создана, все сетевые коммуникации должны осуществляться через выделенный адрес IP, а сила "привилегий пользователя root" в этой тюрьме довольно ограничена. При работе внутри тюрьмы, любые проверки силы администратора в ядре при помощи вызова `suser()` будут оканчиваться неудачно. Однако некоторые вызовы к `suser()` были изменены на новый интерфейс `suser_xxx()`. Эта функция отвечает за распознание и разрешение доступа к власти администратора для процессов, не находящихся в неволе. Процесс администратора внутри среды джейла имеет право: * Манипулировать привилегиями с помощью `setuid`, `seteuid`, `setgid`, `setegid`, `setgroups`, `setreuid`, `setregid` и `setlogin` * Устанавливать ограничения на использование ресурсов при помощи `setrlimit` * Модифицировать некоторые sysctl-переменные (kern.hostname) * `chroot()` * Устанавливать следующие флаги на vnode: `chflags`, `fchflags` * Устанавливать такие атрибуты vnode, как права доступа к файлу, изменять его владельца, группу, размер, время доступа и модификации. * Осуществлять привязку к привилегированному порту в области портов Интернет (порты с номерами 1024) `Jail` является очень полезным инструментом для запуска приложений в защищенном окружении, но есть и некоторые недостатки. На текущий момент к формату `suser_xxx` не преобразованы механизмы IPC, так что такие приложения, как MySQL, не могут работать в джейле. Права администратора могут имеет малую силу внутри джейла, но нет способа определить, что значит "малую". === POSIX(R).1e возможности процессов POSIX(R) выпустила рабочий документ, который добавляет аудит событий, списки управления доступом, тонко настраиваемые привилегии, метки информации и жесткое управление доступом. Этот документ находится в работе и находится в центре внимания проекта http://www.trustedbsd.org/[TrustedBSD]. Некоторая начальная функциональность уже была добавлена во FreeBSD-CURRENT (cap_set_proc(3)). [[secure-trust]] == Доверие Приложение никогда не должно полагать, что среда пользователя безопасна. Сюда включается (но этим не ограничено): ввод пользователя, сигналы, переменные среды, ресурсы, IPC, отображаемая в файл память (mmap), рабочий каталог файловой системы, дескрипторы файлов, число открытых файлов и прочее. Никогда не думайте, что сможете предусмотреть все формы неправильного ввода, который может дать пользователь. Вместо этого ваше приложение должно осуществлять позитивную фильтрацию, пропуская только конечное множество возможных вариантов ввода, которые вы считаете безопасными. Неполная проверка данных была причиной многих нарушений защиты, особенно CGI-скриптов на веб-сайтах. Для имен файлов вам нужно уделять особое внимание путям ("../", "/"), символическим ссылкам и экранирующим символам оболочки. В Perl имеется такая очень полезная вещь, как "безупречный" (taint) режим, который можно использовать для запрещения скриптам использовать данные, порожденные вне программы, не безопасным способом. Этот режим проверяет аргументы командной строки, переменные окружения, информацию локализации, результаты некоторых системных вызовов (`readdir()`, `readlink()`, `getpwxxx()` и весь файловый ввод. [[secure-race-conditions]] == Неожиданное поведение Неожиданное поведение - это аномальное поведение, вызванное непредусмотренной зависимостью от относительной последовательности событий. Другими словами, программист неправильно предположил, что некоторое событие всегда случается перед другим. Некоторые из широко распространенных причин возникновения таких проблем являются сигналы, проверки доступа и открытия файлов. Сигналы по своей природе являются асинхронными событиями, так что по отношению к ним нужно проявлять особое внимание. Проверка доступа функцией `access(2)` с последующим вызовом `open(2)` полностью не атомарно. Пользователи могут переместить файлы в промежутке между двумя вызовами. Вместо этого привилегированное приложение должно выполнить `seteuid()`, а затем сразу вызвать `open()`. В тех же строках приложение должно всегда устанавливать явно маску прав доступа (umask) перед вызовом функции `open()` во избежание беспорядочных вызовов `chmod()`. diff --git a/documentation/content/zh-tw/books/porters-handbook/makefiles/chapter.adoc b/documentation/content/zh-tw/books/porters-handbook/makefiles/chapter.adoc index e8f473d59a..d710f9affd 100644 --- a/documentation/content/zh-tw/books/porters-handbook/makefiles/chapter.adoc +++ b/documentation/content/zh-tw/books/porters-handbook/makefiles/chapter.adoc @@ -1,4838 +1,4838 @@ --- title: Chapter 5. Configuring the Makefile prev: books/porters-handbook/slow-porting next: books/porters-handbook/special --- [[makefiles]] = Configuring the Makefile :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :source-highlighter: rouge :experimental: :skip-front-matter: :toc-title: 目录 :part-signifier: 部分 :chapter-signifier: 第 :appendix-caption: 附录 :table-caption: 表 :figure-caption: 图 :example-caption: 例 :xrefstyle: basic :relfileprefix: ../ :outfilesuffix: :g-plus-plus: g++ :sectnumoffset: 5 include::shared/mirrors.adoc[] include::shared/authors.adoc[] include::shared/releases.adoc[] include::shared/zh-tw/mailing-lists.adoc[] include::shared/zh-tw/urls.adoc[] toc::[] Configuring the [.filename]#Makefile# is pretty simple, and again we suggest looking at existing examples before starting. Also, there is a <> in this handbook, so take a look and please follow the ordering of variables and sections in that template to make the port easier for others to read. Consider these problems in sequence during the design of the new [.filename]#Makefile#: [[makefile-source]] == The Original Source Does it live in `DISTDIR` as a standard ``gzip``ped tarball named something like [.filename]#foozolix-1.2.tar.gz#? If so, go on to the next step. If not, the distribution file format might require overriding one or more of `DISTVERSION`, `DISTNAME`, `EXTRACT_CMD`, `EXTRACT_BEFORE_ARGS`, `EXTRACT_AFTER_ARGS`, `EXTRACT_SUFX`, or `DISTFILES`. In the worst case, create a custom `do-extract` target to override the default. This is rarely, if ever, necessary. [[makefile-naming]] == Naming The first part of the port's [.filename]#Makefile# names the port, describes its version number, and lists it in the correct category. [[makefile-portname]] === `PORTNAME` Set `PORTNAME` to the base name of the software. It is used as the base for the FreeBSD package, and for <>. [IMPORTANT] ==== The package name must be unique across the entire ports tree. Make sure that the `PORTNAME` is not already in use by an existing port, and that no other port already has the same `PKGBASE`. If the name has already been used, add either <>. ==== [[makefile-versions]] === Versions, `DISTVERSION` _or_ `PORTVERSION` Set `DISTVERSION` to the version number of the software. `PORTVERSION` is the version used for the FreeBSD package. It will be automatically derived from `DISTVERSION` to be compatible with FreeBSD's package versioning scheme. If the version contains _letters_, it might be needed to set `PORTVERSION` and not `DISTVERSION`. [IMPORTANT] ==== Only one of `PORTVERSION` and `DISTVERSION` can be set at a time. ==== From time to time, some software will use a version scheme that is not compatible with how `DISTVERSION` translates in `PORTVERSION`. [TIP] ==== When updating a port, it is possible to use man:pkg-version[8]'s `-t` argument to check if the new version is greater or lesser than before. See <>. ==== [[makefile-versions-ex-pkg-version]] .Using man:pkg-version[8] to Compare Versions. [example] ==== `pkg version -t` takes two versions as arguments, it will respond with `<`, `=` or `>` if the first version is less, equal, or more than the second version, respectively. [source,shell] .... % pkg version -t 1.2 1.3 < <.> % pkg version -t 1.2 1.2 = <.> % pkg version -t 1.2 1.2.0 = <.> % pkg version -t 1.2 1.2.p1 > <.> % pkg version -t 1.2.a1 1.2.b1 < <.> % pkg version -t 1.2 1.2p1 < <.> .... <.> `1.2` is before `1.3`. <.> `1.2` and `1.2` are equal as they have the same version. <.> `1.2` and `1.2.0` are equal as nothing equals zero. <.> `1.2` is after `1.2.p1` as `.p1`, think "pre-release 1". <.> `1.2.a1` is before `1.2.b1`, think "alpha" and "beta", and `a` is before `b`. <.> `1.2` is before `1.2p1` as `2p1`, think "2, patch level 1" which is a version after any `2.X` but before `3`. [NOTE] **** In here, the `a`, `b`, and `p` are used as if meaning "alpha", "beta" or "pre-release" and "patch level", but they are only letters and are sorted alphabetically, so any letter can be used, and they will be sorted appropriately. **** ==== .Examples of `DISTVERSION` and the Derived `PORTVERSION` [cols="10%,90%", frame="none", options="header"] |=== | DISTVERSION | PORTVERSION |0.7.1d |0.7.1.d |10Alpha3 |10.a3 |3Beta7-pre2 |3.b7.p2 |8:f_17 |8f.17 |=== [[makefile-versions-ex1]] .Using `DISTVERSION` [example] ==== When the version only contains numbers separated by dots, dashes or underscores, use `DISTVERSION`. [.programlisting] .... PORTNAME= nekoto DISTVERSION= 1.2-4 .... It will generate a `PORTVERSION` of `1.2.4`. ==== [[makefile-versions-ex2]] .Using `DISTVERSION` When the Version Starts with a Letter or a Prefix [example] ==== When the version starts or ends with a letter, or a prefix or a suffix that is not part of the version, use `DISTVERSIONPREFIX`, `DISTVERSION`, and `DISTVERSIONSUFFIX`. If the version is `v1.2-4`: [.programlisting] .... PORTNAME= nekoto DISTVERSIONPREFIX= v DISTVERSION= 1_2_4 .... Some of the time, projects using GitHub will use their name in their versions. For example, the version could be `nekoto-1.2-4`: [.programlisting] .... PORTNAME= nekoto DISTVERSIONPREFIX= nekoto- DISTVERSION= 1.2_4 .... Those projects also sometimes use some string at the end of the version, for example, `1.2-4_RELEASE`: [.programlisting] .... PORTNAME= nekoto DISTVERSION= 1.2-4 DISTVERSIONSUFFIX= _RELEASE .... Or they do both, for example, `nekoto-1.2-4_RELEASE`: [.programlisting] .... PORTNAME= nekoto DISTVERSIONPREFIX= nekoto- DISTVERSION= 1.2-4 DISTVERSIONSUFFIX= _RELEASE .... `DISTVERSIONPREFIX` and `DISTVERSIONSUFFIX` will not be used while constructing `PORTVERSION`, but only used in `DISTNAME`. All will generate a `PORTVERSION` of `1.2.4`. ==== [[makefile-versions-ex3]] .Using `DISTVERSION` When the Version Contains Letters Meaning "alpha", "beta", or "pre-release" [example] ==== When the version contains numbers separated by dots, dashes or underscores, and letters are used to mean "alpha", "beta" or "pre-release", which is, before the version without the letters, use `DISTVERSION`. [.programlisting] .... PORTNAME= nekoto DISTVERSION= 1.2-pre4 .... [.programlisting] .... PORTNAME= nekoto DISTVERSION= 1.2p4 .... Both will generate a `PORTVERSION` of `1.2.p4` which is before than 1.2. man:pkg-version[8] can be used to check that fact: [source,shell] .... % pkg version -t 1.2.p4 1.2 < .... ==== [[makefile-versions-ex4]] .Not Using `DISTVERSION` When the Version Contains Letters Meaning "Patch Level" [example] ==== When the version contains letters that are not meant as "alpha", "beta", or "pre", but more in a "patch level", and meaning after the version without the letters, use `PORTVERSION`. [.programlisting] .... PORTNAME= nekoto PORTVERSION= 1.2p4 .... In this case, using `DISTVERSION` is not possible because it would generate a version of `1.2.p4` which would be before `1.2` and not after. man:pkg-version[8] will verify this: [source,shell] .... % pkg version -t 1.2 1.2.p4 > <.> % pkg version -t 1.2 1.2p4 < <.> .... <.> `1.2` is after `1.2.p4`, which is _wrong_ in this case. <.> `1.2` is before `1.2p4`, which is what was needed. ==== For some more advanced examples of setting `PORTVERSION`, when the software's versioning is really not compatible with FreeBSD's, or `DISTNAME` when the distribution file does not contain the version itself, see <>. [[makefile-naming-revepoch]] === `PORTREVISION` and `PORTEPOCH` [[makefile-portrevision]] ==== `PORTREVISION` `PORTREVISION` is a monotonically increasing value which is reset to 0 with every increase of `DISTVERSION`, typically every time there is a new official vendor release. If `PORTREVISION` is non-zero, the value is appended to the package name. Changes to `PORTREVISION` are used by automated tools like man:pkg-version[8] to determine that a new package is available. `PORTREVISION` must be increased each time a change is made to the port that changes the generated package in any way. That includes changes that only affect a package built with non-default <>. Examples of when `PORTREVISION` must be bumped: * Addition of patches to correct security vulnerabilities, bugs, or to add new functionality to the port. * Changes to the port [.filename]#Makefile# to enable or disable compile-time options in the package. * Changes in the packing list or the install-time behavior of the package. For example, a change to a script which generates initial data for the package, like man:ssh[1] host keys. * Version bump of a port's shared library dependency (in this case, someone trying to install the old package after installing a newer version of the dependency will fail since it will look for the old libfoo.x instead of libfoo.(x+1)). * Silent changes to the port distfile which have significant functional differences. For example, changes to the distfile requiring a correction to [.filename]#distinfo# with no corresponding change to `DISTVERSION`, where a `diff -ru` of the old and new versions shows non-trivial changes to the code. Examples of changes which do not require a `PORTREVISION` bump: * Style changes to the port skeleton with no functional change to what appears in the resulting package. * Changes to `MASTER_SITES` or other functional changes to the port which do not affect the resulting package. * Trivial patches to the distfile such as correction of typos, which are not important enough that users of the package have to go to the trouble of upgrading. * Build fixes which cause a package to become compilable where it was previously failing. As long as the changes do not introduce any functional change on any other platforms on which the port did previously build. Since `PORTREVISION` reflects the content of the package, if the package was not previously buildable then there is no need to increase `PORTREVISION` to mark a change. A rule of thumb is to decide whether a change committed to a port is something which _some_ people would benefit from having. Either because of an enhancement, fix, or by virtue that the new package will actually work at all. Then weigh that against that fact that it will cause everyone who regularly updates their ports tree to be compelled to update. If yes, `PORTREVISION` must be bumped. [NOTE] ==== People using binary packages will _never_ see the update if `PORTREVISION` is not bumped. Without increasing `PORTREVISION`, the package builders have no way to detect the change and thus, will not rebuild the package. ==== [[makefile-portepoch]] ==== `PORTEPOCH` From time to time a software vendor or FreeBSD porter will do something silly and release a version of their software which is actually numerically less than the previous version. An example of this is a port which goes from foo-20000801 to foo-1.0 (the former will be incorrectly treated as a newer version since 20000801 is a numerically greater value than 1). [TIP] ==== The results of version number comparisons are not always obvious. `pkg version` (see man:pkg-version[8]) can be used to test the comparison of two version number strings. For example: [source,shell] .... % pkg version -t 0.031 0.29 > .... The `>` output indicates that version 0.031 is considered greater than version 0.29, which may not have been obvious to the porter. ==== In situations such as this, `PORTEPOCH` must be increased. If `PORTEPOCH` is nonzero it is appended to the package name as described in section 0 above. `PORTEPOCH` must never be decreased or reset to zero, because that would cause comparison to a package from an earlier epoch to fail. For example, the package would not be detected as out of date. The new version number, `1.0,1` in the above example, is still numerically less than the previous version, 20000801, but the `,1` suffix is treated specially by automated tools and found to be greater than the implied suffix `,0` on the earlier package. Dropping or resetting `PORTEPOCH` incorrectly leads to no end of grief. If the discussion above was not clear enough, please consult the {freebsd-ports}. It is expected that `PORTEPOCH` will not be used for the majority of ports, and that sensible use of `DISTVERSION`, or that use `PORTVERSION` carefully, can often preempt it becoming necessary if a future release of the software changes the version structure. However, care is needed by FreeBSD porters when a vendor release is made without an official version number - such as a code "snapshot" release. The temptation is to label the release with the release date, which will cause problems as in the example above when a new "official" release is made. For example, if a snapshot release is made on the date `20000917`, and the previous version of the software was version `1.2`, do not use `20000917` for `DISTVERSION`. The correct way is a `DISTVERSION` of `1.2.20000917`, or similar, so that the succeeding release, say `1.3`, is still a numerically greater value. [[makefile-portrevision-example]] ==== Example of `PORTREVISION` and `PORTEPOCH` Usage The `gtkmumble` port, version `0.10`, is committed to the ports collection: [.programlisting] .... PORTNAME= gtkmumble DISTVERSION= 0.10 .... `PKGNAME` becomes `gtkmumble-0.10`. A security hole is discovered which requires a local FreeBSD patch. `PORTREVISION` is bumped accordingly. [.programlisting] .... PORTNAME= gtkmumble DISTVERSION= 0.10 PORTREVISION= 1 .... `PKGNAME` becomes `gtkmumble-0.10_1` A new version is released by the vendor, numbered `0.2` (it turns out the author actually intended `0.10` to actually mean `0.1.0`, not "what comes after 0.9" - oops, too late now). Since the new minor version `2` is numerically less than the previous version `10`, `PORTEPOCH` must be bumped to manually force the new package to be detected as "newer". Since it is a new vendor release of the code, `PORTREVISION` is reset to 0 (or removed from the [.filename]#Makefile#). [.programlisting] .... PORTNAME= gtkmumble DISTVERSION= 0.2 PORTEPOCH= 1 .... `PKGNAME` becomes `gtkmumble-0.2,1` The next release is 0.3. Since `PORTEPOCH` never decreases, the version variables are now: [.programlisting] .... PORTNAME= gtkmumble DISTVERSION= 0.3 PORTEPOCH= 1 .... `PKGNAME` becomes `gtkmumble-0.3,1` [NOTE] ==== If `PORTEPOCH` were reset to `0` with this upgrade, someone who had installed the `gtkmumble-0.10_1` package would not detect the `gtkmumble-0.3` package as newer, since `3` is still numerically less than `10`. Remember, this is the whole point of `PORTEPOCH` in the first place. ==== [[porting-pkgnameprefix-suffix]] === `PKGNAMEPREFIX` and `PKGNAMESUFFIX` Two optional variables, `PKGNAMEPREFIX` and `PKGNAMESUFFIX`, are combined with `PORTNAME` and `PORTVERSION` to form `PKGNAME` as `${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}`. Make sure this conforms to our <>. In particular, the use of a hyphen (`-`) in `PORTVERSION` is _not_ allowed. Also, if the package name has the _language-_ or the _-compiled.specifics_ part (see below), use `PKGNAMEPREFIX` and `PKGNAMESUFFIX`, respectively. Do not make them part of `PORTNAME`. [[porting-pkgname]] === Package Naming Conventions These are the conventions to follow when naming packages. This is to make the package directory easy to scan, as there are already thousands of packages and users are going to turn away if they hurt their eyes! Package names take the form of [.filename]#language_region-name-compiled.specifics-version.numbers#. The package name is defined as `${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}`. Make sure to set the variables to conform to that format. [[porting-pkgname-language]] [.filename]#language_region-#:: FreeBSD strives to support the native language of its users. The _language-_ part is a two letter abbreviation of the natural language defined by ISO-639 when the port is specific to a certain language. Examples are `ja` for Japanese, `ru` for Russian, `vi` for Vietnamese, `zh` for Chinese, `ko` for Korean and `de` for German. + If the port is specific to a certain region within the language area, add the two letter country code as well. Examples are `en_US` for US English and `fr_CH` for Swiss French. + The _language-_ part is set in `PKGNAMEPREFIX`. [[porting-pkgname-name]] [.filename]#name#:: Make sure that the port's name and version are clearly separated and placed into `PORTNAME` and `DISTVERSION`. The only reason for `PORTNAME` to contain a version part is if the upstream distribution is really named that way, as in the package:textproc/libxml2[] or package:japanese/kinput2-freewnn[] ports. Otherwise, `PORTNAME` cannot contain any version-specific information. It is quite normal for several ports to have the same `PORTNAME`, as the package:www/apache*[] ports do; in that case, different versions (and different index entries) are distinguished by `PKGNAMEPREFIX` and `PKGNAMESUFFIX` values. + There is a tradition of naming `Perl 5` modules by prepending `p5-` and converting the double-colon separator to a hyphen. For example, the `Data::Dumper` module becomes `p5-Data-Dumper`. [[porting-pkgname-compiled-specifics]] [.filename]#-compiled.specifics#:: If the port can be built with different <> (usually part of the directory name in a family of ports), the _-compiled.specifics_ part states the compiled-in defaults. The hyphen is optional. Examples are paper size and font units. + The _-compiled.specifics_ part is set in `PKGNAMESUFFIX`. [[porting-pkgname-version-numbers]] [.filename]#-version.numbers#:: The version string follows a dash (`-`) and is a period-separated list of integers and single lowercase alphabetics. In particular, it is not permissible to have another dash inside the version string. The only exception is the string `pl` (meaning "patchlevel"), which can be used _only_ when there are no major and minor version numbers in the software. If the software version has strings like "alpha", "beta", "rc", or "pre", take the first letter and put it immediately after a period. If the version string continues after those names, the numbers follow the single alphabet without an extra period between them (for example, `1.0b2`). + The idea is to make it easier to sort ports by looking at the version string. In particular, make sure version number components are always delimited by a period, and if the date is part of the string, use the `d__yyyy.mm.dd__` format, not `_dd.mm.yyyy_` or the non-Y2K compliant `_yy.mm.dd_` format. It is important to prefix the version with a letter, here `d` (for date), in case a release with an actual version number is made, which would be numerically less than `_yyyy_`. [IMPORTANT] ==== Package name must be unique among all of the ports tree, check that there is not already a port with the same `PORTNAME` and if there is add one of <>. ==== Here are some (real) examples on how to convert the name as called by the software authors to a suitable package name, for each line, only one of `DISTVERSION` or `PORTVERSION` is set in, depending on which would be used in the port's [.filename]#Makefile#: .Package Naming Examples [cols="1,1,1,1,1,1,1", frame="none", options="header"] |=== | Distribution Name | PKGNAMEPREFIX | PORTNAME | PKGNAMESUFFIX | DISTVERSION | PORTVERSION | Reason or comment |mule-2.2.2 |(empty) |mule |(empty) |2.2.2 | |No changes required |mule-1.0.1 |(empty) |mule |1 |1.0.1 | |This is version 1 of mule, and version 2 already exists |EmiClock-1.0.2 |(empty) |emiclock |(empty) |1.0.2 | |No uppercase names for single programs |rdist-1.3alpha |(empty) |rdist |(empty) |1.3alpha | |Version will be `1.3.a` |es-0.9-beta1 |(empty) |es |(empty) |0.9-beta1 | |Version will be `0.9.b1` |mailman-2.0rc3 |(empty) |mailman |(empty) |2.0rc3 | |Version will be `2.0.r3` |v3.3beta021.src |(empty) |tiff |(empty) | |3.3 |What the heck was that anyway? |tvtwm |(empty) |tvtwm |(empty) | |p11 |No version in the filename, use what upstream says it is |piewm |(empty) |piewm |(empty) |1.0 | |No version in the filename, use what upstream says it is |xvgr-2.10pl1 |(empty) |xvgr |(empty) | |2.10.pl1 |In that case, `pl1` means patch level, so using DISTVERSION is not possible. |gawk-2.15.6 |ja- |gawk |(empty) |2.15.6 | |Japanese language version |psutils-1.13 |(empty) |psutils |-letter |1.13 | |Paper size hardcoded at package build time |pkfonts |(empty) |pkfonts |300 |1.0 | |Package for 300dpi fonts |=== If there is absolutely no trace of version information in the original source and it is unlikely that the original author will ever release another version, just set the version string to `1.0` (like the `piewm` example above). Otherwise, ask the original author or use the date string the source file was released on (`d__yyyy.mm.dd__`, or `d__yyyymmdd__`) as the version. [TIP] ==== Use any letter. Here, `d` here stands for date, if the source is a Git repository, `g` followed by the commit date is commonly used, using `s` for snapshot is also common. ==== [[makefile-categories]] == Categorization [[makefile-categories-definition]] === `CATEGORIES` When a package is created, it is put under [.filename]#/usr/ports/packages/All# and links are made from one or more subdirectories of [.filename]#/usr/ports/packages#. The names of these subdirectories are specified by the variable `CATEGORIES`. It is intended to make life easier for the user when he is wading through the pile of packages on the FTP site or the CDROM. Please take a look at the <> and pick the ones that are suitable for the port. This list also determines where in the ports tree the port is imported. If there is more than one category here, the port files must be put in the subdirectory with the name of the first category. See <> for more discussion about how to pick the right categories. [[porting-categories]] === Current List of Categories Here is the current list of port categories. Those marked with an asterisk (`*`) are _virtual_ categories-those that do not have a corresponding subdirectory in the ports tree. They are only used as secondary categories, and only for search purposes. [NOTE] ==== For non-virtual categories, there is a one-line description in `COMMENT` in that subdirectory's [.filename]#Makefile#. ==== [.informaltable] [cols="1,1,1", frame="none", options="header"] |=== | Category | Description | Notes |[.filename]#accessibility# |Ports to help disabled users. | |[.filename]#afterstep#`*` |Ports to support the http://www.afterstep.org[AfterStep] window manager. | |[.filename]#arabic# |Arabic language support. | |[.filename]#archivers# |Archiving tools. | |[.filename]#astro# |Astronomical ports. | |[.filename]#audio# |Sound support. | |[.filename]#benchmarks# |Benchmarking utilities. | |[.filename]#biology# |Biology-related software. | |[.filename]#cad# |Computer aided design tools. | |[.filename]#chinese# |Chinese language support. | |[.filename]#comms# |Communication software. |Mostly software to talk to the serial port. |[.filename]#converters# |Character code converters. | |[.filename]#databases# |Databases. | |[.filename]#deskutils# |Things that used to be on the desktop before computers were invented. | |[.filename]#devel# |Development utilities. |Do not put libraries here just because they are libraries. They should _not_ be in this category unless they truly do not belong anywhere else. |[.filename]#dns# |DNS-related software. | |[.filename]#docs#`*` |Meta-ports for FreeBSD documentation. | |[.filename]#editors# |General editors. |Specialized editors go in the section for those tools. For example, a mathematical-formula editor will go in [.filename]#math#, and have [.filename]#editors# as a second category. |[.filename]#elisp#`*` |Emacs-lisp ports. | |[.filename]#emulators# |Emulators for other operating systems. |Terminal emulators do _not_ belong here. X-based ones go to [.filename]#x11# and text-based ones to either [.filename]#comms# or [.filename]#misc#, depending on the exact functionality. |[.filename]#enlightenment#`*` |Ports related to the Enlightenment window manager. | |[.filename]#finance# |Monetary, financial and related applications. | |[.filename]#french# |French language support. | |[.filename]#ftp# |FTP client and server utilities. |If the port speaks both FTP and HTTP, put it in [.filename]#ftp# with a secondary category of [.filename]#www#. |[.filename]#games# |Games. | |[.filename]#geography#`*` |Geography-related software. | |[.filename]#german# |German language support. | |[.filename]#gnome#`*` |Ports from the http://www.gnome.org[GNOME] Project. | |[.filename]#gnustep#`*` |Software related to the GNUstep desktop environment. | |[.filename]#graphics# |Graphics utilities. | |[.filename]#hamradio#`*` |Software for amateur radio. | |[.filename]#haskell#`*` |Software related to the Haskell language. | |[.filename]#hebrew# |Hebrew language support. | |[.filename]#hungarian# |Hungarian language support. | |[.filename]#irc# |Internet Relay Chat utilities. | |[.filename]#japanese# |Japanese language support. | |[.filename]#java# |Software related to the Java(TM) language. |The [.filename]#java# category must not be the only one for a port. Save for ports directly related to the Java language, porters are also encouraged not to use [.filename]#java# as the main category of a port. |[.filename]#kde#`*` |Ports from the http://www.kde.org[KDE] Project (generic). | |[.filename]#kde-applications#`*` |Applications from the http://www.kde.org[KDE] Project. | |[.filename]#kde-frameworks#`*` |Add-on libraries from the http://www.kde.org[KDE] Project for programming with Qt. | |[.filename]#kde-plasma#`*` |Desktop from the http://www.kde.org[KDE] Project. | |[.filename]#kld#`*` |Kernel loadable modules. | |[.filename]#korean# |Korean language support. | |[.filename]#lang# |Programming languages. | |[.filename]#linux#`*` |Linux applications and support utilities. | |[.filename]#lisp#`*` |Software related to the Lisp language. | |[.filename]#mail# |Mail software. | |[.filename]#mate#`*` |Ports related to the MATE desktop environment, a fork of GNOME 2. | |[.filename]#math# |Numerical computation software and other utilities for mathematics. | |[.filename]#mbone#`*` |MBone applications. | |[.filename]#misc# |Miscellaneous utilities |Things that do not belong anywhere else. If at all possible, try to find a better category for the port than `misc`, as ports tend to be overlooked in here. |[.filename]#multimedia# |Multimedia software. | |[.filename]#net# |Miscellaneous networking software. | |[.filename]#net-im# |Instant messaging software. | |[.filename]#net-mgmt# |Networking management software. | |[.filename]#net-p2p# |Peer to peer network applications. | |[.filename]#net-vpn#`*` |Virtual Private Network applications. | |[.filename]#news# |USENET news software. | |[.filename]#parallel#`*` |Applications dealing with parallelism in computing. | |[.filename]#pear#`*` |Ports related to the Pear PHP framework. | |[.filename]#perl5#`*` |Ports that require Perl version 5 to run. | |[.filename]#plan9#`*` |Various programs from http://www.cs.bell-labs.com/plan9dist/[Plan9]. | |[.filename]#polish# |Polish language support. | |[.filename]#ports-mgmt# |Ports for managing, installing and developing FreeBSD ports and packages. | |[.filename]#portuguese# |Portuguese language support. | |[.filename]#print# |Printing software. |Desktop publishing tools (previewers, etc.) belong here too. |[.filename]#python#`*` |Software related to the http://www.python.org/[Python] language. | |[.filename]#ruby#`*` |Software related to the http://www.ruby-lang.org/[Ruby] language. | |[.filename]#rubygems#`*` |Ports of http://www.rubygems.org/[RubyGems] packages. | |[.filename]#russian# |Russian language support. | |[.filename]#scheme#`*` |Software related to the Scheme language. | |[.filename]#science# |Scientific ports that do not fit into other categories such as [.filename]#astro#, [.filename]#biology# and [.filename]#math#. | |[.filename]#security# |Security utilities. | |[.filename]#shells# |Command line shells. | |[.filename]#spanish#`*` |Spanish language support. | |[.filename]#sysutils# |System utilities. | |[.filename]#tcl#`*` |Ports that use Tcl to run. | |[.filename]#textproc# |Text processing utilities. |It does not include desktop publishing tools, which go to [.filename]#print#. |[.filename]#tk#`*` |Ports that use Tk to run. | |[.filename]#ukrainian# |Ukrainian language support. | |[.filename]#vietnamese# |Vietnamese language support. | |[.filename]#wayland#`*` |Ports to support the Wayland display server. | |[.filename]#windowmaker#`*` |Ports to support the WindowMaker window manager. | |[.filename]#www# |Software related to the World Wide Web. |HTML language support belongs here too. |[.filename]#x11# |The X Window System and friends. |This category is only for software that directly supports the window system. Do not put regular X applications here. Most of them go into other [.filename]#x11-*# categories (see below). |[.filename]#x11-clocks# |X11 clocks. | |[.filename]#x11-drivers# |X11 drivers. | |[.filename]#x11-fm# |X11 file managers. | |[.filename]#x11-fonts# |X11 fonts and font utilities. | |[.filename]#x11-servers# |X11 servers. | |[.filename]#x11-themes# |X11 themes. | |[.filename]#x11-toolkits# |X11 toolkits. | |[.filename]#x11-wm# |X11 window managers. | |[.filename]#xfce#`*` |Ports related to the http://www.xfce.org/[Xfce] desktop environment. | |[.filename]#zope#`*` |http://www.zope.org/[Zope] support. | |=== [[choosing-categories]] === Choosing the Right Category As many of the categories overlap, choosing which of the categories will be the primary category of the port can be tedious. There are several rules that govern this issue. Here is the list of priorities, in decreasing order of precedence: * The first category must be a physical category (see <>). This is necessary to make the packaging work. Virtual categories and physical categories may be intermixed after that. * Language specific categories always come first. For example, if the port installs Japanese X11 fonts, then the `CATEGORIES` line would read [.filename]#japanese x11-fonts#. * Specific categories are listed before less-specific ones. For instance, an HTML editor is listed as [.filename]#www editors#, not the other way around. Also, do not list [.filename]#net# when the port belongs to any of [.filename]#irc#, [.filename]#mail#, [.filename]#news#, [.filename]#security#, or [.filename]#www#, as [.filename]#net# is included implicitly. * [.filename]#x11# is used as a secondary category only when the primary category is a natural language. In particular, do not put [.filename]#x11# in the category line for X applications. * Emacs modes are placed in the same ports category as the application supported by the mode, not in [.filename]#editors#. For example, an Emacs mode to edit source files of some programming language goes into [.filename]#lang#. * Ports installing loadable kernel modules also have the virtual category [.filename]#kld# in their `CATEGORIES` line. This is one of the things handled automatically by adding `USES=kmod`. * [.filename]#misc# does not appear with any other non-virtual category. If there is `misc` with something else in `CATEGORIES`, that means `misc` can safely be deleted and the port placed only in the other subdirectory. * If the port truly does not belong anywhere else, put it in [.filename]#misc#. If the category is not clearly defined, please put a comment to that effect in the https://bugs.freebsd.org/submit/[port submission] in the bug database so we can discuss it before we import it. As a committer, send a note to the {freebsd-ports} so we can discuss it first. Too often, new ports are imported to the wrong category only to be moved right away. [[proposing-categories]] === Proposing a New Category As the Ports Collection has grown over time, various new categories have been introduced. New categories can either be _virtual_ categories-those that do not have a corresponding subdirectory in the ports tree- or _physical_ categories-those that do. This section discusses the issues involved in creating a new physical category. Read it thouroughly before proposing a new one. Our existing practice has been to avoid creating a new physical category unless either a large number of ports would logically belong to it, or the ports that would belong to it are a logically distinct group that is of limited general interest (for instance, categories related to spoken human languages), or preferably both. The rationale for this is that such a change creates a link:{committers-guide}#ports[fair amount of work] for both the committers and also for all users who track changes to the Ports Collection. In addition, proposed category changes just naturally seem to attract controversy. (Perhaps this is because there is no clear consensus on when a category is "too big", nor whether categories should lend themselves to browsing (and thus what number of categories would be an ideal number), and so forth.) Here is the procedure: [.procedure] ==== . Propose the new category on {freebsd-ports}. Include a detailed rationale for the new category, including why the existing categories are not sufficient, and the list of existing ports proposed to move. (If there are new ports pending in Bugzilla that would fit this category, list them too.) If you are the maintainer and/or submitter, respectively, mention that as it may help the case. . Participate in the discussion. . If it seems that there is support for the idea, file a PR which includes both the rationale and the list of existing ports that need to be moved. Ideally, this PR would also include these patches: ** [.filename]##Makefile##s for the new ports once they are repocopied ** [.filename]#Makefile# for the new category ** [.filename]#Makefile# for the old ports' categories ** [.filename]##Makefile##s for ports that depend on the old ports ** (for extra credit, include the other files that have to change, as per the procedure in the Committer's Guide.) . Since it affects the ports infrastructure and involves moving and patching many ports but also possibly running regression tests on the build cluster, assign the PR to the {portmgr}. . If that PR is approved, a committer will need to follow the rest of the procedure that is link:{committers-guide}#PORTS[outlined in the Committer's Guide]. ==== Proposing a new virtual category is similar to the above but much less involved, since no ports will actually have to move. In this case, the only patches to include in the PR would be those to add the new category to `CATEGORIES` of the affected ports. [[proposing-reorg]] === Proposing Reorganizing All the Categories Occasionally someone proposes reorganizing the categories with either a 2-level structure, or some other kind of keyword structure. To date, nothing has come of any of these proposals because, while they are very easy to make, the effort involved to retrofit the entire existing ports collection with any kind of reorganization is daunting to say the very least. Please read the history of these proposals in the mailing list archives before posting this idea. Furthermore, be prepared to be challenged to offer a working prototype. [[makefile-distfiles]] == The Distribution Files The second part of the [.filename]#Makefile# describes the files that must be downloaded to build the port, and where they can be downloaded. [[makefile-distname]] === `DISTNAME` `DISTNAME` is the name of the port as called by the authors of the software. `DISTNAME` defaults to `${PORTNAME}-${DISTVERSIONPREFIX}${DISTVERSION}${DISTVERSIONSUFFIX}`, and if not set, `DISTVERSION` defaults to `${PORTVERSION}` so override `DISTNAME` only if necessary. `DISTNAME` is only used in two places. First, the distribution file list (`DISTFILES`) defaults to `${DISTNAME}${EXTRACT_SUFX}`. Second, the distribution file is expected to extract into a subdirectory named `WRKSRC`, which defaults to [.filename]#work/${DISTNAME}#. Some vendor's distribution names which do not fit into the `${PORTNAME}-${PORTVERSION}`-scheme can be handled automatically by setting `DISTVERSIONPREFIX`, `DISTVERSION`, and `DISTVERSIONSUFFIX`. `PORTVERSION` will be derived from `DISTVERSION` automatically. [IMPORTANT] ==== Only one of `PORTVERSION` and `DISTVERSION` can be set at a time. If `DISTVERSION` does not derive a correct `PORTVERSION`, do not use `DISTVERSION`. ==== If the upstream version scheme can be derived into a ports-compatible version scheme, set some variable to the upstream version, _do not_ use `DISTVERSION` as the variable name. Set `PORTVERSION` to the computed version based on the variable you created, and set `DISTNAME` accordingly. If the upstream version scheme cannot easily be coerced into a ports-compatible value, set `PORTVERSION` to a sensible value, and set `DISTNAME` with `PORTNAME` with the verbatim upstream version. [[makefile-distname-ex1]] .Deriving `PORTVERSION` Manually [example] ==== BIND9 uses a version scheme that is not compatible with the ports versions (it has `-` in its versions) and cannot be derived using `DISTVERSION` because after the 9.9.9 release, it will release a "patchlevels" in the form of `9.9.9-P1`. DISTVERSION would translate that into `9.9.9.p1`, which, in the ports versioning scheme means 9.9.9 pre-release 1, which is before 9.9.9 and not after. So `PORTVERSION` is manually derived from an `ISCVERSION` variable to output `9.9.9p1`. The order into which the ports framework, and pkg, will sort versions is checked using the `-t` argument of man:pkg-version[8]: [source,shell] .... % pkg version -t 9.9.9 9.9.9.p1 > <.> % pkg version -t 9.9.9 9.9.9p1 < <.> .... <.> The `>` sign means that the first argument passed to `-t` is greater than the second argument. `9.9.9` is after `9.9.9.p1`. <.> The `<` sign means that the first argument passed to `-t` is less than the second argument. `9.9.9` is before `9.9.9p1`. In the port [.filename]#Makefile#, for example package:dns/bind99[], it is achieved by: [.programlisting] .... PORTNAME= bind PORTVERSION= ${ISCVERSION:S/-P/P/:S/b/.b/:S/a/.a/:S/rc/.rc/} CATEGORIES= dns net MASTER_SITES= ISC/bind9/${ISCVERSION} PKGNAMESUFFIX= 99 DISTNAME= ${PORTNAME}-${ISCVERSION} MAINTAINER= mat@FreeBSD.org COMMENT= BIND DNS suite with updated DNSSEC and DNS64 LICENSE= ISCL # ISC releases things like 9.8.0-P1 or 9.8.1rc1, which our versioning does not like ISCVERSION= 9.9.9-P6 .... Define upstream version in `ISCVERSION`, with a comment saying _why_ it is needed. Use `ISCVERSION` to get a ports-compatible `PORTVERSION`. Use `ISCVERSION` directly to get the correct URL for fetching the distribution file. Use `ISCVERSION` directly to name the distribution file. ==== [[makefile-distname-ex2]] .Derive `DISTNAME` from `PORTVERSION` [example] ==== From time to time, the distribution file name has little or no relation to the version of the software. In package:comms/kermit[], only the last element of the version is present in the distribution file: [.programlisting] .... PORTNAME= kermit PORTVERSION= 9.0.304 CATEGORIES= comms ftp net MASTER_SITES= ftp://ftp.kermitproject.org/kermit/test/tar/ DISTNAME= cku${PORTVERSION:E}-dev20 .... The `:E` man:make[1] modifier returns the suffix of the variable, in this case, `304`. The distribution file is correctly generated as `cku304-dev20.tar.gz`. ==== [[makefile-distname-ex3]] .Exotic Case 1 [example] ==== Sometimes, there is no relation between the software name, its version, and the distribution file it is distributed in. From package:audio/libworkman[]: [.programlisting] .... PORTNAME= libworkman PORTVERSION= 1.4 CATEGORIES= audio MASTER_SITES= LOCAL/jim DISTNAME= ${PORTNAME}-1999-06-20 .... ==== [[makefile-distname-ex4]] .Exotic Case 2 [example] ==== In package:comms/librs232[], the distribution file is not versioned, so using <> is needed: [.programlisting] .... PORTNAME= librs232 PORTVERSION= 20160710 CATEGORIES= comms MASTER_SITES= http://www.teuniz.net/RS-232/ DISTNAME= RS-232 DIST_SUBDIR= ${PORTNAME}-${PORTVERSION} .... ==== [NOTE] ==== `PKGNAMEPREFIX` and `PKGNAMESUFFIX` do not affect `DISTNAME`. Also note that if `WRKSRC` is equal to [.filename]#${WRKDIR}/${DISTNAME}# while the original source archive is named something other than `${PORTNAME}-${PORTVERSION}${EXTRACT_SUFX}`, leave `DISTNAME` alone- defining only `DISTFILES` is easier than both `DISTNAME` and `WRKSRC` (and possibly `EXTRACT_SUFX`). ==== [[makefile-master_sites]] === `MASTER_SITES` Record the directory part of the FTP/HTTP-URL pointing at the original tarball in `MASTER_SITES`. Do not forget the trailing slash ([.filename]#/#)! The `make` macros will try to use this specification for grabbing the distribution file with `FETCH` if they cannot find it already on the system. It is recommended that multiple sites are included on this list, preferably from different continents. This will safeguard against wide-area network problems. [IMPORTANT] ==== `MASTER_SITES` must not be blank. It must point to the actual site hosting the distribution files. It cannot point to web archives, or the FreeBSD distribution files cache sites. The only exception to this rule is ports that do not have any distribution files. For example, meta-ports do not have any distribution files, so `MASTER_SITES` does not need to be set. ==== [[makefile-master_sites-shorthand]] ==== Using `MASTER_SITE_*` Variables Shortcut abbreviations are available for popular archives like SourceForge (`SOURCEFORGE`), GNU (`GNU`), or Perl CPAN (`PERL_CPAN`). `MASTER_SITES` can use them directly: [.programlisting] .... MASTER_SITES= GNU/make .... The older expanded format still works, but all ports have been converted to the compact format. The expanded format looks like this: [.programlisting] .... MASTER_SITES= ${MASTER_SITE_GNU} MASTER_SITE_SUBDIR= make .... These values and variables are defined in https://svnweb.freebsd.org/ports/head/Mk/bsd.sites.mk?view=markup[Mk/bsd.sites.mk]. New entries are added often, so make sure to check the latest version of this file before submitting a port. [TIP] ==== For any `MASTER_SITE_FOO` variable, the shorthand `_FOO_` can be used. For example, use: [.programlisting] .... MASTER_SITES= FOO .... If `MASTER_SITE_SUBDIR` is needed, use this: [.programlisting] .... MASTER_SITES= FOO/bar .... ==== [NOTE] ==== Some `MASTER_SITE_*` names are quite long, and for ease of use, shortcuts have been defined: [[makefile-master_sites-shortcut]] .Shortcuts for `MASTER_SITE_*` Macros [cols="1,1", frame="none", options="header"] |=== | Macro | Shortcut |`PERL_CPAN` |`CPAN` |`GITHUB` |`GH` |`GITHUB_CLOUD` |`GHC` |`LIBREOFFICE_DEV` |`LODEV` |`NETLIB` |`NL` |`RUBYGEMS` |`RG` |`SOURCEFORGE` |`SF` |=== ==== [[makefile-master_sites-magic]] ==== Magic MASTER_SITES Macros Several "magic" macros exist for popular sites with a predictable directory structure. For these, just use the abbreviation and the system will choose a subdirectory automatically. For a port named `Stardict`, of version `1.2.3`, and hosted on SourceForge, adding this line: [.programlisting] .... MASTER_SITES= SF .... infers a subdirectory named `/project/stardict/stardict/1.2.3`. If the inferred directory is incorrect, it can be overridden: [.programlisting] .... MASTER_SITES= SF/stardict/WyabdcRealPeopleTTS/${PORTVERSION} .... This can also be written as [.programlisting] .... MASTER_SITES= SF MASTER_SITE_SUBDIR= stardict/WyabdcRealPeopleTTS/${PORTVERSION} .... [[makefile-master_sites-popular]] .Magic `MASTER_SITES` Macros [cols="1,1", frame="none", options="header"] |=== | Macro | Assumed subdirectory |`APACHE_COMMONS_BINARIES` |`${PORTNAME:S,commons-,,}` |`APACHE_COMMONS_SOURCE` |`${PORTNAME:S,commons-,,}` |`APACHE_JAKARTA` |`${PORTNAME:S,-,/,}/source` |`BERLIOS` |`${PORTNAME:tl}.berlios` |`CHEESESHOP` |`source/${DISTNAME:C/(.).\*/\1/}/${DISTNAME:C/(.*)-[0-9].*/\1/}` |`CPAN` |`${PORTNAME:C/-.*//}` |`DEBIAN` |`pool/main/${PORTNAME:C/^((lib)?.).*$/\1/}/${PORTNAME}` |`FARSIGHT` |`${PORTNAME}` |`FESTIVAL` |`${PORTREVISION}` |`GCC` |`releases/${DISTNAME}` |`GENTOO` |`distfiles` |`GIMP` |`${PORTNAME}/${PORTVERSION:R}/` |`GH` |`${GH_ACCOUNT}/${GH_PROJECT}/tar.gz/${GH_TAGNAME}?dummy=/` |`GHC` |`${GH_ACCOUNT}/${GH_PROJECT}/` |`GNOME` |`sources/${PORTNAME}/${PORTVERSION:C/^([0-9]+\.[0-9]+).*/\1/}` |`GNU` |`${PORTNAME}` |`GNUPG` |`${PORTNAME}` |`GNU_ALPHA` |`${PORTNAME}` |`HORDE` |`${PORTNAME}` |`LODEV` |`${PORTNAME}` |`MATE` |`${PORTVERSION:C/^([0-9]+\.[0-9]+).*/\1/}` |`MOZDEV` |`${PORTNAME:tl}` |`NL` |`${PORTNAME}` |`QT` |`archive/qt/${PORTVERSION:R}` |`SAMBA` |`${PORTNAME}` |`SAVANNAH` |`${PORTNAME:tl}` |`SF` |`${PORTNAME:tl}/${PORTNAME:tl}/${PORTVERSION}` |=== [[makefile-master_sites-github]] === `USE_GITHUB` If the distribution file comes from a specific commit or tag on https://github.com[GitHub] for which there is no officially released file, there is an easy way to set the right `DISTNAME` and `MASTER_SITES` automatically. These variables are available: [[makefile-master_sites-github-description]] .`USE_GITHUB` Description [cols="1,1,1", options="header"] |=== | Variable | Description | Default |`GH_ACCOUNT` |Account name of the GitHub user hosting the project |`${PORTNAME}` |`GH_PROJECT` |Name of the project on GitHub |`${PORTNAME}` |`GH_TAGNAME` |Name of the tag to download (2.0.1, hash, ...) Using the name of a branch here is incorrect. It is also possible to use the hash of a commit id to do a snapshot. |`${DISTVERSIONPREFIX}${DISTVERSION}${DISTVERSIONSUFFIX}` |`GH_SUBDIR` |When the software needs an additional distribution file to be extracted within `${WRKSRC}`, this variable can be used. See the examples in <> for more information. |(none) |`GH_TUPLE` |`GH_TUPLE` allows putting `GH_ACCOUNT`, `GH_PROJECT`, `GH_TAGNAME`, and `GH_SUBDIR` into a single variable. The format is _account_`:`_project_`:`_tagname_`:`_group_`/`_subdir_. The `/`_subdir_ part is optional. It is helpful when there is more than one GitHub project from which to fetch. |=== [IMPORTANT] ==== Do not use `GH_TUPLE` for the default distribution file, as it has no default. ==== [[makefile-master_sites-github-ex1]] .Simple Use of `USE_GITHUB` [example] ==== While trying to make a port for version `1.2.7` of pkg from the FreeBSD user on github, at https://github.com/freebsd/pkg[], The [.filename]#Makefile# would end up looking like this (slightly stripped for the example): [.programlisting] .... PORTNAME= pkg DISTVERSION= 1.2.7 USE_GITHUB= yes GH_ACCOUNT= freebsd .... It will automatically have `MASTER_SITES` set to `GH GHC` and `WRKSRC` to `${WRKDIR}/pkg-1.2.7`. ==== [[makefile-master_sites-github-ex2]] .More Complete Use of `USE_GITHUB` [example] ==== While trying to make a port for the bleeding edge version of pkg from the FreeBSD user on github, at https://github.com/freebsd/pkg[], the [.filename]#Makefile# ends up looking like this (slightly stripped for the example): [.programlisting] .... PORTNAME= pkg-devel DISTVERSION= 1.3.0.a.20140411 USE_GITHUB= yes GH_ACCOUNT= freebsd GH_PROJECT= pkg GH_TAGNAME= 6dbb17b .... It will automatically have `MASTER_SITES` set to `GH GHC` and `WRKSRC` to `${WRKDIR}/pkg-6dbb17b`. [TIP] **** `20140411` is the date of the commit referenced in `GH_TAGNAME`, not the date the [.filename]#Makefile# is edited, or the date the commit is made. **** ==== [[makefile-master_sites-github-ex3]] .Use of `USE_GITHUB` with `DISTVERSIONPREFIX` [example] ==== From time to time, `GH_TAGNAME` is a slight variation from `DISTVERSION`. For example, if the version is `1.0.2`, the tag is `v1.0.2`. In those cases, it is possible to use `DISTVERSIONPREFIX` or `DISTVERSIONSUFFIX`: [.programlisting] .... PORTNAME= foo DISTVERSIONPREFIX= v DISTVERSION= 1.0.2 USE_GITHUB= yes .... It will automatically set `GH_TAGNAME` to `v1.0.2`, while `WRKSRC` will be kept to `${WRKDIR}/foo-1.0.2`. ==== [[makefile-master_sites-github-ex4]] .Using `USE_GITHUB` When Upstream Does Not Use Versions [example] ==== If there never was a version upstream, do not invent one like `0.1` or `1.0`. Create the port with a `DISTVERSION` of `g__YYYYMMDD__`, where `g` is for Git, and `_YYYYMMDD_` represents the date the commit referenced in `GH_TAGNAME`. [.programlisting] .... PORTNAME= bar DISTVERSION= g20140411 USE_GITHUB= yes GH_TAGNAME= c472d66b .... This creates a versioning scheme that increases over time, and that is still before version `0` (see <> for details on man:pkg-version[8]): [source,shell] .... % pkg version -t g20140411 0 < .... Which means using `PORTEPOCH` will not be needed in case upstream decides to cut versions in the future. ==== [[makefile-master_sites-github-ex5]] .Using `USE_GITHUB` to Access a Commit Between Two Versions [example] ==== If the current version of the software uses a Git tag, and the port needs to be updated to a newer, intermediate version, without a tag, use man:git-describe[1] to find out the version to use: [source,shell] .... % git describe --tags f0038b1 v0.7.3-14-gf0038b1 .... `v0.7.3-14-gf0038b1` can be split into three parts: `v0.7.3`:: This is the last Git tag that appears in the commit history before the requested commit. `-14`:: This means that the requested commit, `f0038b1`, is the 14th commit after the `v0.7.3` tag. `-gf0038b1`:: The `-g` means "Git", and the `f0038b1` is the commit hash that this reference points to. [.programlisting] .... PORTNAME= bar DISTVERSIONPREFIX= v DISTVERSION= 0.7.3-14 DISTVERSIONSUFFIX= -gf0038b1 USE_GITHUB= yes .... This creates a versioning scheme that increases over time (well, over commits), and does not conflict with the creation of a `0.7.4` version. (See <> for details on man:pkg-version[8]): [source,shell] .... % pkg version -t 0.7.3 0.7.3.14 < % pkg version -t 0.7.3.14 0.7.4 < .... [NOTE] **** If the requested commit is the same as a tag, a shorter description is shown by default. The longer version is equivalent: [source,shell] .... % git describe --tags c66c71d v0.7.3 % git describe --tags --long c66c71d v0.7.3-0-gc66c71d .... **** ==== [[makefile-master_sites-github-multiple]] ==== Fetching Multiple Files from GitHub The `USE_GITHUB` framework also supports fetching multiple distribution files from different places in GitHub. It works in a way very similar to <>. Multiple values are added to `GH_ACCOUNT`, `GH_PROJECT`, and `GH_TAGNAME`. Each different value is assigned a group. The main value can either have no group, or the `:DEFAULT` group. A value can be omitted if it is the same as the default as listed in <>. `GH_TUPLE` can also be used when there are a lot of distribution files. It helps keep the account, project, tagname, and group information at the same place. For each group, a `${WRKSRC_group}` helper variable is created, containing the directory into which the file has been extracted. The `${WRKSRC_group}` variables can be used to move directories around during `post-extract`, or add to `CONFIGURE_ARGS`, or whatever is needed so that the software builds correctly. [CAUTION] ==== The `:__group__` part _must_ be used for _only one_ distribution file. It is used as a unique key and using it more than once will overwrite the previous values. ==== [NOTE] ==== As this is only syntactic sugar above `DISTFILES` and `MASTER_SITES`, the group names must adhere to the restrictions on group names outlined in <> ==== When fetching multiple files from GitHub, sometimes the default distribution file is not fetched from GitHub. To disable fetching the default distribution, set: [.programlisting] .... USE_GITHUB= nodefault .... [IMPORTANT] ==== When using `USE_GITHUB=nodefault`, the [.filename]#Makefile# must set `DISTFILES` in its <>. The definition should be: [.programlisting] .... DISTFILES= ${DISTNAME}${EXTRACT_SUFX} .... ==== [[makefile-master_sites-github-multi]] .Use of `USE_GITHUB` with Multiple Distribution Files [example] ==== From time to time, there is a need to fetch more than one distribution file. For example, when the upstream git repository uses submodules. This can be done easily using groups in the `GH_*` variables: [.programlisting] .... PORTNAME= foo DISTVERSION= 1.0.2 USE_GITHUB= yes GH_ACCOUNT= bar:icons,contrib GH_PROJECT= foo-icons:icons foo-contrib:contrib GH_TAGNAME= 1.0:icons fa579bc:contrib GH_SUBDIR= ext/icons:icons CONFIGURE_ARGS= --with-contrib=${WRKSRC_contrib} .... This will fetch three distribution files from github. The default one comes from [.filename]#foo/foo# and is version `1.0.2`. The second one, with the `icons` group, comes from [.filename]#bar/foo-icons# and is in version `1.0`. The third one comes from [.filename]#bar/foo-contrib# and uses the Git commit `fa579bc`. The distribution files are named [.filename]#foo-foo-1.0.2_GH0.tar.gz#, [.filename]#bar-foo-icons-1.0_GH0.tar.gz#, and [.filename]#bar-foo-contrib-fa579bc_GH0.tar.gz#. All the distribution files are extracted in `${WRKDIR}` in their respective subdirectories. The default file is still extracted in `${WRKSRC}`, in this case, [.filename]#${WRKDIR}/foo-1.0.2#. Each additional distribution file is extracted in `${WRKSRC_group}`. Here, for the `icons` group, it is called `${WRKSRC_icons}` and it contains [.filename]#${WRKDIR}/foo-icons-1.0#. The file with the `contrib` group is called `${WRKSRC_contrib}` and contains `${WRKDIR}/foo-contrib-fa579bc`. The software's build system expects to find the icons in a [.filename]#ext/icons# subdirectory in its sources, so `GH_SUBDIR` is used. `GH_SUBDIR` makes sure that [.filename]#ext# exists, but that [.filename]#ext/icons# does not already exist. Then it does this: [.programlisting] .... post-extract: @${MV} ${WRKSRC_icons} ${WRKSRC}/ext/icons .... ==== [[makefile-master_sites-github-multi2]] .Use of `USE_GITHUB` with Multiple Distribution Files Using `GH_TUPLE` [example] ==== This is functionally equivalent to <>, but using `GH_TUPLE`: [.programlisting] .... PORTNAME= foo DISTVERSION= 1.0.2 USE_GITHUB= yes GH_TUPLE= bar:foo-icons:1.0:icons/ext/icons \ bar:foo-contrib:fa579bc:contrib CONFIGURE_ARGS= --with-contrib=${WRKSRC_contrib} .... Grouping was used in the previous example with `bar:icons,contrib`. Some redundant information is present with `GH_TUPLE` because grouping is not possible. ==== [[makefile-master_sites-github-submodules]] .How to Use `USE_GITHUB` with Git Submodules? [example] ==== Ports with GitHub as an upstream repository sometimes use submodules. See man:git-submodule[1] for more information. The problem with submodules is that each is a separate repository. As such, they each must be fetched separately. Using package:finance/moneymanagerex[] as an example, its GitHub repository is https://github.com/moneymanagerex/moneymanagerex[]. It has a https://github.com/moneymanagerex/moneymanagerex/blob/master/.gitmodules[.gitmodules] file at the root. This file describes all the submodules used in this repository, and lists additional repositories needed. This file will tell what additional repositories are needed: [.programlisting] .... [submodule "lib/wxsqlite3"] path = lib/wxsqlite3 url = https://github.com/utelle/wxsqlite3.git [submodule "3rd/mongoose"] path = 3rd/mongoose url = https://github.com/cesanta/mongoose.git [submodule "3rd/LuaGlue"] path = 3rd/LuaGlue url = https://github.com/moneymanagerex/LuaGlue.git [submodule "3rd/cgitemplate"] path = 3rd/cgitemplate url = https://github.com/moneymanagerex/html-template.git [...] .... The only information missing from that file is the commit hash or tag to use as a version. This information is found after cloning the repository: [source,shell] .... % git clone --recurse-submodules https://github.com/moneymanagerex/moneymanagerex.git Cloning into 'moneymanagerex'... remote: Counting objects: 32387, done. [...] Submodule '3rd/LuaGlue' (https://github.com/moneymanagerex/LuaGlue.git) registered for path '3rd/LuaGlue' Submodule '3rd/cgitemplate' (https://github.com/moneymanagerex/html-template.git) registered for path '3rd/cgitemplate' Submodule '3rd/mongoose' (https://github.com/cesanta/mongoose.git) registered for path '3rd/mongoose' Submodule 'lib/wxsqlite3' (https://github.com/utelle/wxsqlite3.git) registered for path 'lib/wxsqlite3' [...] Cloning into '/home/mat/work/freebsd/ports/finance/moneymanagerex/moneymanagerex/3rd/LuaGlue'... Cloning into '/home/mat/work/freebsd/ports/finance/moneymanagerex/moneymanagerex/3rd/cgitemplate'... Cloning into '/home/mat/work/freebsd/ports/finance/moneymanagerex/moneymanagerex/3rd/mongoose'... Cloning into '/home/mat/work/freebsd/ports/finance/moneymanagerex/moneymanagerex/lib/wxsqlite3'... [...] Submodule path '3rd/LuaGlue': checked out 'c51d11a247ee4d1e9817dfa2a8da8d9e2f97ae3b' Submodule path '3rd/cgitemplate': checked out 'cd434eeeb35904ebcd3d718ba29c281a649b192c' Submodule path '3rd/mongoose': checked out '2140e5992ab9a3a9a34ce9a281abf57f00f95cda' Submodule path 'lib/wxsqlite3': checked out 'fb66eb230d8aed21dec273b38c7c054dcb7d6b51' [...] % cd moneymanagerex % git submodule status c51d11a247ee4d1e9817dfa2a8da8d9e2f97ae3b 3rd/LuaGlue (heads/master) cd434eeeb35904ebcd3d718ba29c281a649b192c 3rd/cgitemplate (cd434ee) 2140e5992ab9a3a9a34ce9a281abf57f00f95cda 3rd/mongoose (6.2-138-g2140e59) fb66eb230d8aed21dec273b38c7c054dcb7d6b51 lib/wxsqlite3 (v3.4.0) [...] .... It can also be found on GitHub. Each subdirectory that is a submodule is shown as `_directory @ hash_`, for example, `mongoose @ 2140e59`. [NOTE] **** While getting the information from GitHub seems more straightforward, the information found using `git submodule status` will provide more meaningful information. For example, here, ``lib/wxsqlite3``'s commit hash `fb66eb2` correspond to `v3.4.0`. Both can be used interchangeably, but when a tag is available, use it. **** Now that all the required information has been gathered, the [.filename]#Makefile# can be written (only GitHub-related lines are shown): [.programlisting] .... PORTNAME= moneymanagerex DISTVERSIONPREFIX= v DISTVERSION= 1.3.0 USE_GITHUB= yes GH_TUPLE= utelle:wxsqlite3:v3.4.0:wxsqlite3/lib/wxsqlite3 \ moneymanagerex:LuaGlue:c51d11a:lua_glue/3rd/LuaGlue \ moneymanagerex:html-template:cd434ee:html_template/3rd/cgitemplate \ cesanta:mongoose:2140e59:mongoose/3rd/mongoose \ [...] .... ==== [[makefile-master_sites-gitlab]] === `USE_GITLAB` Similar to GitHub, if the distribution file comes from https://gitlab.com[gitlab.com] or is hosting the GitLab software, these variables are available for use and might need to be set. [[makefile-master_sites-gitlab-description]] .`USE_GITLAB` Description [cols="1,1,1", options="header"] |=== | Variable | Description | Default |`GL_SITE` |Site name hosting the GitLab project |https://gitlab.com |`GL_ACCOUNT` |Account name of the GitLab user hosting the project |`${PORTNAME}` |`GL_PROJECT` |Name of the project on GitLab |`${PORTNAME}` |`GL_COMMIT` |The commit hash to download. Must be the full 160 bit, 40 character hex sha1 hash. This is a required variable for GitLab. |`(none)` |`GL_SUBDIR` |When the software needs an additional distribution file to be extracted within `${WRKSRC}`, this variable can be used. See the examples in <> for more information. |(none) |`GL_TUPLE` |`GL_TUPLE` allows putting `GL_SITE`, `GL_ACCOUNT`, `GL_PROJECT`, `GL_COMMIT`, and `GL_SUBDIR` into a single variable. The format is _site_`:`_account_`:`_project_`:`_commit_`:`_group_`/`_subdir_. The _site_`:` and `/`_subdir_ part is optional. It is helpful when there are more than one GitLab project from which to fetch. |=== [[makefile-master_sites-gitlab-ex1]] .Simple Use of `USE_GITLAB` [example] ==== While trying to make a port for version `1.14` of libsignon-glib from the accounts-sso user on gitlab.com, at https://gitlab.com/accounts-sso/libsignon-glib[], The [.filename]#Makefile# would end up looking like this for fetching the distribution files: [.programlisting] .... PORTNAME= libsignon-glib DISTVERSION= 1.14 USE_GITLAB= yes GL_ACCOUNT= accounts-sso GL_COMMIT= e90302e342bfd27bc8c9132ab9d0ea3d8723fd03 .... It will automatically have `MASTER_SITES` set to https://gitlab.com[gitlab.com] and `WRKSRC` to `${WRKDIR}/libsignon-glib-e90302e342bfd27bc8c9132ab9d0ea3d8723fd03-e90302e342bfd27bc8c9132ab9d0ea3d8723fd03`. ==== [[makefile-master_sites-gitlab-ex2]] .More Complete Use of `USE_GITLAB` [example] ==== A more complete use of the above if port had no versioning and foobar from the foo user on project bar on a self hosted GitLab site `https://gitlab.example.com`, the [.filename]#Makefile# ends up looking like this for fetching distribution files: [.programlisting] .... PORTNAME= foobar DISTVERSION= g20170906 USE_GITLAB= yes GL_SITE= https://gitlab.example.com GL_ACCOUNT= foo GL_PROJECT= bar GL_COMMIT= 9c1669ce60c3f4f5eb43df874d7314483fb3f8a6 .... -It will have `MASTER_SITES` set to "`https://gitlab.example.com`" and `WRKSRC` to `${WRKDIR}/bar-9c1669ce60c3f4f5eb43df874d7314483fb3f8a6-9c1669ce60c3f4f5eb43df874d7314483fb3f8a6`. +It will have `MASTER_SITES` set to `"https://gitlab.example.com"` and `WRKSRC` to `${WRKDIR}/bar-9c1669ce60c3f4f5eb43df874d7314483fb3f8a6-9c1669ce60c3f4f5eb43df874d7314483fb3f8a6`. [TIP] **** `20170906` is the date of the commit referenced in `GL_COMMIT`, not the date the [.filename]#Makefile# is edited, or the date the commit to the FreeBSD ports tree is made. **** [NOTE] **** ``GL_SITE``'s protocol, port and webroot can all be modified in the same variable. **** ==== [[makefile-master_sites-gitlab-multiple]] ==== Fetching Multiple Files from GitLab The `USE_GITLAB` framework also supports fetching multiple distribution files from different places from GitLab and GitLab hosted sites. It works in a way very similar to <> and <>. Multiple values are added to `GL_SITE`, `GL_ACCOUNT`, `GL_PROJECT` and `GL_COMMIT`. Each different value is assigned a group. <>. `GL_TUPLE` can also be used when there are a lot of distribution files. It helps keep the site, account, project, commit, and group information at the same place. For each group, a `${WRKSRC_group}` helper variable is created, containing the directory into which the file has been extracted. The `${WRKSRC_group}` variables can be used to move directories around during `post-extract`, or add to `CONFIGURE_ARGS`, or whatever is needed so that the software builds correctly. [CAUTION] ==== The `:__group__` part _must_ be used for _only one_ distribution file. It is used as a unique key and using it more than once will overwrite the previous values. ==== [NOTE] ==== As this is only syntactic sugar above `DISTFILES` and `MASTER_SITES`, the group names must adhere to the restrictions on group names outlined in <> ==== When fetching multiple files using GitLab, sometimes the default distribution file is not fetched from a GitLab site. To disable fetching the default distribution, set: [.programlisting] .... USE_GITLAB= nodefault .... [IMPORTANT] ==== When using `USE_GITLAB=nodefault`, the [.filename]#Makefile# must set `DISTFILES` in its <>. The definition should be: [.programlisting] .... DISTFILES= ${DISTNAME}${EXTRACT_SUFX} .... ==== [[makefile-master_sites-gitlab-multi]] .Use of `USE_GITLAB` with Multiple Distribution Files [example] ==== From time to time, there is a need to fetch more than one distribution file. For example, when the upstream git repository uses submodules. This can be done easily using groups in the `GL_*` variables: [.programlisting] .... PORTNAME= foo DISTVERSION= 1.0.2 USE_GITLAB= yes GL_SITE= https://gitlab.example.com:9434/gitlab:icons GL_ACCOUNT= bar:icons,contrib GL_PROJECT= foo-icons:icons foo-contrib:contrib GL_COMMIT= c189207a55da45305c884fe2b50e086fcad4724b ae7368cab1ca7ca754b38d49da064df87968ffe4:icons 9e4dd76ad9b38f33fdb417a4c01935958d5acd2a:contrib GL_SUBDIR= ext/icons:icons CONFIGURE_ARGS= --with-contrib=${WRKSRC_contrib} .... This will fetch two distribution files from gitlab.com and one from `gitlab.example.com` hosting GitLab. The default one comes from [.filename]#https://gitlab.com/foo/foo# and commit is `c189207a55da45305c884fe2b50e086fcad4724b`. The second one, with the `icons` group, comes from [.filename]#https://gitlab.example.com:9434/gitlab/bar/foo-icons# and commit is `ae7368cab1ca7ca754b38d49da064df87968ffe4`. The third one comes from [.filename]#https://gitlab.com/bar/foo-contrib# and is commit `9e4dd76ad9b38f33fdb417a4c01935958d5acd2a`. The distribution files are named [.filename]#foo-foo-c189207a55da45305c884fe2b50e086fcad4724b_GL0.tar.gz#, [.filename]#bar-foo-icons-ae7368cab1ca7ca754b38d49da064df87968ffe4_GL0.tar.gz#, and [.filename]#bar-foo-contrib-9e4dd76ad9b38f33fdb417a4c01935958d5acd2a_GL0.tar.gz#. All the distribution files are extracted in `${WRKDIR}` in their respective subdirectories. The default file is still extracted in `${WRKSRC}`, in this case, [.filename]#${WRKDIR}/foo-c189207a55da45305c884fe2b50e086fcad4724b-c189207a55da45305c884fe2b50e086fcad4724b#. Each additional distribution file is extracted in `${WRKSRC_group}`. Here, for the `icons` group, it is called `${WRKSRC_icons}` and it contains [.filename]#${WRKDIR}/foo-icons-ae7368cab1ca7ca754b38d49da064df87968ffe4-ae7368cab1ca7ca754b38d49da064df87968ffe4#. The file with the `contrib` group is called `${WRKSRC_contrib}` and contains `${WRKDIR}/foo-contrib-9e4dd76ad9b38f33fdb417a4c01935958d5acd2a-9e4dd76ad9b38f33fdb417a4c01935958d5acd2a`. The software's build system expects to find the icons in a [.filename]#ext/icons# subdirectory in its sources, so `GL_SUBDIR` is used. `GL_SUBDIR` makes sure that [.filename]#ext# exists, but that [.filename]#ext/icons# does not already exist. Then it does this: [.programlisting] .... post-extract: @${MV} ${WRKSRC_icons} ${WRKSRC}/ext/icons .... ==== [[makefile-master_sites-gitlab-multi2]] .Use of `USE_GITLAB` with Multiple Distribution Files Using `GL_TUPLE` [example] ==== This is functionally equivalent to <>, but using `GL_TUPLE`: [.programlisting] .... PORTNAME= foo DISTVERSION= 1.0.2 USE_GITLAB= yes GL_COMMIT= c189207a55da45305c884fe2b50e086fcad4724b GL_TUPLE= https://gitlab.example.com:9434/gitlab:bar:foo-icons:ae7368cab1ca7ca754b38d49da064df87968ffe4:icons/ext/icons \ bar:foo-contrib:9e4dd76ad9b38f33fdb417a4c01935958d5acd2a:contrib CONFIGURE_ARGS= --with-contrib=${WRKSRC_contrib} .... Grouping was used in the previous example with `bar:icons,contrib`. Some redundant information is present with `GL_TUPLE` because grouping is not possible. ==== [[makefile-extract_sufx]] === `EXTRACT_SUFX` If there is one distribution file, and it uses an odd suffix to indicate the compression mechanism, set `EXTRACT_SUFX`. For example, if the distribution file was named [.filename]#foo.tar.gzip# instead of the more normal [.filename]#foo.tar.gz#, write: [.programlisting] .... DISTNAME= foo EXTRACT_SUFX= .tar.gzip .... The `USES=tar[:__xxx__]`, `USES=lha` or `USES=zip` automatically set `EXTRACT_SUFX` to the most common archives extensions as necessary, see <> for more details. If neither of these are set then `EXTRACT_SUFX` defaults to `.tar.gz`. [NOTE] ==== As `EXTRACT_SUFX` is only used in `DISTFILES`, only set one of them.. ==== [[makefile-distfiles-definition]] === `DISTFILES` Sometimes the names of the files to be downloaded have no resemblance to the name of the port. For example, it might be called [.filename]#source.tar.gz# or similar. In other cases the application's source code might be in several different archives, all of which must be downloaded. If this is the case, set `DISTFILES` to be a space separated list of all the files that must be downloaded. [.programlisting] .... DISTFILES= source1.tar.gz source2.tar.gz .... If not explicitly set, `DISTFILES` defaults to `${DISTNAME}${EXTRACT_SUFX}`. [[makefile-extract_only]] === `EXTRACT_ONLY` If only some of the `DISTFILES` must be extracted-for example, one of them is the source code, while another is an uncompressed document-list the filenames that must be extracted in `EXTRACT_ONLY`. [.programlisting] .... DISTFILES= source.tar.gz manual.html EXTRACT_ONLY= source.tar.gz .... When none of the `DISTFILES` need to be uncompressed, set `EXTRACT_ONLY` to the empty string. [.programlisting] .... EXTRACT_ONLY= .... [[porting-patchfiles]] === `PATCHFILES` If the port requires some additional patches that are available by FTP or HTTP, set `PATCHFILES` to the names of the files and `PATCH_SITES` to the URL of the directory that contains them (the format is the same as `MASTER_SITES`). If the patch is not relative to the top of the source tree (that is, `WRKSRC`) because it contains some extra pathnames, set `PATCH_DIST_STRIP` accordingly. For instance, if all the pathnames in the patch have an extra `foozolix-1.0/` in front of the filenames, then set `PATCH_DIST_STRIP=-p1`. Do not worry if the patches are compressed; they will be decompressed automatically if the filenames end with [.filename]#.Z#, [.filename]#.gz#, [.filename]#.bz2# or [.filename]#.xz#. If the patch is distributed with some other files, such as documentation, in a compressed tarball, using `PATCHFILES` is not possible. If that is the case, add the name and the location of the patch tarball to `DISTFILES` and `MASTER_SITES`. Then, use `EXTRA_PATCHES` to point to those files and [.filename]#bsd.port.mk# will automatically apply them. In particular, do _not_ copy patch files into [.filename]#${PATCHDIR}#. That directory may not be writable. [TIP] ==== If there are multiple patches and they need mixed values for the strip parameter, it can be added alongside the patch name in `PATCHFILES`, e.g: [.programlisting] .... PATCHFILES= patch1 patch2:-p1 .... This does not conflict with <>, adding a group also works: [.programlisting] .... PATCHFILES= patch2:-p1:source2 .... ==== [NOTE] ==== The tarball will have been extracted alongside the regular source by then, so there is no need to explicitly extract it if it is a regular compressed tarball. Take extra care not to overwrite something that already exists in that directory if extracting it manually. Also, do not forget to add a command to remove the copied patch in the `pre-clean` target. ==== [[porting-master-sites-n]] === Multiple Distribution or Patches Files from Multiple Locations (Consider this to be a somewhat "advanced topic"; those new to this document may wish to skip this section at first). This section has information on the fetching mechanism known as both `MASTER_SITES:n` and `MASTER_SITES_NN`. We will refer to this mechanism as `MASTER_SITES:n`. A little background first. OpenBSD has a neat feature inside `DISTFILES` and `PATCHFILES` which allows files and patches to be postfixed with `:n` identifiers. Here, `n` can be any word containing `[0-9a-zA-Z_]` and denote a group designation. For example: [.programlisting] .... DISTFILES= alpha:0 beta:1 .... In OpenBSD, distribution file [.filename]#alpha# will be associated with variable `MASTER_SITES0` instead of our common `MASTER_SITES` and [.filename]#beta# with `MASTER_SITES1`. This is a very interesting feature which can decrease that endless search for the correct download site. Just picture 2 files in `DISTFILES` and 20 sites in `MASTER_SITES`, the sites slow as hell where [.filename]#beta# is carried by all sites in `MASTER_SITES`, and [.filename]#alpha# can only be found in the 20th site. It would be such a waste to check all of them if the maintainer knew this beforehand, would it not? Not a good start for that lovely weekend! Now that you have the idea, just imagine more `DISTFILES` and more `MASTER_SITES`. Surely our "distfiles survey meister" would appreciate the relief to network strain that this would bring. In the next sections, information will follow on the FreeBSD implementation of this idea. We improved a bit on OpenBSD's concept. [IMPORTANT] ==== The group names cannot have dashes in them (`-`), in fact, they cannot have any characters out of the `[a-zA-Z0-9_]` range. This is because, while man:make[1] is ok with variable names containing dashes, man:sh[1] is not. ==== [[porting-master-sites-n-simplified]] ==== Simplified Information This section explains how to quickly prepare fine grained fetching of multiple distribution files and patches from different sites and subdirectories. We describe here a case of simplified `MASTER_SITES:n` usage. This will be sufficient for most scenarios. More detailed information are available in <>. Some applications consist of multiple distribution files that must be downloaded from a number of different sites. For example, Ghostscript consists of the core of the program, and then a large number of driver files that are used depending on the user's printer. Some of these driver files are supplied with the core, but many others must be downloaded from a variety of different sites. To support this, each entry in `DISTFILES` may be followed by a colon and a "group name". Each site listed in `MASTER_SITES` is then followed by a colon, and the group that indicates which distribution files are downloaded from this site. For example, consider an application with the source split in two parts, [.filename]#source1.tar.gz# and [.filename]#source2.tar.gz#, which must be downloaded from two different sites. The port's [.filename]#Makefile# would include lines like <>. [[ports-master-sites-n-example-simple-use-one-file-per-site]] .Simplified Use of `MASTER_SITES:n` with One File Per Site [example] ==== [.programlisting] .... MASTER_SITES= ftp://ftp1.example.com/:source1 \ http://www.example.com/:source2 DISTFILES= source1.tar.gz:source1 \ source2.tar.gz:source2 .... ==== Multiple distribution files can have the same group. Continuing the previous example, suppose that there was a third distfile, [.filename]#source3.tar.gz#, that is downloaded from `ftp.example2.com`. The [.filename]#Makefile# would then be written like <>. [[ports-master-sites-n-example-simple-use-more-than-one-file-per-site]] .Simplified Use of `MASTER_SITES:n` with More Than One File Per Site [example] ==== [.programlisting] .... MASTER_SITES= ftp://ftp.example.com/:source1 \ http://www.example.com/:source2 DISTFILES= source1.tar.gz:source1 \ source2.tar.gz:source2 \ source3.tar.gz:source2 .... ==== [[ports-master-sites-n-detailed]] ==== Detailed Information Okay, so the previous example did not reflect the new port's needs? In this section we will explain in detail how the fine grained fetching mechanism `MASTER_SITES:n` works and how it can be used. . Elements can be postfixed with `:__n__` where _n_ is `[^:,]+`, that is, _n_ could conceptually be any alphanumeric string but we will limit it to `[a-zA-Z_][0-9a-zA-Z_]+` for now. + Moreover, string matching is case sensitive; that is, `n` is different from `N`. + However, these words cannot be used for postfixing purposes since they yield special meaning: `default`, `all` and `ALL` (they are used internally in item <>). Furthermore, `DEFAULT` is a special purpose word (check item <>). . Elements postfixed with `:n` belong to the group `n`, `:m` belong to group `m` and so forth. + [[porting-master-sites-n-DEFAULT-group]] . Elements without a postfix are groupless, they all belong to the special group `DEFAULT`. Any elements postfixed with `DEFAULT`, is just being redundant unless an element belongs to both `DEFAULT` and other groups at the same time (check item <>). + These examples are equivalent but the first one is preferred: + [.programlisting] .... MASTER_SITES= alpha .... + [.programlisting] .... MASTER_SITES= alpha:DEFAULT .... . Groups are not exclusive, an element may belong to several different groups at the same time and a group can either have either several different elements or none at all. + [[porting-master-sites-n-comma-operator]] . When an element belongs to several groups at the same time, use the comma operator (`,`). + Instead of repeating it several times, each time with a different postfix, we can list several groups at once in a single postfix. For instance, `:m,n,o` marks an element that belongs to group `m`, `n` and `o`. + All these examples are equivalent but the last one is preferred: + [.programlisting] .... MASTER_SITES= alpha alpha:SOME_SITE .... + [.programlisting] .... MASTER_SITES= alpha:DEFAULT alpha:SOME_SITE .... + [.programlisting] .... MASTER_SITES= alpha:SOME_SITE,DEFAULT .... + [.programlisting] .... MASTER_SITES= alpha:DEFAULT,SOME_SITE .... . All sites within a given group are sorted according to `MASTER_SORT_AWK`. All groups within `MASTER_SITES` and `PATCH_SITES` are sorted as well. + [[porting-master-sites-n-group-semantics]] . Group semantics can be used in any of the variables `MASTER_SITES`, `PATCH_SITES`, `MASTER_SITE_SUBDIR`, `PATCH_SITE_SUBDIR`, `DISTFILES`, and `PATCHFILES` according to this syntax: .. All `MASTER_SITES`, `PATCH_SITES`, `MASTER_SITE_SUBDIR` and `PATCH_SITE_SUBDIR` elements must be terminated with the forward slash `/` character. If any elements belong to any groups, the group postfix `:__n__` must come right after the terminator `/`. The `MASTER_SITES:n` mechanism relies on the existence of the terminator `/` to avoid confusing elements where a `:n` is a valid part of the element with occurrences where `:n` denotes group `n`. For compatibility purposes, since the `/` terminator was not required before in both `MASTER_SITE_SUBDIR` and `PATCH_SITE_SUBDIR` elements, if the postfix immediate preceding character is not a `/` then `:n` will be considered a valid part of the element instead of a group postfix even if an element is postfixed with `:n`. See both <> and <>. + [[ports-master-sites-n-example-detailed-use-master-site-subdir]] .Detailed Use of `MASTER_SITES:n` in `MASTER_SITE_SUBDIR` [example] ==== [.programlisting] .... MASTER_SITE_SUBDIR= old:n new/:NEW .... *** Directories within group `DEFAULT` -> old:n *** Directories within group `NEW` -> new ==== + [[ports-master-sites-n-example-detailed-use-complete-example-master-sites]] .Detailed Use of `MASTER_SITES:n` with Comma Operator, Multiple Files, Multiple Sites and Multiple Subdirectories [example] ==== [.programlisting] .... MASTER_SITES= http://site1/%SUBDIR%/ http://site2/:DEFAULT \ http://site3/:group3 http://site4/:group4 \ http://site5/:group5 http://site6/:group6 \ http://site7/:DEFAULT,group6 \ http://site8/%SUBDIR%/:group6,group7 \ http://site9/:group8 DISTFILES= file1 file2:DEFAULT file3:group3 \ file4:group4,group5,group6 file5:grouping \ file6:group7 MASTER_SITE_SUBDIR= directory-trial:1 directory-n/:groupn \ directory-one/:group6,DEFAULT \ directory .... The previous example results in this fine grained fetching. Sites are listed in the exact order they will be used. *** [.filename]#file1# will be fetched from **** `MASTER_SITE_OVERRIDE` **** http://site1/directory-trial:1/ **** http://site1/directory-one/ **** http://site1/directory/ **** http://site2/ **** http://site7/ **** `MASTER_SITE_BACKUP` *** [.filename]#file2# will be fetched exactly as [.filename]#file1# since they both belong to the same group **** `MASTER_SITE_OVERRIDE` **** http://site1/directory-trial:1/ **** http://site1/directory-one/ **** http://site1/directory/ **** http://site2/ **** http://site7/ **** `MASTER_SITE_BACKUP` *** [.filename]#file3# will be fetched from **** `MASTER_SITE_OVERRIDE` **** http://site3/ **** `MASTER_SITE_BACKUP` *** [.filename]#file4# will be fetched from **** `MASTER_SITE_OVERRIDE` **** http://site4/ **** http://site5/ **** http://site6/ **** http://site7/ **** http://site8/directory-one/ **** `MASTER_SITE_BACKUP` *** [.filename]#file5# will be fetched from **** `MASTER_SITE_OVERRIDE` **** `MASTER_SITE_BACKUP` *** [.filename]#file6# will be fetched from **** `MASTER_SITE_OVERRIDE` **** http://site8/ **** `MASTER_SITE_BACKUP` ==== . How do I group one of the special macros from [.filename]#bsd.sites.mk#, for example, SourceForge (`SF`)? + This has been simplified as much as possible. See <>. + [[ports-master-sites-n-example-detailed-use-master-site-sourceforge]] .Detailed Use of `MASTER_SITES:n` with SourceForge (`SF`) [example] ==== [.programlisting] .... MASTER_SITES= http://site1/ SF/something/1.0:sourceforge,TEST DISTFILES= something.tar.gz:sourceforge .... [.filename]#something.tar.gz# will be fetched from all sites within SourceForge. ==== . How do I use this with `PATCH*`? + All examples were done with `MASTER*` but they work exactly the same for `PATCH*` ones as can be seen in <>. + [[ports-master-sites-n-example-detailed-use-patch-sites]] .Simplified Use of `MASTER_SITES:n` with `PATCH_SITES` [example] ==== [.programlisting] .... PATCH_SITES= http://site1/ http://site2/:test PATCHFILES= patch1:test .... ==== [[port-master-sites-n-what-changed]] ==== What Does Change for Ports? What Does Not? [lowerroman] . All current ports remain the same. The `MASTER_SITES:n` feature code is only activated if there are elements postfixed with `:__n__` like elements according to the aforementioned syntax rules, especially as shown in item <>. + [[porting-master-sites-n-what-changes-in-port-targets]] . The port targets remain the same: `checksum`, `makesum`, `patch`, `configure`, `build`, etc. With the obvious exceptions of `do-fetch`, `fetch-list`, `master-sites` and `patch-sites`. ** `do-fetch`: deploys the new grouping postfixed `DISTFILES` and `PATCHFILES` with their matching group elements within both `MASTER_SITES` and `PATCH_SITES` which use matching group elements within both `MASTER_SITE_SUBDIR` and `PATCH_SITE_SUBDIR`. Check <>. ** `fetch-list`: works like old `fetch-list` with the exception that it groups just like `do-fetch`. ** `master-sites` and `patch-sites`: (incompatible with older versions) only return the elements of group `DEFAULT`; in fact, they execute targets `master-sites-default` and `patch-sites-default` respectively. + Furthermore, using target either `master-sites-all` or `patch-sites-all` is preferred to directly checking either `MASTER_SITES` or `PATCH_SITES`. Also, directly checking is not guaranteed to work in any future versions. Check item <> for more information on these new port targets. . New port targets .. There are `master-sites-_n_` and `patch-sites-_n_` targets which will list the elements of the respective group _n_ within `MASTER_SITES` and `PATCH_SITES` respectively. For instance, both `master-sites-DEFAULT` and `patch-sites-DEFAULT` will return the elements of group `DEFAULT`, `master-sites-test` and `patch-sites-test` of group `test`, and thereon. + [[porting-master-sites-n-new-port-targets-master-sites-all]] .. There are new targets `master-sites-all` and `patch-sites-all` which do the work of the old `master-sites` and `patch-sites` ones. They return the elements of all groups as if they all belonged to the same group with the caveat that it lists as many `MASTER_SITE_BACKUP` and `MASTER_SITE_OVERRIDE` as there are groups defined within either `DISTFILES` or `PATCHFILES`; respectively for `master-sites-all` and `patch-sites-all`. [[makefile-dist_subdir]] === `DIST_SUBDIR` Do not let the port clutter [.filename]#/usr/ports/distfiles#. If the port requires a lot of files to be fetched, or contains a file that has a name that might conflict with other ports (for example, [.filename]#Makefile#), set `DIST_SUBDIR` to the name of the port (`${PORTNAME}` or `${PKGNAMEPREFIX}${PORTNAME}` are fine). This will change `DISTDIR` from the default [.filename]#/usr/ports/distfiles# to [.filename]#/usr/ports/distfiles/${DIST_SUBDIR}#, and in effect puts everything that is required for the port into that subdirectory. It will also look at the subdirectory with the same name on the backup master site at http://distcache.FreeBSD.org[http://distcache.FreeBSD.org] (Setting `DISTDIR` explicitly in [.filename]#Makefile# will not accomplish this, so please use `DIST_SUBDIR`.) [NOTE] ==== This does not affect `MASTER_SITES` defined in the [.filename]#Makefile#. ==== [[makefile-maintainer]] == `MAINTAINER` Set your mail-address here. Please. _:-)_ Only a single address without the comment part is allowed as a `MAINTAINER` value. The format used is `user@hostname.domain`. Please do not include any descriptive text such as a real name in this entry. That merely confuses the Ports infrastructure and most tools using it. The maintainer is responsible for keeping the port up to date and making sure that it works correctly. For a detailed description of the responsibilities of a port maintainer, refer to link:{contributing}#maintain-port[The challenge for port maintainers]. [NOTE] ==== A maintainer volunteers to keep a port in good working order. Maintainers have the primary responsibility for their ports, but not exclusive ownership. Ports exist for the benefit of the community and, in reality, belong to the community. What this means is that people other than the maintainer can make changes to a port. Large changes to the Ports Collection might require changes to many ports. The FreeBSD Ports Management Team or members of other teams might modify ports to fix dependency issues or other problems, like a version bump for a shared library update. Some types of fixes have "blanket approval" from the {portmgr}, allowing any committer to fix those categories of problems on any port. These fixes do not need approval from the maintainer. Blanket approval for most ports applies to fixes like infrastructure changes, or trivial and _tested_ build and runtime fixes. The current list is available in link:{committers-guide}#ports-qa-misc-blanket-approval[Ports section of the Committer's Guide]. ==== Other changes to the port will be sent to the maintainer for review and approval before being committed. If the maintainer does not respond to an update request after two weeks (excluding major public holidays), then that is considered a maintainer timeout, and the update can be made without explicit maintainer approval. If the maintainer does not respond within three months, or if there have been three consecutive timeouts, then that maintainer is considered absent without leave, and all of their ports can be assigned back to the pool. Exceptions to this are anything maintained by the {portmgr}, or the {security-officer}. No unauthorized commits may ever be made to ports maintained by those groups. We reserve the right to modify the maintainer's submission to better match existing policies and style of the Ports Collection without explicit blessing from the submitter or the maintainer. Also, large infrastructural changes can result in a port being modified without the maintainer's consent. These kinds of changes will never affect the port's functionality. The {portmgr} reserves the right to revoke or override anyone's maintainership for any reason, and the {security-officer} reserves the right to revoke or override maintainership for security reasons. [[makefile-comment]] == `COMMENT` The comment is a one-line description of a port shown by `pkg info`. Please follow these rules when composing it: . The COMMENT string should be 70 characters or less. . Do _not_ include the package name or version number of software. . The comment must begin with a capital and end without a period. . Do not start with an indefinite article (that is, A or An). . Capitalize names such as Apache, JavaScript, or Perl. . Use a serial comma for lists of words: "green, red, and blue." . Check for spelling errors. Here is an example: [.programlisting] .... COMMENT= Cat chasing a mouse all over the screen .... The COMMENT variable immediately follows the MAINTAINER variable in the [.filename]#Makefile#. [[licenses]] == Licenses Each port must document the license under which it is available. If it is not an OSI approved license it must also document any restrictions on redistribution. [[licenses-license]] === `LICENSE` A short name for the license or licenses if more than one license apply. If it is one of the licenses listed in <>, only `LICENSE_FILE` and `LICENSE_DISTFILES` variables can be set. If this is a license that has not been defined in the ports framework (see <>), the `LICENSE_PERMS` and `LICENSE_NAME` must be set, along with either `LICENSE_FILE` or `LICENSE_TEXT`. `LICENSE_DISTFILES` and `LICENSE_GROUPS` can also be set, but are not required. The predefined licenses are shown in <>. The current list is always available in [.filename]#Mk/bsd.licenses.db.mk#. [[licenses-license-ex1]] .Simplest Usage, Predefined Licenses [example] ==== When the [.filename]#README# of some software says "This software is under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version." but does not provide the license file, use this: [.programlisting] .... LICENSE= LGPL21+ .... When the software provides the license file, use this: [.programlisting] .... LICENSE= LGPL21+ LICENSE_FILE= ${WRKSRC}/COPYING .... ==== For the predefined licenses, the default permissions are `dist-mirror dist-sell pkg-mirror pkg-sell auto-accept`. [[licenses-license-list]] .Predefined License List [cols="1,1,1,1", frame="none", options="header"] |=== | Short Name | Name | Group | Permissions |`AGPLv3` |GNU Affero General Public License version 3 |`FSF GPL OSI` |(default) |`AGPLv3+` |GNU Affero General Public License version 3 (or later) |`FSF GPL OSI` |(default) |`APACHE10` |Apache License 1.0 |`FSF` |(default) |`APACHE11` |Apache License 1.1 |`FSF OSI` |(default) |`APACHE20` |Apache License 2.0 |`FSF OSI` |(default) |`ART10` |Artistic License version 1.0 |`OSI` |(default) |`ART20` |Artistic License version 2.0 |`FSF GPL OSI` |(default) |`ARTPERL10` |Artistic License (perl) version 1.0 |`OSI` |(default) |`BSD` |BSD license Generic Version (deprecated) |`FSF OSI COPYFREE` |(default) |`BSD2CLAUSE` |BSD 2-clause "Simplified" License |`FSF OSI COPYFREE` |(default) |`BSD3CLAUSE` |BSD 3-clause "New" or "Revised" License |`FSF OSI COPYFREE` |(default) |`BSD4CLAUSE` |BSD 4-clause "Original" or "Old" License |`FSF` |(default) |`BSL` |Boost Software License |`FSF OSI COPYFREE` |(default) |`CC-BY-1.0` |Creative Commons Attribution 1.0 | |(default) |`CC-BY-2.0` |Creative Commons Attribution 2.0 | |(default) |`CC-BY-2.5` |Creative Commons Attribution 2.5 | |(default) |`CC-BY-3.0` |Creative Commons Attribution 3.0 | |(default) |`CC-BY-4.0` |Creative Commons Attribution 4.0 | |(default) |`CC-BY-NC-1.0` |Creative Commons Attribution Non Commercial 1.0 | |`dist-mirror``pkg-mirror``auto-accept` |`CC-BY-NC-2.0` |Creative Commons Attribution Non Commercial 2.0 | |`dist-mirror``pkg-mirror``auto-accept` |`CC-BY-NC-2.5` |Creative Commons Attribution Non Commercial 2.5 | |`dist-mirror``pkg-mirror``auto-accept` |`CC-BY-NC-3.0` |Creative Commons Attribution Non Commercial 3.0 | |`dist-mirror``pkg-mirror``auto-accept` |`CC-BY-NC-4.0` |Creative Commons Attribution Non Commercial 4.0 | |`dist-mirror``pkg-mirror``auto-accept` |`CC-BY-NC-ND-1.0` |Creative Commons Attribution Non Commercial No Derivatives 1.0 | |`dist-mirror``pkg-mirror``auto-accept` |`CC-BY-NC-ND-2.0` |Creative Commons Attribution Non Commercial No Derivatives 2.0 | |`dist-mirror``pkg-mirror``auto-accept` |`CC-BY-NC-ND-2.5` |Creative Commons Attribution Non Commercial No Derivatives 2.5 | |`dist-mirror``pkg-mirror``auto-accept` |`CC-BY-NC-ND-3.0` |Creative Commons Attribution Non Commercial No Derivatives 3.0 | |`dist-mirror``pkg-mirror``auto-accept` |`CC-BY-NC-ND-4.0` |Creative Commons Attribution Non Commercial No Derivatives 4.0 | |`dist-mirror``pkg-mirror``auto-accept` |`CC-BY-NC-SA-1.0` |Creative Commons Attribution Non Commercial Share Alike 1.0 | |`dist-mirror``pkg-mirror``auto-accept` |`CC-BY-NC-SA-2.0` |Creative Commons Attribution Non Commercial Share Alike 2.0 | |`dist-mirror``pkg-mirror``auto-accept` |`CC-BY-NC-SA-2.5` |Creative Commons Attribution Non Commercial Share Alike 2.5 | |`dist-mirror``pkg-mirror``auto-accept` |`CC-BY-NC-SA-3.0` |Creative Commons Attribution Non Commercial Share Alike 3.0 | |`dist-mirror``pkg-mirror``auto-accept` |`CC-BY-NC-SA-4.0` |Creative Commons Attribution Non Commercial Share Alike 4.0 | |`dist-mirror``pkg-mirror``auto-accept` |`CC-BY-ND-1.0` |Creative Commons Attribution No Derivatives 1.0 | |(default) |`CC-BY-ND-2.0` |Creative Commons Attribution No Derivatives 2.0 | |(default) |`CC-BY-ND-2.5` |Creative Commons Attribution No Derivatives 2.5 | |(default) |`CC-BY-ND-3.0` |Creative Commons Attribution No Derivatives 3.0 | |(default) |`CC-BY-ND-4.0` |Creative Commons Attribution No Derivatives 4.0 | |(default) |`CC-BY-SA-1.0` |Creative Commons Attribution Share Alike 1.0 | |(default) |`CC-BY-SA-2.0` |Creative Commons Attribution Share Alike 2.0 | |(default) |`CC-BY-SA-2.5` |Creative Commons Attribution Share Alike 2.5 | |(default) |`CC-BY-SA-3.0` |Creative Commons Attribution Share Alike 3.0 | |(default) |`CC-BY-SA-4.0` |Creative Commons Attribution Share Alike 4.0 | |(default) |`CC0-1.0` |Creative Commons Zero v1.0 Universal |`FSF GPL COPYFREE` |(default) |`CDDL` |Common Development and Distribution License |`FSF OSI` |(default) |`CPAL-1.0` |Common Public Attribution License |`FSF OSI` |(default) |`ClArtistic` |Clarified Artistic License |`FSF GPL OSI` |(default) |`EPL` |Eclipse Public License |`FSF OSI` |(default) |`GFDL` |GNU Free Documentation License |`FSF` |(default) |`GMGPL` |GNAT Modified General Public License |`FSF GPL OSI` |(default) |`GPLv1` |GNU General Public License version 1 |`FSF GPL OSI` |(default) |`GPLv1+` |GNU General Public License version 1 (or later) |`FSF GPL OSI` |(default) |`GPLv2` |GNU General Public License version 2 |`FSF GPL OSI` |(default) |`GPLv2+` |GNU General Public License version 2 (or later) |`FSF GPL OSI` |(default) |`GPLv3` |GNU General Public License version 3 |`FSF GPL OSI` |(default) |`GPLv3+` |GNU General Public License version 3 (or later) |`FSF GPL OSI` |(default) |`GPLv3RLE` |GNU GPL version 3 Runtime Library Exception |`FSF GPL OSI` |(default) |`GPLv3RLE+` |GNU GPL version 3 Runtime Library Exception (or later) |`FSF GPL OSI` |(default) |`ISCL` |Internet Systems Consortium License |`FSF GPL OSI COPYFREE` |(default) |`LGPL20` |GNU Library General Public License version 2.0 |`FSF GPL OSI` |(default) |`LGPL20+` |GNU Library General Public License version 2.0 (or later) |`FSF GPL OSI` |(default) |`LGPL21` |GNU Lesser General Public License version 2.1 |`FSF GPL OSI` |(default) |`LGPL21+` |GNU Lesser General Public License version 2.1 (or later) |`FSF GPL OSI` |(default) |`LGPL3` |GNU Lesser General Public License version 3 |`FSF GPL OSI` |(default) |`LGPL3+` |GNU Lesser General Public License version 3 (or later) |`FSF GPL OSI` |(default) |`LPPL10` |LaTeX Project Public License version 1.0 |`FSF OSI` |`dist-mirror dist-sell` |`LPPL11` |LaTeX Project Public License version 1.1 |`FSF OSI` |`dist-mirror dist-sell` |`LPPL12` |LaTeX Project Public License version 1.2 |`FSF OSI` |`dist-mirror dist-sell` |`LPPL13` |LaTeX Project Public License version 1.3 |`FSF OSI` |`dist-mirror dist-sell` |`LPPL13a` |LaTeX Project Public License version 1.3a |`FSF OSI` |`dist-mirror dist-sell` |`LPPL13b` |LaTeX Project Public License version 1.3b |`FSF OSI` |`dist-mirror dist-sell` |`LPPL13c` |LaTeX Project Public License version 1.3c |`FSF OSI` |`dist-mirror dist-sell` |`MIT` |MIT license / X11 license |`COPYFREE FSF GPL OSI` |(default) |`MPL10` |Mozilla Public License version 1.0 |`FSF OSI` |(default) |`MPL11` |Mozilla Public License version 1.1 |`FSF OSI` |(default) |`MPL20` |Mozilla Public License version 2.0 |`FSF OSI` |(default) |`NCSA` |University of Illinois/NCSA Open Source License |`COPYFREE FSF GPL OSI` |(default) |`NONE` |No license specified | |`none` |`OFL10` |SIL Open Font License version 1.0 (http://scripts.sil.org/OFL) |`FONTS` |(default) |`OFL11` |SIL Open Font License version 1.1 (http://scripts.sil.org/OFL) |`FONTS` |(default) |`OWL` |Open Works License (owl.apotheon.org) |`COPYFREE` |(default) |`OpenSSL` |OpenSSL License |`FSF` |(default) |`PD` |Public Domain |`GPL COPYFREE` |(default) |`PHP202` |PHP License version 2.02 |`FSF OSI` |(default) |`PHP30` |PHP License version 3.0 |`FSF OSI` |(default) |`PHP301` |PHP License version 3.01 |`FSF OSI` |(default) |`PSFL` |Python Software Foundation License |`FSF GPL OSI` |(default) |`PostgreSQL` |PostgreSQL Licence |`FSF GPL OSI COPYFREE` |(default) |`RUBY` |Ruby License |`FSF` |(default) |`UNLICENSE` |The Unlicense |`COPYFREE FSF GPL` |(default) |`WTFPL` |Do What the Fuck You Want To Public License version 2 |`GPL FSF COPYFREE` |(default) |`WTFPL1` |Do What the Fuck You Want To Public License version 1 |`GPL FSF COPYFREE` |(default) |`ZLIB` |zlib License |`GPL FSF OSI` |(default) |`ZPL21` |Zope Public License version 2.1 |`GPL OSI` |(default) |=== [[licenses-license_perms]] === `LICENSE_PERMS` and `LICENSE_PERMS_NAME_` Permissions. use `none` if empty. .License Permissions List [[licenses-license_perms-dist-mirror]] `dist-mirror`:: Redistribution of the distribution files is permitted. The distribution files will be added to the FreeBSD `MASTER_SITE_BACKUP` CDN. [[licenses-license_perms-no-dist-mirror]] `no-dist-mirror`:: Redistribution of the distribution files is prohibited. This is equivalent to setting <>. The distribution files will _not_ be added to the FreeBSD `MASTER_SITE_BACKUP` CDN. [[licenses-license_perms-dist-sell]] `dist-sell`:: Selling of distribution files is permitted. The distribution files will be present on the installer images. [[licenses-license_perms-no-dist-sell]] `no-dist-sell`:: Selling of distribution files is prohibited. This is equivalent to setting <>. [[licenses-license_perms-pkg-mirror]] `pkg-mirror`:: Free redistribution of package is permitted. The package will be distributed on the FreeBSD package CDN https://pkg.freebsd.org/[https://pkg.freebsd.org/]. [[licenses-license_perms-no-pkg-mirror]] `no-pkg-mirror`:: Free redistribution of package is prohibited. Equivalent to setting <>. The package will _not_ be distributed from the FreeBSD package CDN https://pkg.freebsd.org/[https://pkg.freebsd.org/]. [[licenses-license_perms-pkg-sell]] `pkg-sell`:: Selling of package is permitted. The package will be present on the installer images. [[licenses-license_perms-no-pkg-sell]] `no-pkg-sell`:: Selling of package is prohibited. This is equivalent to setting <>. The package will _not_ be present on the installer images. [[licenses-license_perms-auto-accept]] `auto-accept`:: License is accepted by default. Prompts to accept a license are not displayed unless the user has defined `LICENSES_ASK`. Use this unless the license states the user must accept the terms of the license. [[licenses-license_perms-no-auto-accept]] `no-auto-accept`:: License is not accepted by default. The user will always be asked to confirm the acceptance of this license. This must be used if the license states that the user must accept its terms. When both `_permission_` and `no-_permission_` is present the `no-_permission_` will cancel `_permission_`. When `_permission_` is not present, it is considered to be a `no-_permission_`. [WARNING] ==== Some missing permissions will prevent a port (and all ports depending on it) from being usable by package users: A port without the `auto-accept` permission will never be be built and all the ports depending on it will be ignored. A port without the `pkg-mirror` permission will be removed, as well as all the ports depending on it, after the build and they will ever end up being distributed. ==== [[licenses-license_perms-ex1]] .Nonstandard License [example] ==== Read the terms of the license and translate those using the available permissions. [.programlisting] .... LICENSE= UNKNOWN LICENSE_NAME= unknown LICENSE_TEXT= This program is NOT in public domain.\ It can be freely distributed for non-commercial purposes only. LICENSE_PERMS= dist-mirror no-dist-sell pkg-mirror no-pkg-sell auto-accept .... ==== [[licenses-license_perms-ex2]] .Standard and Nonstandard Licenses [example] ==== Read the terms of the license and express those using the available permissions. In case of doubt, please ask for guidance on the {freebsd-ports}. [.programlisting] .... LICENSE= WARSOW GPLv2 LICENSE_COMB= multi LICENSE_NAME_WARSOW= Warsow Content License LICENSE_FILE_WARSOW= ${WRKSRC}/docs/license.txt LICENSE_PERMS_WARSOW= dist-mirror pkg-mirror auto-accept .... When the permissions of the GPLv2 and the UNKNOWN licenses are mixed, the port ends up with `dist-mirror dist-sell pkg-mirror pkg-sell auto-accept dist-mirror no-dist-sell pkg-mirror no-pkg-sell auto-accept`. The `no-_permissions_` cancel the _permissions_. The resulting list of permissions are _dist-mirror pkg-mirror auto-accept_. The distribution files and the packages will not be available on the installer images. ==== [[licenses-license_groups]] === `LICENSE_GROUPS` and `LICENSE_GROUPS_NAME` Groups the license belongs. .Predefined License Groups List [[licenses-license_groups-FSF]] `FSF`:: Free Software Foundation Approved, see the http://www.fsf.org/licensing[FSF Licensing & Compliance Team]. [[licenses-license_groups-GPL]] `GPL`:: GPL Compatible [[licenses-license_groups-OSI]] `OSI`:: OSI Approved, see the Open Source Initiative http://opensource.org/licenses[Open Source Licenses] page. [[licenses-license_groups-COPYFREE]] `COPYFREE`:: Comply with Copyfree Standard Definition, see the http://copyfree.org/standard/licenses[Copyfree Licenses] page. [[licenses-license_groups-FONTS]] `FONTS`:: Font licenses [[licenses-license_name]] === `LICENSE_NAME` and `LICENSE_NAME_NAME` Full name of the license. [[licenses-license_name-ex1]] .`LICENSE_NAME` [example] ==== [.programlisting] .... LICENSE= UNRAR LICENSE_NAME= UnRAR License LICENSE_FILE= ${WRKSRC}/license.txt LICENSE_PERMS= dist-mirror dist-sell pkg-mirror pkg-sell auto-accept .... ==== [[licenses-license_file]] === `LICENSE_FILE` and `LICENSE_FILE_NAME` Full path to the file containing the license text, usually [.filename]#${WRKSRC}/some/file#. If the file is not in the distfile, and its content is too long to be put in <>, put it in a new file in [.filename]#${FILESDIR}#. [[licenses-license_file-ex1]] .`LICENSE_FILE` [example] ==== [.programlisting] .... LICENSE= GPLv3+ LICENSE_FILE= ${WRKSRC}/COPYING .... ==== [[licenses-license_text]] === `LICENSE_TEXT` and `LICENSE_TEXT_NAME` Text to use as a license. Useful when the license is not in the distribution files and its text is short. [[licenses-license_text-ex1]] .`LICENSE_TEXT` [example] ==== [.programlisting] .... LICENSE= UNKNOWN LICENSE_NAME= unknown LICENSE_TEXT= This program is NOT in public domain.\ It can be freely distributed for non-commercial purposes only,\ and THERE IS NO WARRANTY FOR THIS PROGRAM. LICENSE_PERMS= dist-mirror no-dist-sell pkg-mirror no-pkg-sell auto-accept .... ==== [[licenses-license_distfiles]] === `LICENSE_DISTFILES` and `LICENSE_DISTFILES_NAME` The distribution files to which the licenses apply. Defaults to all the distribution files. [[licenses-license_distfiles-ex1]] .`LICENSE_DISTFILES` [example] ==== Used when the distribution files do not all have the same license. For example, one has a code license, and another has some artwork that cannot be redistributed: [.programlisting] .... MASTER_SITES= SF/some-game DISTFILES= ${DISTNAME}${EXTRACT_SUFX} artwork.zip LICENSE= BSD3CLAUSE ARTWORK LICENSE_COMB= dual LICENSE_NAME_ARTWORK= The game artwork license LICENSE_TEXT_ARTWORK= The README says that the files cannot be redistributed LICENSE_PERMS_ARTWORK= pkg-mirror pkg-sell auto-accept LICENSE_DISTFILES_BSD3CLAUSE= ${DISTNAME}${EXTRACT_SUFX} LICENSE_DISTFILES_ARTWORK= artwork.zip .... ==== [[licenses-license_comb]] === `LICENSE_COMB` Set to `multi` if all licenses apply. Set to `dual` if any license applies. Defaults to `single`. [[licenses-license_comb-ex1]] .Dual Licenses [example] ==== When a port says "This software may be distributed under the GNU General Public License or the Artistic License", it means that either license can be used. Use this: [.programlisting] .... LICENSE= ART10 GPLv1 LICENSE_COMB= dual .... If license files are provided, use this: [.programlisting] .... LICENSE= ART10 GPLv1 LICENSE_COMB= dual LICENSE_FILE_ART10= ${WRKSRC}/Artistic LICENSE_FILE_GPLv1= ${WRKSRC}/Copying .... ==== [[licenses-license_comb-ex2]] .Multiple Licenses [example] ==== When part of a port has one license, and another part has a different license, use `multi`: [.programlisting] .... LICENSE= GPLv2 LGPL21+ LICENSE_COMB= multi .... ==== [[makefile-portscout]] == `PORTSCOUT` Portscout is an automated distfile check utility for the FreeBSD Ports Collection, described in detail in <>. `PORTSCOUT` defines special conditions within which the Portscout distfile scanner is restricted. Situations where `PORTSCOUT` is set include: * When distfiles have to be ignored, whether for specific versions, or specific minor revisions. For example, to exclude version _8.2_ from distfile version checks because it is known to be broken, add: + [.programlisting] .... PORTSCOUT= ignore:8.2 .... * When specific versions or specific major and minor revisions of a distfile must be checked. For example, if only version _0.6.4_ must be monitored because newer versions have compatibility issues with FreeBSD, add: + [.programlisting] .... PORTSCOUT= limit:^0\.6\.4 .... * When URLs listing the available versions differ from the download URLs. For example, to limit distfile version checks to the download page for the package:databases/pgtune[] port, add: + [.programlisting] .... PORTSCOUT= site:http://pgfoundry.org/frs/?group_id=1000416 .... [[makefile-depend]] == Dependencies Many ports depend on other ports. This is a very convenient feature of most Unix-like operating systems, including FreeBSD. Multiple ports can share a common dependency, rather than bundling that dependency with every port or package that needs it. There are seven variables that can be used to ensure that all the required bits will be on the user's machine. There are also some pre-supported dependency variables for common cases, plus a few more to control the behavior of dependencies. [IMPORTANT] ==== When software has extra dependencies that provide extra features, the base dependencies listed in `*_DEPENDS` should include the extra dependencies that would benefit most users. The base dependencies should never be a "minimal" dependency set. The goal is not to include every dependency possible. Only include those that will benefit most people. ==== [[makefile-lib_depends]] === `LIB_DEPENDS` This variable specifies the shared libraries this port depends on. It is a list of `_lib:dir_` tuples where `_lib_` is the name of the shared library, `_dir_` is the directory in which to find it in case it is not available. For example, [.programlisting] .... LIB_DEPENDS= libjpeg.so:graphics/jpeg .... will check for a shared jpeg library with any version, and descend into the [.filename]#graphics/jpeg# subdirectory of the ports tree to build and install it if it is not found. The dependency is checked twice, once from within the `build` target and then from within the `install` target. Also, the name of the dependency is put into the package so that `pkg install` (see man:pkg-install[8]) will automatically install it if it is not on the user's system. [[makefile-run_depends]] === `RUN_DEPENDS` This variable specifies executables or files this port depends on during run-time. It is a list of ``_path:dir_``[:``_target_``] tuples where `_path_` is the name of the executable or file, _dir_ is the directory in which to find it in case it is not available, and _target_ is the target to call in that directory. If _path_ starts with a slash (`/`), it is treated as a file and its existence is tested with `test -e`; otherwise, it is assumed to be an executable, and `which -s` is used to determine if the program exists in the search path. For example, [.programlisting] .... RUN_DEPENDS= ${LOCALBASE}/news/bin/innd:news/inn \ xmlcatmgr:textproc/xmlcatmgr .... will check if the file or directory [.filename]#/usr/local/news/bin/innd# exists, and build and install it from the [.filename]#news/inn# subdirectory of the ports tree if it is not found. It will also see if an executable called `xmlcatmgr` is in the search path, and descend into [.filename]#textproc/xmlcatmgr# to build and install it if it is not found. [NOTE] ==== In this case, `innd` is actually an executable; if an executable is in a place that is not expected to be in the search path, use the full pathname. ==== [NOTE] ==== The official search `PATH` used on the ports build cluster is [.programlisting] .... /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin .... ==== The dependency is checked from within the `install` target. Also, the name of the dependency is put into the package so that `pkg install` (see man:pkg-install[8]) will automatically install it if it is not on the user's system. The _target_ part can be omitted if it is the same as `DEPENDS_TARGET`. A quite common situation is when `RUN_DEPENDS` is literally the same as `BUILD_DEPENDS`, especially if ported software is written in a scripted language or if it requires the same build and run-time environment. In this case, it is both tempting and intuitive to directly assign one to the other: [.programlisting] .... RUN_DEPENDS= ${BUILD_DEPENDS} .... However, such assignment can pollute run-time dependencies with entries not defined in the port's original `BUILD_DEPENDS`. This happens because of man:make[1]'s lazy evaluation of variable assignment. Consider a [.filename]#Makefile# with `USE_*`, which are processed by [.filename]#ports/Mk/bsd.*.mk# to augment initial build dependencies. For example, `USES= gmake` adds package:devel/gmake[] to `BUILD_DEPENDS`. To prevent such additional dependencies from polluting `RUN_DEPENDS`, create another variable with the current content of `BUILD_DEPENDS` and assign it to both `BUILD_DEPENDS` and `RUN_DEPENDS`: [.programlisting] .... MY_DEPENDS= some:devel/some \ other:lang/other BUILD_DEPENDS= ${MY_DEPENDS} RUN_DEPENDS= ${MY_DEPENDS} .... [IMPORTANT] ==== _Do not_ use `:=` to assign `BUILD_DEPENDS` to `RUN_DEPENDS` or vice-versa. All variables are expanded immediately, which is exactly the wrong thing to do and almost always a failure. ==== [[makefile-build_depends]] === `BUILD_DEPENDS` This variable specifies executables or files this port requires to build. Like `RUN_DEPENDS`, it is a list of ``_path:dir_``[:``_target_``] tuples. For example, [.programlisting] .... BUILD_DEPENDS= unzip:archivers/unzip .... will check for an executable called `unzip`, and descend into the [.filename]#archivers/unzip# subdirectory of the ports tree to build and install it if it is not found. [NOTE] ==== "build" here means everything from extraction to compilation. The dependency is checked from within the `extract` target. The _target_ part can be omitted if it is the same as `DEPENDS_TARGET` ==== [[makefile-fetch_depends]] === `FETCH_DEPENDS` This variable specifies executables or files this port requires to fetch. Like the previous two, it is a list of ``_path:dir_``[:``_target_``] tuples. For example, [.programlisting] .... FETCH_DEPENDS= ncftp2:net/ncftp2 .... will check for an executable called `ncftp2`, and descend into the [.filename]#net/ncftp2# subdirectory of the ports tree to build and install it if it is not found. The dependency is checked from within the `fetch` target. The _target_ part can be omitted if it is the same as `DEPENDS_TARGET`. [[makefile-extract_depends]] === `EXTRACT_DEPENDS` This variable specifies executables or files this port requires for extraction. Like the previous, it is a list of ``_path:dir_``[:``_target_``] tuples. For example, [.programlisting] .... EXTRACT_DEPENDS= unzip:archivers/unzip .... will check for an executable called `unzip`, and descend into the [.filename]#archivers/unzip# subdirectory of the ports tree to build and install it if it is not found. The dependency is checked from within the `extract` target. The _target_ part can be omitted if it is the same as `DEPENDS_TARGET`. [NOTE] ==== Use this variable only if the extraction does not already work (the default assumes `tar`) and cannot be made to work using `USES=tar`, `USES=lha` or `USES=zip` described in <>. ==== [[makefile-patch_depends]] === `PATCH_DEPENDS` This variable specifies executables or files this port requires to patch. Like the previous, it is a list of ``_path:dir_``[:``_target_``] tuples. For example, [.programlisting] .... PATCH_DEPENDS= ${NONEXISTENT}:java/jfc:extract .... will descend into the [.filename]#java/jfc# subdirectory of the ports tree to extract it. The dependency is checked from within the `patch` target. The _target_ part can be omitted if it is the same as `DEPENDS_TARGET`. [[makefile-uses]] === `USES` Parameters can be added to define different features and dependencies used by the port. They are specified by adding this line to the [.filename]#Makefile#: [.programlisting] .... USES= feature[:arguments] .... For the complete list of values, please see <>. [WARNING] ==== `USES` cannot be assigned after inclusion of [.filename]#bsd.port.pre.mk#. ==== [[makefile-use-vars]] === `USE_*` Several variables exist to define common dependencies shared by many ports. Their use is optional, but helps to reduce the verbosity of the port [.filename]##Makefile##s. Each of them is styled as `USE_*`. These variables may be used only in the port [.filename]##Makefile##s and [.filename]#ports/Mk/bsd.*.mk#. They are not meant for user-settable options - use `PORT_OPTIONS` for that purpose. [NOTE] ==== It is _always_ incorrect to set any `USE_*` in [.filename]#/etc/make.conf#. For instance, setting [.programlisting] .... USE_GCC=X.Y .... (where X.Y is version number) would add a dependency on gccXY for every port, including `lang/gccXY` itself! ==== [[makefile-use-vars-table]] .`USE_*` [cols="1,1", frame="none", options="header"] |=== | Variable | Means |`USE_GCC` a| The port requires GCC (`gcc` or `{g-plus-plus}`) to build. Some ports need any GCC version, some require modern, recent versions. It is typically set to `any` (in this case, GCC from base would be used on versions of FreeBSD that still have it, or `lang/gcc` port would be installed when default C/C++ compiler is Clang); or `yes` (means always use stable, modern GCC from `lang/gcc` port). The exact version can also be specified, with a value such as `4.7`. The minimal required version can be specified as `4.6+`. The GCC from the base system is used when it satisfies the requested version, otherwise an appropriate compiler is built from the port, and `CC` and `CXX` are adjusted accordingly. [NOTE] ==== `USE_GCC` will register a build-time and a run-time dependency. ==== |=== Variables related to gmake and [.filename]#configure# are described in <>, while autoconf, automake and libtool are described in <>. Perl related variables are described in <>. X11 variables are listed in <>. <> deals with GNOME and <> with KDE related variables. <> documents Java variables, while <> contains information on Apache, PHP and PEAR modules. Python is discussed in <>, while Ruby in <>. <> provides variables used for SDL applications and finally, <> contains information on Xfce. [[makefile-version-dependency]] === Minimal Version of a Dependency A minimal version of a dependency can be specified in any `*_DEPENDS` except `LIB_DEPENDS` using this syntax: [.programlisting] .... p5-Spiffy>=0.26:devel/p5-Spiffy .... The first field contains a dependent package name, which must match the entry in the package database, a comparison sign, and a package version. The dependency is satisfied if p5-Spiffy-0.26 or newer is installed on the machine. [[makefile-note-on-dependencies]] === Notes on Dependencies As mentioned above, the default target to call when a dependency is required is `DEPENDS_TARGET`. It defaults to `install`. This is a user variable; it is never defined in a port's [.filename]#Makefile#. If the port needs a special way to handle a dependency, use the `:target` part of `*_DEPENDS` instead of redefining `DEPENDS_TARGET`. When running `make clean`, the port dependencies are automatically cleaned too. If this is not desirable, define `NOCLEANDEPENDS` in the environment. This may be particularly desirable if the port has something that takes a long time to rebuild in its dependency list, such as KDE, GNOME or Mozilla. To depend on another port unconditionally, use the variable `${NONEXISTENT}` as the first field of `BUILD_DEPENDS` or `RUN_DEPENDS`. Use this only when the source of the other port is needed. Compilation time can be saved by specifying the target too. For instance [.programlisting] .... BUILD_DEPENDS= ${NONEXISTENT}:graphics/jpeg:extract .... will always descend to the `jpeg` port and extract it. [[makefile-circular-dependencies]] === Circular Dependencies Are Fatal [IMPORTANT] ==== Do not introduce any circular dependencies into the ports tree! ==== The ports building technology does not tolerate circular dependencies. If one is introduced, someone, somewhere in the world, will have their FreeBSD installation broken almost immediately, with many others quickly to follow. These can really be hard to detect. If in doubt, before making that change, make sure to run: `cd /usr/ports; make index`. That process can be quite slow on older machines, but it may be able to save a large number of people, including yourself, a lot of grief in the process. [[makefile-automatic-dependencies]] === Problems Caused by Automatic Dependencies Dependencies must be declared either explicitly or by using the <>. Using other methods like automatic detection complicates indexing, which causes problems for port and package management. [[makefile-automatic-dependencies-bad]] .Wrong Declaration of an Optional Dependency [example] ==== [.programlisting] .... .include .if exists(${LOCALBASE}/bin/foo) LIB_DEPENDS= libbar.so:foo/bar .endif .... ==== The problem with trying to automatically add dependencies is that files and settings outside an individual port can change at any time. For example: an index is built, then a batch of ports are installed. But one of the ports installs the tested file. The index is now incorrect, because an installed port unexpectedly has a new dependency. The index may still be wrong even after rebuilding if other ports also determine their need for dependencies based on the existence of other files. [[makefile-automatic-dependencies-good]] .Correct Declaration of an Optional Dependency [example] ==== [.programlisting] .... OPTIONS_DEFINE= BAR BAR_DESC= Calling cellphones via bar BAR_LIB_DEPENDS= libbar.so:foo/bar .... ==== Testing option variables is the correct method. It will not cause inconsistencies in the index of a batch of ports, provided the options were defined prior to the index build. Simple scripts can then be used to automate the building, installation, and updating of these ports and their packages. [[makefile-masterdir]] == Slave Ports and `MASTERDIR` If the port needs to build slightly different versions of packages by having a variable (for instance, resolution, or paper size) take different values, create one subdirectory per package to make it easier for users to see what to do, but try to share as many files as possible between ports. Typically, by using variables cleverly, only a very short [.filename]#Makefile# is needed in all but one of the directories. In the sole [.filename]#Makefile#, use `MASTERDIR` to specify the directory where the rest of the files are. Also, use a variable as part of <> so the packages will have different names. This will be best demonstrated by an example. This is part of [.filename]#print/pkfonts300/Makefile#; [.programlisting] .... PORTNAME= pkfonts${RESOLUTION} PORTVERSION= 1.0 DISTFILES= pk${RESOLUTION}.tar.gz PLIST= ${PKGDIR}/pkg-plist.${RESOLUTION} .if !defined(RESOLUTION) RESOLUTION= 300 .else .if ${RESOLUTION} != 118 && ${RESOLUTION} != 240 && \ ${RESOLUTION} != 300 && ${RESOLUTION} != 360 && \ ${RESOLUTION} != 400 && ${RESOLUTION} != 600 .BEGIN: @${ECHO_MSG} "Error: invalid value for RESOLUTION: \"${RESOLUTION}\"" @${ECHO_MSG} "Possible values are: 118, 240, 300, 360, 400 and 600." @${FALSE} .endif .endif .... package:print/pkfonts300[] also has all the regular patches, package files, etc. Running `make` there, it will take the default value for the resolution (300) and build the port normally. As for other resolutions, this is the _entire_ [.filename]#print/pkfonts360/Makefile#: [.programlisting] .... RESOLUTION= 360 MASTERDIR= ${.CURDIR}/../pkfonts300 .include "${MASTERDIR}/Makefile" .... ([.filename]#print/pkfonts118/Makefile#, [.filename]#print/pkfonts600/Makefile#, and all the other are similar). `MASTERDIR` definition tells [.filename]#bsd.port.mk# that the regular set of subdirectories like `FILESDIR` and `SCRIPTDIR` are to be found under [.filename]#pkfonts300#. The `RESOLUTION=360` line will override the `RESOLUTION=300` line in [.filename]#pkfonts300/Makefile# and the port will be built with resolution set to 360. [[makefile-manpages]] == Man Pages If the port anchors its man tree somewhere other than `PREFIX`, use `MANDIRS` to specify those directories. Note that the files corresponding to manual pages must be placed in [.filename]#pkg-plist# along with the rest of the files. The purpose of `MANDIRS` is to enable automatic compression of manual pages, therefore the file names are suffixed with [.filename]#.gz#. [[makefile-info]] == Info Files If the package needs to install GNU info files, list them in `INFO` (without the trailing `.info`), one entry per document. These files are assumed to be installed to [.filename]#PREFIX/INFO_PATH#. Change `INFO_PATH` if the package uses a different location. However, this is not recommended. These entries contain just the path relative to [.filename]#PREFIX/INFO_PATH#. For example, package:lang/gcc34[] installs info files to [.filename]#PREFIX/INFO_PATH/gcc34#, and `INFO` will be something like this: [.programlisting] .... INFO= gcc34/cpp gcc34/cppinternals gcc34/g77 ... .... Appropriate installation/de-installation code will be automatically added to the temporary [.filename]#pkg-plist# before package registration. [[makefile-options]] == Makefile Options Many applications can be built with optional or differing configurations. Examples include choice of natural (human) language, GUI versus command-line, or type of database to support. Users may need a different configuration than the default, so the ports system provides hooks the port author can use to control which variant will be built. Supporting these options properly will make users happy, and effectively provide two or more ports for the price of one. [[makefile-options-options]] === `OPTIONS` [[makefile-options-background]] ==== Background `OPTIONS_*` give the user installing the port a dialog showing the available options, and then saves those options to [.filename]#${PORT_DBDIR}/${OPTIONS_NAME}/options#. The next time the port is built, the options are reused. `PORT_DBDIR` defaults to [.filename]#/var/db/ports#. `OPTIONS_NAME` is to the port origin with an underscore as the space separator, for example, for package:dns/bind99[] it will be `dns_bind99`. When the user runs `make config` (or runs `make build` for the first time), the framework checks for [.filename]#${PORT_DBDIR}/${OPTIONS_NAME}/options#. If that file does not exist, the values of `OPTIONS_*` are used, and a dialog box is displayed where the options can be enabled or disabled. Then [.filename]#options# is saved and the configured variables are used when building the port. If a new version of the port adds new `OPTIONS`, the dialog will be presented to the user with the saved values of old `OPTIONS` prefilled. `make showconfig` shows the saved configuration. Use `make rmconfig` to remove the saved configuration. [[makefile-options-syntax]] ==== Syntax `OPTIONS_DEFINE` contains a list of `OPTIONS` to be used. These are independent of each other and are not grouped: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT2 .... Once defined, `OPTIONS` are described (optional, but strongly recommended): [.programlisting] .... OPT1_DESC= Describe OPT1 OPT2_DESC= Describe OPT2 OPT3_DESC= Describe OPT3 OPT4_DESC= Describe OPT4 OPT5_DESC= Describe OPT5 OPT6_DESC= Describe OPT6 .... [.filename]#ports/Mk/bsd.options.desc.mk# has descriptions for many common `OPTIONS`. While often useful, override them if the description is insufficient for the port. [TIP] ==== When describing options, view it from the perspective of the user: "What functionality does it change?" and "Why would I want to enable this?" Do not just repeat the name. For example, describing the `NLS` option as "include NLS support" does not help the user, who can already see the option name but may not know what it means. Describing it as "Native Language Support via gettext utilities" is much more helpful. ==== [IMPORTANT] ==== Option names are always in all uppercase. They cannot use mixed case or lowercase. ==== `OPTIONS` can be grouped as radio choices, where only one choice from each group is allowed: [.programlisting] .... OPTIONS_SINGLE= SG1 OPTIONS_SINGLE_SG1= OPT3 OPT4 .... [WARNING] ==== There _must_ be one of each `OPTIONS_SINGLE` group selected at all times for the options to be valid. One option of each group _must_ be added to `OPTIONS_DEFAULT`. ==== `OPTIONS` can be grouped as radio choices, where none or only one choice from each group is allowed: [.programlisting] .... OPTIONS_RADIO= RG1 OPTIONS_RADIO_RG1= OPT7 OPT8 .... `OPTIONS` can also be grouped as "multiple-choice" lists, where _at least one_ option must be enabled: [.programlisting] .... OPTIONS_MULTI= MG1 OPTIONS_MULTI_MG1= OPT5 OPT6 .... `OPTIONS` can also be grouped as "multiple-choice" lists, where none or any option can be enabled: [.programlisting] .... OPTIONS_GROUP= GG1 OPTIONS_GROUP_GG1= OPT9 OPT10 .... `OPTIONS` are unset by default, unless they are listed in `OPTIONS_DEFAULT`: [.programlisting] .... OPTIONS_DEFAULT= OPT1 OPT3 OPT6 .... `OPTIONS` definitions must appear before the inclusion of [.filename]#bsd.port.options.mk#. `PORT_OPTIONS` values can only be tested after the inclusion of [.filename]#bsd.port.options.mk#. Inclusion of [.filename]#bsd.port.pre.mk# can be used instead, too, and is still widely used in ports written before the introduction of [.filename]#bsd.port.options.mk#. But be aware that some variables will not work as expected after the inclusion of [.filename]#bsd.port.pre.mk#, typically some `USE_*` flags. [[ports-options-simple-use]] .Simple Use of `OPTIONS` [example] ==== [.programlisting] .... OPTIONS_DEFINE= FOO BAR OPTIONS_DEFAULT=FOO FOO_DESC= Option foo support BAR_DESC= Feature bar support # Will add --with-foo / --without-foo FOO_CONFIGURE_WITH= foo BAR_RUN_DEPENDS= bar:bar/bar .include .... ==== [[ports-options-check-unset]] .Check for Unset Port `OPTIONS` [example] ==== [.programlisting] .... .if ! ${PORT_OPTIONS:MEXAMPLES} CONFIGURE_ARGS+=--without-examples .endif .... The form shown above is discouraged. The preferred method is using a configure knob to really enable and disable the feature to match the option: [.programlisting] .... # Will add --with-examples / --without-examples EXAMPLES_CONFIGURE_WITH= examples .... ==== [[ports-options-practical-use]] .Practical Use of `OPTIONS` [example] ==== [.programlisting] .... OPTIONS_DEFINE= EXAMPLES OPTIONS_DEFAULT= PGSQL LDAP SSL OPTIONS_SINGLE= BACKEND OPTIONS_SINGLE_BACKEND= MYSQL PGSQL BDB OPTIONS_MULTI= AUTH OPTIONS_MULTI_AUTH= LDAP PAM SSL EXAMPLES_DESC= Install extra examples MYSQL_DESC= Use MySQL as backend PGSQL_DESC= Use PostgreSQL as backend BDB_DESC= Use Berkeley DB as backend LDAP_DESC= Build with LDAP authentication support PAM_DESC= Build with PAM support SSL_DESC= Build with OpenSSL support # Will add USE_PGSQL=yes PGSQL_USE= pgsql=yes # Will add --enable-postgres / --disable-postgres PGSQL_CONFIGURE_ENABLE= postgres ICU_LIB_DEPENDS= libicuuc.so:devel/icu # Will add --with-examples / --without-examples EXAMPLES_CONFIGURE_WITH= examples # Check other OPTIONS .include .... ==== [[makefile-options-default]] ==== Default Options These options are always on by default. * `DOCS` - build and install documentation. * `NLS` - Native Language Support. * `EXAMPLES` - build and install examples. * `IPV6` - IPv6 protocol support. [NOTE] ==== There is no need to add these to `OPTIONS_DEFAULT`. To have them active, and show up in the options selection dialog, however, they must be added to `OPTIONS_DEFINE`. ==== [[makefile-options-auto-activation]] === Feature Auto-Activation When using a GNU configure script, keep an eye on which optional features are activated by auto-detection. Explicitly disable optional features that are not needed by adding `--without-xxx` or `--disable-xxx` in `CONFIGURE_ARGS`. [[makefile-options-auto-activation-bad]] .Wrong Handling of an Option [example] ==== [.programlisting] .... .if ${PORT_OPTIONS:MFOO} LIB_DEPENDS+= libfoo.so:devel/foo CONFIGURE_ARGS+= --enable-foo .endif .... ==== In the example above, imagine a library libfoo is installed on the system. The user does not want this application to use libfoo, so he toggled the option off in the `make config` dialog. But the application's configure script detects the library present in the system and includes its support in the resulting executable. Now when the user decides to remove libfoo from the system, the ports system does not protest (no dependency on libfoo was recorded) but the application breaks. [[makefile-options-auto-activation-good]] .Correct Handling of an Option [example] ==== [.programlisting] .... FOO_LIB_DEPENDS= libfoo.so:devel/foo # Will add --enable-foo / --disable-foo FOO_CONFIGURE_ENABLE= foo .... ==== [NOTE] ==== Under some circumstances, the shorthand conditional syntax can cause problems with complex constructs. The errors are usually `Malformed conditional`, an alternative syntax can be used. [.programlisting] .... .if !empty(VARIABLE:MVALUE) .... as an alternative to [.programlisting] .... .if ${VARIABLE:MVALUE} .... ==== [[options-helpers]] === Options Helpers There are some macros to help simplify conditional values which differ based on the options set. For easier access, a comprehensive list is provided: `PLIST_SUB`, `SUB_LIST`:: For automatic `%%_OPT_%%` and `%%NO__OPT__%%` generation, see <>. + For more complex usage, see <>. `CONFIGURE_ARGS`:: For `--enable-_x_` and `--disable-_x_`, see <>. + For `--with-_x_` and `--without-_x_`, see <>. + For all other cases, see <>. `CMAKE_ARGS`:: For arguments that are booleans (`on`, `off`, `true`, `false`, `0`, `1`) see <>. + For all other cases, see <>. `MESON_ARGS`:: For arguments that take `true` or `false`, see <>. + For arguments that take `yes` or `no`, use <>. + For arguments that take `enabled` or `disabled`, see <>. + For all other cases, use <>. `QMAKE_ARGS`:: See <>. `USE_*`:: See <>. `*_DEPENDS`:: See <>. `*` (Any variable):: The most used variables have direct helpers, see <>. + For any variable without a specific helper, see <>. Options dependencies:: When an option need another option to work, see <>. Options conflicts:: When an option cannot work if another is also enabled, see <>. Build targets:: When an option need some extra processing, see <>. [[options_sub]] ==== `OPTIONS_SUB` If `OPTIONS_SUB` is set to `yes` then each of the options added to `OPTIONS_DEFINE` will be added to `PLIST_SUB` and `SUB_LIST`, for example: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPTIONS_SUB= yes .... is equivalent to: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} PLIST_SUB+= OPT1="" NO_OPT1="@comment " SUB_LIST+= OPT1="" NO_OPT1="@comment " .else PLIST_SUB+= OPT1="@comment " NO_OPT1="" SUB_LIST+= OPT1="@comment " NO_OPT1="" .endif .... [NOTE] ==== The value of `OPTIONS_SUB` is ignored. Setting it to any value will add `PLIST_SUB` and `SUB_LIST` entries for _all_ options. ==== [[options-use]] ==== `OPT_USE` and `OPT_USE_OFF` When option _OPT_ is selected, for each `_key=value_` pair in ``OPT_USE``, _value_ is appended to the corresponding `USE_KEY`. If _value_ has spaces in it, replace them with commas and they will be changed back to spaces during processing. `OPT_USE_OFF` works the same way, but when `OPT` is _not_ selected. For example: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_USES= xorg OPT1_USE= mysql=yes xorg=x11,xextproto,xext,xrandr OPT1_USE_OFF= openssl=yes .... is equivalent to: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} USE_MYSQL= yes USES+= xorg USE_XORG= x11 xextproto xext xrandr .else USE_OPENSSL= yes .endif .... [[options-configure-helpers]] ==== `CONFIGURE_ARGS` Helpers [[options-configure_enable]] ===== `OPT_CONFIGURE_ENABLE` When option _OPT_ is selected, for each _entry_ in `OPT_CONFIGURE_ENABLE` then `--enable-_entry_` is appended to `CONFIGURE_ARGS`. When option _OPT_ is _not_ selected, `--disable-_entry_` is appended to `CONFIGURE_ARGS`. An optional argument can be specified with an `=` symbol. This argument is only appended to the `--enable-_entry_` configure option. For example: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT2 OPT1_CONFIGURE_ENABLE= test1 test2 OPT2_CONFIGURE_ENABLE= test2=exhaustive .... is equivalent to: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} CONFIGURE_ARGS+= --enable-test1 --enable-test2 .else CONFIGURE_ARGS+= --disable-test1 --disable-test2 .endif .if ${PORT_OPTIONS:MOPT2} CONFIGURE_ARGS+= --enable-test2=exhaustive .else CONFIGURE_ARGS+= --disable-test2 .endif .... [[options-configure_with]] ===== `OPT_CONFIGURE_WITH` When option _OPT_ is selected, for each _entry_ in `_OPT_CONFIGURE_WITH` then `--with-_entry_` is appended to `CONFIGURE_ARGS`. When option _OPT_ is _not_ selected, `--without-_entry_` is appended to `CONFIGURE_ARGS`. An optional argument can be specified with an `=` symbol. This argument is only appended to the `--with-_entry_` configure option. For example: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT2 OPT1_CONFIGURE_WITH= test1 OPT2_CONFIGURE_WITH= test2=exhaustive .... is equivalent to: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT2 .include .if ${PORT_OPTIONS:MOPT1} CONFIGURE_ARGS+= --with-test1 .else CONFIGURE_ARGS+= --without-test1 .endif .if ${PORT_OPTIONS:MOPT2} CONFIGURE_ARGS+= --with-test2=exhaustive .else CONFIGURE_ARGS+= --without-test2 .endif .... [[options-configure_on]] ===== `OPT_CONFIGURE_ON` and `OPT_CONFIGURE_OFF` When option _OPT_ is selected, the value of `OPT_CONFIGURE_ON`, if defined, is appended to `CONFIGURE_ARGS`. `OPT_CONFIGURE_OFF` works the same way, but when `OPT` is _not_ selected. For example: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_CONFIGURE_ON= --add-test OPT1_CONFIGURE_OFF= --no-test .... is equivalent to: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} CONFIGURE_ARGS+= --add-test .else CONFIGURE_ARGS+= --no-test .endif .... [TIP] ==== Most of the time, the helpers in <> and <> provide a shorter and more comprehensive functionality. ==== [[options-cmake-helpers]] ==== `CMAKE_ARGS` Helpers [[options-cmake_on]] ===== `OPT_CMAKE_ON` and `OPT_CMAKE_OFF` When option _OPT_ is selected, the value of `OPT_CMAKE_ON`, if defined, is appended to `CMAKE_ARGS`. `OPT_CMAKE_OFF` works the same way, but when `OPT` is _not_ selected. For example: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_CMAKE_ON= -DTEST:BOOL=true -DDEBUG:BOOL=true OPT1_CMAKE_OFF= -DOPTIMIZE:BOOL=true .... is equivalent to: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} CMAKE_ARGS+= -DTEST:BOOL=true -DDEBUG:BOOL=true .else CMAKE_ARGS+= -DOPTIMIZE:BOOL=true .endif .... [TIP] ==== See <> for a shorter helper when the value is boolean. ==== [[options-cmake_bool]] ===== `OPT_CMAKE_BOOL` and `OPT_CMAKE_BOOL_OFF` When option _OPT_ is selected, for each _entry_ in `OPT_CMAKE_BOOL` then `-D_entry_:BOOL=true` is appended to `CMAKE_ARGS`. When option _OPT_ is _not_ selected, `-D_entry_:BOOL=false` is appended to `CONFIGURE_ARGS`. `OPT_CMAKE_BOOL_OFF` is the opposite, `-D_entry_:BOOL=false` is appended to `CMAKE_ARGS` when the option is selected, and `-D_entry_:BOOL=true` when the option is _not_ selected. For example: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_CMAKE_BOOL= TEST DEBUG OPT1_CMAKE_BOOL_OFF= OPTIMIZE .... is equivalent to: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} CMAKE_ARGS+= -DTEST:BOOL=true -DDEBUG:BOOL=true \ -DOPTIMIZE:BOOL=false .else CMAKE_ARGS+= -DTEST:BOOL=false -DDEBUG:BOOL=false \ -DOPTIMIZE:BOOL=true .endif .... [[options-meson-helpers]] ==== `MESON_ARGS` Helpers [[options-meson_on]] ===== `OPT_MESON_ON` and `OPT_MESON_OFF` When option _OPT_ is selected, the value of `OPT_MESON_ON`, if defined, is appended to `MESON_ARGS`. `OPT_MESON_OFF` works the same way, but when `OPT` is _not_ selected. For example: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_MESON_ON= -Dopt=1 OPT1_MESON_OFF= -Dopt=2 .... is equivalent to: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} MESON_ARGS+= -Dopt=1 .else MESON_ARGS+= -Dopt=2 .endif .... [[options-meson_true]] ===== `OPT_MESON_TRUE` and `OPT_MESON_FALSE` When option _OPT_ is selected, for each _entry_ in `OPT_MESON_TRUE` then `-D_entry_=true` is appended to `MESON_ARGS`. When option _OPT_ is _not_ selected, `-D_entry_=false` is appended to `MESON_ARGS`. `OPT_MESON_FALSE` is the opposite, `-D_entry_=false` is appended to `MESON_ARGS` when the option is selected, and `-D_entry_=true` when the option is _not_ selected. For example: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_MESON_TRUE= test debug OPT1_MESON_FALSE= optimize .... is equivalent to: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} MESON_ARGS+= -Dtest=true -Ddebug=true \ -Doptimize=false .else MESON_ARGS+= -Dtest=false -Ddebug=false \ -Doptimize=true .endif .... [[options-meson_yes]] ===== `OPT_MESON_YES` and `OPT_MESON_NO` When option _OPT_ is selected, for each _entry_ in `OPT_MESON_YES` then `-D_entry_=yes` is appended to `MESON_ARGS`. When option _OPT_ is _not_ selected, `-D_entry_=no` is appended to `MESON_ARGS`. `OPT_MESON_NO` is the opposite, `-D_entry_=no` is appended to `MESON_ARGS` when the option is selected, and `-D_entry_=yes` when the option is _not_ selected. For example: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_MESON_YES= test debug OPT1_MESON_NO= optimize .... is equivalent to: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} MESON_ARGS+= -Dtest=yes -Ddebug=yes \ -Doptimize=no .else MESON_ARGS+= -Dtest=no -Ddebug=no \ -Doptimize=yes .endif .... [[options-meson_enabled]] ===== `OPT_MESON_ENABLED` and `OPT_MESON_DISABLED` When option _OPT_ is selected, for each _entry_ in `OPT_MESON_ENABLED` then `-D_entry_=enabled` is appended to `MESON_ARGS`. When option _OPT_ is _not_ selected, `-D_entry_=disabled` is appended to `MESON_ARGS`. `OPT_MESON_DISABLED` is the opposite, `-D_entry_=disabled` is appended to `MESON_ARGS` when the option is selected, and `-D_entry_=enabled` when the option is _not_ selected. For example: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_MESON_ENABLED= test OPT1_MESON_DISABLED= debug .... is equivalent to: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} MESON_ARGS+= -Dtest=enabled -Ddebug=disabled .else MESON_ARGS+= -Dtest=disabled -Ddebug=enabled .endif .... [[options-qmake_on]] ==== `OPT_QMAKE_ON` and `OPT_QMAKE_OFF` When option _OPT_ is selected, the value of `OPT_QMAKE_ON`, if defined, is appended to `QMAKE_ARGS`. `OPT_QMAKE_OFF` works the same way, but when `OPT` is _not_ selected. For example: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_QMAKE_ON= -DTEST:BOOL=true OPT1_QMAKE_OFF= -DPRODUCTION:BOOL=true .... is equivalent to: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} QMAKE_ARGS+= -DTEST:BOOL=true .else QMAKE_ARGS+= -DPRODUCTION:BOOL=true .endif .... [[options-implies]] ==== `OPT_IMPLIES` Provides a way to add dependencies between options. When _OPT_ is selected, all the options listed in this variable will be selected too. Using the <> described earlier to illustrate: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT2 OPT1_IMPLIES= OPT2 OPT1_CONFIGURE_ENABLE= opt1 OPT2_CONFIGURE_ENABLE= opt2 .... Is equivalent to: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT2 .include .if ${PORT_OPTIONS:MOPT1} CONFIGURE_ARGS+= --enable-opt1 .else CONFIGURE_ARGS+= --disable-opt1 .endif .if ${PORT_OPTIONS:MOPT2} || ${PORT_OPTIONS:MOPT1} CONFIGURE_ARGS+= --enable-opt2 .else CONFIGURE_ARGS+= --disable-opt2 .endif .... [[options-implies-ex1]] .Simple Use of `OPT_IMPLIES` [example] ==== This port has a `X11` option, and a `GNOME` option that needs the `X11` option to be selected to build. [.programlisting] .... OPTIONS_DEFINE= X11 GNOME OPTIONS_DEFAULT= X11 X11_USES= xorg X11_USE= xorg=xi,xextproto GNOME_USE= gnome=gtk30 GNOME_IMPLIES= X11 .... ==== [[options-prevents]] ==== `OPT_PREVENTS` and `OPT_PREVENTS_MSG` Provides a way to add conflicts between options. When _OPT_ is selected, all the options listed in `OPT_PREVENTS` must be un-selected. If `OPT_PREVENTS_MSG` is set and a conflict is triggered, its content will be shown explaining why they conflict. For example: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT2 OPT1_PREVENTS= OPT2 OPT1_PREVENTS_MSG= OPT1 and OPT2 enable conflicting options .... Is roughly equivalent to: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT2 .include .if ${PORT_OPTIONS:MOPT2} && ${PORT_OPTIONS:MOPT1} BROKEN= Option OPT1 conflicts with OPT2 (select only one) .endif .... The only difference is that the first one will write an error after running `make config`, suggesting changing the selected options. [[options-prevents-ex1]] .Simple Use of `OPT_PREVENTS` [example] ==== This port has `X509` and `SCTP` options. Both options add patches, but the patches conflict with each other, so they cannot be selected at the same time. [.programlisting] .... OPTIONS_DEFINE= X509 SCTP SCTP_PATCHFILES= ${PORTNAME}-6.8p1-sctp-2573.patch.gz:-p1 SCTP_CONFIGURE_WITH= sctp X509_PATCH_SITES= http://www.roumenpetrov.info/openssh/x509/:x509 X509_PATCHFILES= ${PORTNAME}-7.0p1+x509-8.5.diff.gz:-p1:x509 X509_PREVENTS= SCTP X509_PREVENTS_MSG= X509 and SCTP patches conflict .... ==== [[options-vars]] ==== `OPT_VARS` and `OPT_VARS_OFF` Provides a generic way to set and append to variables. [WARNING] ==== Before using `OPT_VARS` and `OPT_VARS_OFF`, see if there is already a more specific helper available in <>. ==== When option _OPT_ is selected, and `OPT_VARS` defined, `_key_=_value_` and `_key_+=_value_` pairs are evaluated from `OPT_VARS`. An `=` cause the existing value of `KEY` to be overwritten, an `+=` appends to the value. `OPT_VARS_OFF` works the same way, but when `OPT` is _not_ selected. [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT2 OPT3 OPT1_VARS= also_build+=bin1 OPT2_VARS= also_build+=bin2 OPT3_VARS= bin3_build=yes OPT3_VARS_OFF= bin3_build=no MAKE_ARGS= ALSO_BUILD="${ALSO_BUILD}" BIN3_BUILD="${BIN3_BUILD}" .... is equivalent to: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT2 MAKE_ARGS= ALSO_BUILD="${ALSO_BUILD}" BIN3_BUILD="${BIN3_BUILD}" .include .if ${PORT_OPTIONS:MOPT1} ALSO_BUILD+= bin1 .endif .if ${PORT_OPTIONS:MOPT2} ALSO_BUILD+= bin2 .endif .if ${PORT_OPTIONS:MOPT2} BIN3_BUILD= yes .else BIN3_BUILD= no .endif .... [IMPORTANT] ==== Values containing whitespace must be enclosed in quotes: [.programlisting] .... OPT_VARS= foo="bar baz" .... This is due to the way man:make[1] variable expansion deals with whitespace. When `OPT_VARS= foo=bar baz` is expanded, the variable ends up containing two strings, `foo=bar` and `baz`. But the submitter probably intended there to be only one string, `foo=bar baz`. Quoting the value prevents whitespace from being used as a delimiter. Also, _do not_ add extra spaces after the `_var_=` sign and before the value, it would also be split into two strings. _This will not work_: [.programlisting] .... OPT_VARS= foo= bar .... ==== [[options-dependencies]] ==== Dependencies, `OPT_DEPTYPE` and `OPT_DEPTYPE_OFF` For any of these dependency types: * `PKG_DEPENDS` * `EXTRACT_DEPENDS` * `PATCH_DEPENDS` * `FETCH_DEPENDS` * `BUILD_DEPENDS` * `LIB_DEPENDS` * `RUN_DEPENDS` When option _OPT_ is selected, the value of `PT_DEPTYPE`, if defined, is appended to `DEPTYPE`. `OPT_DEPTYPE_OFF` works the same, but when `OPT` is _not_ selected. For example: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_LIB_DEPENDS= liba.so:devel/a OPT1_LIB_DEPENDS_OFF= libb.so:devel/b .... is equivalent to: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} LIB_DEPENDS+= liba.so:devel/a .else LIB_DEPENDS+= libb.so:devel/b .endif .... [[options-variables]] ==== Generic Variables Replacement, `OPT_VARIABLE` and `OPT_VARIABLE_OFF` For any of these variables: * `ALL_TARGET` * `BINARY_ALIAS` * `BROKEN` * `CATEGORIES` * `CFLAGS` * `CONFIGURE_ENV` * `CONFLICTS` * `CONFLICTS_BUILD` * `CONFLICTS_INSTALL` * `CPPFLAGS` * `CXXFLAGS` * `DESKTOP_ENTRIES` * `DISTFILES` * `EXTRACT_ONLY` * `EXTRA_PATCHES` * `GH_ACCOUNT` * `GH_PROJECT` * `GH_SUBDIR` * `GH_TAGNAME` * `GH_TUPLE` * `GL_ACCOUNT` * `GL_COMMIT` * `GL_PROJECT` * `GL_SITE` * `GL_SUBDIR` * `GL_TUPLE` * `IGNORE` * `INFO` * `INSTALL_TARGET` * `LDFLAGS` * `LIBS` * `MAKE_ARGS` * `MAKE_ENV` * `MASTER_SITES` * `PATCHFILES` * `PATCH_SITES` * `PLIST_DIRS` * `PLIST_FILES` * `PLIST_SUB` * `PORTDOCS` * `PORTEXAMPLES` * `SUB_FILES` * `SUB_LIST` * `TEST_TARGET` * `USES` When option _OPT_ is selected, the value of `OPT_ABOVEVARIABLE`, if defined, is appended to `_ABOVEVARIABLE_`. `OPT_ABOVEVARIABLE_OFF` works the same way, but when `OPT` is _not_ selected. For example: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_USES= gmake OPT1_CFLAGS_OFF= -DTEST .... is equivalent to: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} USES+= gmake .else CFLAGS+= -DTEST .endif .... [NOTE] ==== Some variables are not in this list, in particular `PKGNAMEPREFIX` and `PKGNAMESUFFIX`. This is intentional. A port _must not_ change its name when its option set changes. ==== [WARNING] ==== Some of these variables, at least `ALL_TARGET`, `DISTFILES` and `INSTALL_TARGET`, have their default values set _after_ the options are processed. With these lines in the [.filename]#Makefile#: [.programlisting] .... ALL_TARGET= all DOCS_ALL_TARGET= doc .... If the `DOCS` option is enabled, `ALL_TARGET` will have a final value of `all doc`; if the option is disabled, it would have a value of `all`. With only the options helper line in the [.filename]#Makefile#: [.programlisting] .... DOCS_ALL_TARGET= doc .... If the `DOCS` option is enabled, `ALL_TARGET` will have a final value of `doc`; if the option is disabled, it would have a value of `all`. ==== [[options-targets]] ==== Additional Build Targets, `_target_-_OPT_-on` and `_target_-_OPT_-off` These [.filename]#Makefile# targets can accept optional extra build targets: * `pre-fetch` * `do-fetch` * `post-fetch` * `pre-extract` * `do-extract` * `post-extract` * `pre-patch` * `do-patch` * `post-patch` * `pre-configure` * `do-configure` * `post-configure` * `pre-build` * `do-build` * `post-build` * `pre-install` * `do-install` * `post-install` * `post-stage` * `pre-package` * `do-package` * `post-package` When option _OPT_ is selected, the target `_TARGET_-_OPT_-on`, if defined, is executed after `_TARGET_`. `_TARGET_-_OPT_-off` works the same way, but when `OPT` is _not_ selected. For example: [.programlisting] .... OPTIONS_DEFINE= OPT1 post-patch-OPT1-on: @${REINPLACE_CMD} -e '/opt1/s|/usr/bin/|${EXAMPLESDIR}/|' ${WRKSRC}/Makefile post-patch-OPT1-off: @${REINPLACE_CMD} -e '/opt1/s|/usr/bin/|${PREFIX}/bin/|' ${WRKSRC}/Makefile .... is equivalent to: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include post-patch: .if ${PORT_OPTIONS:MOPT1} @${REINPLACE_CMD} -e '/opt1/s|/usr/bin/|${EXAMPLESDIR}/|' ${WRKSRC}/Makefile .else @${REINPLACE_CMD} -e '/opt1/s|/usr/bin/|${PREFIX}/bin/|' ${WRKSRC}/Makefile .endif .... [[makefile-wrkdir]] == Specifying the Working Directory Each port is extracted into a working directory, which must be writable. The ports system defaults to having `DISTFILES` unpack in to a directory called `${DISTNAME}`. In other words, if the [.filename]#Makefile# has: [.programlisting] .... PORTNAME= foo DISTVERSION= 1.0 .... then the port's distribution files contain a top-level directory, [.filename]#foo-1.0#, and the rest of the files are located under that directory. A number of variables can be overridden if that is not the case. [[makefile-wrksrc]] === `WRKSRC` The variable lists the name of the directory that is created when the application's distfiles are extracted. If our previous example extracted into a directory called [.filename]#foo# (and not [.filename]#foo-1.0#) write: [.programlisting] .... WRKSRC= ${WRKDIR}/foo .... or possibly [.programlisting] .... WRKSRC= ${WRKDIR}/${PORTNAME} .... [[makefile-wrksrc_subdir]] === `WRKSRC_SUBDIR` If the source files needed for the port are in a subdirectory of the extracted distribution file, set `WRKSRC_SUBDIR` to that directory. [.programlisting] .... WRKSRC_SUBDIR= src .... [[makefile-no_wrksubdir]] === `NO_WRKSUBDIR` If the port does not extract in to a subdirectory at all, then set `NO_WRKSUBDIR` to indicate that. [.programlisting] .... NO_WRKSUBDIR= yes .... [NOTE] ==== Because `WRKDIR` is the only directory that is supposed to be writable during the build, and is used to store many files recording the status of the build, the port's extraction will be forced into a subdirectory. ==== [[conflicts]] == Conflict Handling There are three different variables to register a conflict between packages and ports: `CONFLICTS`, `CONFLICTS_INSTALL` and `CONFLICTS_BUILD`. [NOTE] ==== The conflict variables automatically set the variable `IGNORE`, which is more fully documented in <>. ==== When removing one of several conflicting ports, it is advisable to retain `CONFLICTS` in those other ports for a few months to cater for users who only update once in a while. [[conclicts-conflicts_install]] `CONFLICTS_INSTALL`:: If the package cannot coexist with other packages (because of file conflicts, runtime incompatibilities, etc.). `CONFLICTS_INSTALL` check is done after the build stage and prior to the install stage. [[conclicts-conflicts_build]] `CONFLICTS_BUILD`:: If the port cannot be built when other specific ports are already installed. Build conflicts are not recorded in the resulting package. [[conclicts-conflicts]] `CONFLICTS`:: If the port cannot be built if a certain port is already installed and the resulting package cannot coexist with the other package. `CONFLICTS` check is done prior to the build stage and prior to the install stage. The most common content of one of these variable is the package base of another port. The package base is the package name without the appended version, it can be obtained by running `make -V PKGBASE`. [[conflicts-ex1]] .Basic usage of `CONFLICTS*` [example] ==== package:dns/bind99[] cannot be installed if package:dns/bind910[] is present because they install same files. First gather the package base to use: [source,shell] .... % make -C dns/bind99 -V PKGBASE bind99 % make -C dns/bind910 -V PKGBASE bind910 .... Then add to the [.filename]#Makefile# of package:dns/bind99[]: [.programlisting] .... CONFLICTS_INSTALL= bind910 .... And add to the [.filename]#Makefile# of package:dns/bind910[]: [.programlisting] .... CONFLICTS_INSTALL= bind99 .... ==== Sometime, only some version of another port is incompatible, in this case, use the full package name, with the version, and use shell globs, like `*` and `?` to make sure all possible versions are matched. [[conflicts-ex2]] .Using `CONFLICTS*` With Globs. [example] ==== From versions from 2.0 and up-to 2.4.1_2, package:deskutils/gnotime[] used to install a bundled version of package:databases/qof[]. To reflect this past, the [.filename]#Makefile# of package:databases/qof[] contains: [.programlisting] .... CONFLICTS_INSTALL= gnotime-2.[0-3]* \ gnotime-2.4.0* gnotime-2.4.1 \ gnotime-2.4.1_[12] .... The first entry match versions `2.0` through `2.3`, the second all the revisions of `2.4.0`, the third the exact `2.4.1` version, and the last the first and second revisions of the `2.4.1` version. package:deskutils/gnotime[] does not have any conflicts line because its current version does not conflict with anything else. ==== [[install]] == Installing Files [IMPORTANT] ==== The `install` phase is very important to the end user because it adds files to their system. All the additional commands run in the port [.filename]#Makefile#'s `*-install` targets should be echoed to the screen. _Do not_ silence these commands with `@` or `.SILENT`. ==== [[install-macros]] === `INSTALL_*` Macros Use the macros provided in [.filename]#bsd.port.mk# to ensure correct modes of files in the port's `*-install` targets. Set ownership directly in [.filename]#pkg-plist# with the corresponding entries, such as `@(_owner_,_group_,)`, `@owner _owner_`, and `@group _group_`. These operators work until overridden, or until the end of [.filename]#pkg-plist#, so remember to reset them after they are no longer needed. The default ownership is `root:wheel`. See <> for more information. * `INSTALL_PROGRAM` is a command to install binary executables. * `INSTALL_SCRIPT` is a command to install executable scripts. * `INSTALL_LIB` is a command to install shared libraries (but not static libraries). * `INSTALL_KLD` is a command to install kernel loadable modules. Some architectures do not like having the modules stripped, so use this command instead of `INSTALL_PROGRAM`. * `INSTALL_DATA` is a command to install sharable data, including static libraries. * `INSTALL_MAN` is a command to install manpages and other documentation (it does not compress anything). These variables are set to the man:install[1] command with the appropriate flags for each situation. [IMPORTANT] ==== Do not use `INSTALL_LIB` to install static libraries, because stripping them renders them useless. Use `INSTALL_DATA` instead. ==== [[install-strip]] === Stripping Binaries and Shared Libraries Installed binaries should be stripped. Do not strip binaries manually unless absolutely required. The `INSTALL_PROGRAM` macro installs and strips a binary at the same time. The `INSTALL_LIB` macro does the same thing to shared libraries. When a file must be stripped, but neither `INSTALL_PROGRAM` nor `INSTALL_LIB` macros are desirable, `${STRIP_CMD}` strips the program or shared library. This is typically done within the `post-install` target. For example: [.programlisting] .... post-install: ${STRIP_CMD} ${STAGEDIR}${PREFIX}/bin/xdl .... When multiple files need to be stripped: [.programlisting] .... post-install: .for l in geometry media body track world ${STRIP_CMD} ${STAGEDIR}${PREFIX}/lib/lib${PORTNAME}-${l}.so.0 .endfor .... Use man:file[1] on a file to determine if it has been stripped. Binaries are reported by man:file[1] as `stripped`, or `not stripped`. Additionally, man:strip[1] will detect programs that have already been stripped and exit cleanly. [IMPORTANT] ==== When `WITH_DEBUG` is defined, elf files _must not_ be stripped. The variables (`STRIP_CMD`, `INSTALL_PROGRAM`, `INSTALL_LIB`, ...) and <> provided by the framework handle this automatically. Some software, add `-s` to their `LDFLAGS`, in this case, either remove `-s` if `WITH_DEBUG` is set, or remove it unconditionally and use `STRIP_CMD` in `post-install`. ==== [[install-copytree]] === Installing a Whole Tree of Files Sometimes, a large number of files must be installed while preserving their hierarchical organization. For example, copying over a whole directory tree from `WRKSRC` to a target directory under `PREFIX`. Note that `PREFIX`, `EXAMPLESDIR`, `DATADIR`, and other path variables must always be prepended with `STAGEDIR` to respect staging (see <>). Two macros exist for this situation. The advantage of using these macros instead of `cp` is that they guarantee proper file ownership and permissions on target files. The first macro, `COPYTREE_BIN`, will set all the installed files to be executable, thus being suitable for installing into [.filename]#PREFIX/bin#. The second macro, `COPYTREE_SHARE`, does not set executable permissions on files, and is therefore suitable for installing files under [.filename]#PREFIX/share# target. [.programlisting] .... post-install: ${MKDIR} ${STAGEDIR}${EXAMPLESDIR} (cd ${WRKSRC}/examples && ${COPYTREE_SHARE} . ${STAGEDIR}${EXAMPLESDIR}) .... This example will install the contents of the [.filename]#examples# directory in the vendor distfile to the proper examples location of the port. [.programlisting] .... post-install: ${MKDIR} ${STAGEDIR}${DATADIR}/summer (cd ${WRKSRC}/temperatures && ${COPYTREE_SHARE} "June July August" ${STAGEDIR}${DATADIR}/summer) .... And this example will install the data of summer months to the [.filename]#summer# subdirectory of a [.filename]#DATADIR#. Additional `find` arguments can be passed via the third argument to `COPYTREE_*` macros. For example, to install all files from the first example except Makefiles, one can use these commands. [.programlisting] .... post-install: ${MKDIR} ${STAGEDIR}${EXAMPLESDIR} (cd ${WRKSRC}/examples && \ ${COPYTREE_SHARE} . ${STAGEDIR}${EXAMPLESDIR} "! -name Makefile") .... These macros do not add the installed files to [.filename]#pkg-plist#. They must be added manually. For optional documentation (`PORTDOCS`, see <>) and examples (`PORTEXAMPLES`), the `%%PORTDOCS%%` or `%%PORTEXAMPLES%%` prefixes must be prepended in [.filename]#pkg-plist#. [[install-documentation]] === Install Additional Documentation If the software has some documentation other than the standard man and info pages that is useful for the user, install it under `DOCSDIR` This can be done, like the previous item, in the `post-install` target. Create a new directory for the port. The directory name is `DOCSDIR`. This usually equals `PORTNAME`. However, if the user might want different versions of the port to be installed at the same time, the whole `PKGNAME` can be used. Since only the files listed in [.filename]#pkg-plist# are installed, it is safe to always install documentation to `STAGEDIR` (see <>). Hence `.if` blocks are only needed when the installed files are large enough to cause significant I/O overhead. [.programlisting] .... post-install: ${MKDIR} ${STAGEDIR}${DOCSDIR} ${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${STAGEDIR}${DOCSDIR} .... On the other hand, if there is a DOCS option in the port, install the documentation in a `post-install-DOCS-on` target. These targets are described in <>. Here are some handy variables and how they are expanded by default when used in the [.filename]#Makefile#: * `DATADIR` gets expanded to [.filename]#PREFIX/shared/PORTNAME#. * `DATADIR_REL` gets expanded to [.filename]#share/PORTNAME#. * `DOCSDIR` gets expanded to [.filename]#PREFIX/shared/doc/PORTNAME#. * `DOCSDIR_REL` gets expanded to [.filename]#share/doc/PORTNAME#. * `EXAMPLESDIR` gets expanded to [.filename]#PREFIX/shared/examples/PORTNAME#. * `EXAMPLESDIR_REL` gets expanded to [.filename]#share/examples/PORTNAME#. [NOTE] ==== The `DOCS` option only controls additional documentation installed in `DOCSDIR`. It does not apply to standard man pages and info pages. Things installed in `EXAMPLESDIR` are controlled by the `EXAMPLES` option. ==== These variables are exported to `PLIST_SUB`. Their values will appear there as pathnames relative to [.filename]#PREFIX# if possible. That is, [.filename]#share/doc/PORTNAME# will be substituted for `%%DOCSDIR%%` in the packing list by default, and so on. (See more on [.filename]#pkg-plist# substitution <>.) All conditionally installed documentation files and directories are included in [.filename]#pkg-plist# with the `%%PORTDOCS%%` prefix, for example: [.programlisting] .... %%PORTDOCS%%%%DOCSDIR%%/AUTHORS %%PORTDOCS%%%%DOCSDIR%%/CONTACT .... As an alternative to enumerating the documentation files in [.filename]#pkg-plist#, a port can set the variable `PORTDOCS` to a list of file names and shell glob patterns to add to the final packing list. The names will be relative to `DOCSDIR`. Therefore, a port that utilizes `PORTDOCS`, and uses a non-default location for its documentation, must set `DOCSDIR` accordingly. If a directory is listed in `PORTDOCS` or matched by a glob pattern from this variable, the entire subtree of contained files and directories will be registered in the final packing list. If the `DOCS` option has been unset then files and directories listed in `PORTDOCS` would not be installed or added to port packing list. Installing the documentation at `PORTDOCS` as shown above remains up to the port itself. A typical example of utilizing `PORTDOCS`: [.programlisting] .... PORTDOCS= README.* ChangeLog docs/* .... [NOTE] ==== The equivalents of `PORTDOCS` for files installed under `DATADIR` and `EXAMPLESDIR` are `PORTDATA` and `PORTEXAMPLES`, respectively. The contents of [.filename]#pkg-message# are displayed upon installation. See <> for details. [.filename]#pkg-message# does not need to be added to [.filename]#pkg-plist#. ==== [[install-subdirs]] === Subdirectories Under `PREFIX` Try to let the port put things in the right subdirectories of `PREFIX`. Some ports lump everything and put it in the subdirectory with the port's name, which is incorrect. Also, many ports put everything except binaries, header files and manual pages in a subdirectory of [.filename]#lib#, which does not work well with the BSD paradigm. Many of the files must be moved to one of these directories: [.filename]#etc# (setup/configuration files), [.filename]#libexec# (executables started internally), [.filename]#sbin# (executables for superusers/managers), [.filename]#info# (documentation for info browser) or [.filename]#share# (architecture independent files). See man:hier[7] for details; the rules governing [.filename]#/usr# pretty much apply to [.filename]#/usr/local# too. The exception are ports dealing with USENET "news". They may use [.filename]#PREFIX/news# as a destination for their files. [[binary-alias]] == Use `BINARY_ALIAS` to Rename Commands Instead of Patching the Build When `BINARY_ALIAS` is defined it will create symlinks of the given commands in a directory which will be prepended to `PATH`. Use it to substitute hardcoded commands the build phase relies on without having to patch any build files. [[binary-alias-ex1]] .Using `BINARY_ALIAS` to Make `gsed` Available as `sed` [example] ==== Some ports expect `sed` to behave like GNU sed and use features that man:sed[1] does not provide. GNU sed is available from package:textproc/gsed[] on FreeBSD. Use `BINARY_ALIAS` to substitute `sed` with `gsed` for the duration of the build: [.programlisting] .... BUILD_DEPENDS= gsed:textproc/gsed ... BINARY_ALIAS= sed=gsed .... ==== [[binary-alias-ex2]] .Using `BINARY_ALIAS` to Provide Aliases for Hardcoded `python3` Commands [example] ==== A port that has a hardcoded reference to `python3` in its build scripts will need to have it available in `PATH` at build time. Use `BINARY_ALIAS` to create an alias that points to the right Python 3 binary: [.programlisting] .... USES= python:3.4+,build ... BINARY_ALIAS= python3=${PYTHON_CMD} .... See <> for more information about `USES=python`. ====