FreeBSD Developers' Handbook
Zurück | Kapitel 5. Vorgaben und Richtlinien für das Quelltextverzeichnis | Weiter

# 5.2. Beigesteuerte Software

Beigesteuert von Poul-Henning Kamp und David O'Brien.

Einige Teile der FreeBSD-Distribution enthalten Software, die aktiv außerhalb des FreeBSD-Projektes gepflegt wird. Aus historischen Gründen nennen wir dies contributed Software. Beispiele dafür sind sendmail, gcc und patch.

Über die Jahre wurden verschiedene Methoden genutzt, um solche Software zu verwalten, und jede hat Vor- wie auch Nachteile. So hat sich kein eindeutiger Gewinner herauskristallisiert.

Es wurde viel über diesen Umstand diskutiert und eine Methode als die “offizielle” vorgestellt, um in Zukunft diese Art der Software zu importieren. Ferner wird dringend geraten, dass sich existierende, beigesteuerte Software diesem Modell annähert, da es signifikante Vorteile gegenüber der alten Methode gibt. Dazu gehört auch, dass jeder einfach Diffs bezüglich der “offiziellen” Quelltext-Versionen erzeugen kann (auch ohne CVS-Zugang). Dies wird es deutlich vereinfachen, Änderungen an die Hauptentwickler zurückfließen zu lassen.

Letztendlich kommt es jedoch auf die Menschen an, welche die Arbeit leisten. Wenn die Durchführung dieses Modells bei einem Paket mal nicht möglich ist, können Ausnahmen dieser Regeln nur mit Genehmigung des Core-Teams und der Übereinstimmung der anderen Entwickler gewährt werden. Die Fähigkeit, dieses Paket auch in Zukunft pflegen zu können, ist eine der Schlüsselfragen bei dieser Entscheidung.

> Anmerkung: Durch einige bedauernswerte Einschränkungen des RCS-Dateiformats und die Handhabung von Herstellerzweigen im CVS ist von unwesentlichen, trivialen und/oder kosmetischen Änderungen an Dateien dringend abzuraten, die dem Herstellerzweig folgen. “Grammatikalische oder sprachliche Fehlerbehebungen” sind explizit unter der “Kosmetik”-Kategorie einzuordnen und sollten bei Dateien mit einer 1.1.x.x-Revision vermieden werden. Das Repository kann sich durch Änderungen einzelner Zeichen dramatisch aufblähen.

Die eingebettete Tcl-Programmiersprache soll als Beispiel dienen, wie dieses Modell funktioniert:

`src/contrib/tcl` enthält den Quelltext so, wie vom Maintainer dieses Pakets bereitgestellt. Teile, die unter FreeBSD gänzlich unnutzbar sind, können entfernt werden. Im Fall von Tcl wurden die Unterverzeichnisse `mac`, `win` und `compat` vor dem Import entfernt.

`src/lib/libtcl` enthält ein `Makefile` im bmake-Stil, das die Regeln des Standard-Makefiles `bsd.lib.mk` nutzt, um die Bibliothek zu erstellen und die Dokumentation zu installieren.

`src/usr.bin/tclsh` enthält ein `Makefile` im bmake-Stil, welches das `tclsh`-Programm erstellt und installiert, ebenso die dazugehörigen Manualpages, welche die Regeln von `bsd.prog.mk` nutzen.

`src/tools/tools/tcl_bmake` enthält einige Shell-Skripten, die hilfreich sein können, wenn die Tcl-Software aktualisiert werden soll. Diese sind nicht Teil des Erstellens und der Installation der Software.

Das Entscheidende ist hier das `src/contrib/tcl`-Verzeichnis, welches nach den folgenden Regeln erstellt wird: Es muss den Quelltext aus dem Original enthalten (ohne RCS-Schlüsselworte und im korrekten CVS-Herstellerzweig) mit so wenig FreeBSD-spezifischen Änderungen wie möglich. Sollte es Zweifel geben, wie hier zu verfahren ist, unbedingt zuerst nachfragen und nicht auf gut Glück etwas probieren in der vagen Hoffnung, dass es “irgendwie tut”. CVS verzeiht keine Fehler beim Importieren und ein hoher Arbeitsaufwand wäre die Folge, um diesen großen Fehler wieder wettzumachen.

Aufgrund der eingangs schon erwähnten Einschränkungen bei CVS-Herstellerzweigen ist es erforderlich, dass “offizielle” Fehlerbehebungen vom Hersteller in die Originalquellen der Distribution einfließen und als Resultat wieder in den Herstellerzweig importiert werden. Offizielle Fehlerbehebungen sollten nie direkt in FreeBSD eingepflegt und “committet” werden, da dies den Herstellerzweig zerstören würde und der Import von zukünftigen Versionen wäre um ein Vielfaches schwerer, da es zu Konflikten kommen würde.

Da einige Pakete Dateien enthalten, die zur Kompatibilität mit anderen Architekturen und Umgebungen als FreeBSD gedacht sind, ist es zulässig, diese Teile zu löschen, wenn sie für FreeBSD nicht von Interesse sind, und so Speicherplatz zu sparen. Dateien, die ein Copyright und Release-artige Informationen zu den vorhandenen Dateien enthalten, sollten nicht gelöscht werden.

Falls es einfacher erscheint, können die `bmake`-`Makefile`s vom Verzeichnisbaum durch einige Dienstprogramme automatisch erstellt werden, was es hoffentlich sogar noch einfacher macht, eine Version zu aktualisieren. Ist dies geschehen, so stellen Sie bitte sicher, diese Werkzeuge in das Verzeichnis `src/tools` gleich mit dem Port an sich einzuchecken, sodass es für zukünftige Maintainer verfügbar ist.

Im Verzeichnis `src/contrib/tcl` sollte eine Datei mit dem Namen `FREEBSD-upgrade` hinzugefügt werden und sie sollte den Stand wie folgt anzeigen:

- Welche Dateien ausgelassen wurden.

- Von wo die Original-Distribution stammt und/oder wo die offizielle Hauptseite zu finden ist.

- Wohin Fehlerbehebungen an den Originalautor gesendet werden können.

- Möglicherweise eine Übersicht, welche FreeBSD-spezifischen Änderungen vorgenommen wurden.

Importieren Sie jedoch `FREEBSD-upgrade` nicht mit den beigesteuerten Quelldateien. Stattdessen sollten Sie `cvs add FREEBSD-upgrade ; cvs ci` nach dem initialen Import nutzen. Ein Beispiel von `src/contrib/cpio` sehen Sie hier:

    This directory contains virgin sources of the original distribution files
    on a "vendor" branch.  Do not, under any circumstances, attempt to upgrade
    the files in this directory via patches and a cvs commit.  New versions or
    official-patch versions must be imported.  Please remember to import with
    "-ko" to prevent CVS from corrupting any vendor RCS Ids.

    For the import of GNU cpio 2.4.2, the following files were removed:

            INSTALL         cpio.info       mkdir.c
            Makefile.in     cpio.texi       mkinstalldirs

    To upgrade to a newer version of cpio, when it is available:
            1. Unpack the new version into an empty directory.
               [Do not make ANY changes to the files.]

            2. Remove the files listed above and any others that don't apply to
               FreeBSD.

            3. Use the command:
                    cvs import -ko -m 'Virgin import of GNU cpio v<version>' \
                            src/contrib/cpio GNU cpio_<version>

               For example, to do the import of version 2.4.2, I typed:
                    cvs import -ko -m 'Virgin import of GNU v2.4.2' \
                            src/contrib/cpio GNU cpio_2_4_2

            4. Follow the instructions printed out in step 3 to resolve any
               conflicts between local FreeBSD changes and the newer version.

    Do not, under any circumstances, deviate from this procedure.

    To make local changes to cpio, simply patch and commit to the main
    branch (aka HEAD).  Never make local changes on the GNU branch.

    All local changes should be submitted to "cpio@gnu.ai.mit.edu" for
    inclusion in the next vendor release.

    obrien@FreeBSD.org - 30 March 1997

Zurück | Zum Anfang | Weiter
Vorgaben und Richtlinien für das Quelltextverzeichnis | Nach oben | Belastende Dateien

Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an <de-bsd-questions@de.FreeBSD.org>.
Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an <de-bsd-translators@de.FreeBSD.org>.