<!--
The FreeBSD Documentation Project
The FreeBSD German Documentation Project
$FreeBSD$
$FreeBSDde: de-docproj/books/developers-handbook/policies/chapter.sgml,v 1.9 2010/01/18 19:11:52 bcr Exp $
basiert auf: 1.34
-->
<chapter id="policies">
<chapterinfo>
<authorgroup>
<author>
<firstname>Poul-Henning</firstname>
<surname>Kamp</surname>
<contrib>Beigesteuert von </contrib>
</author>
</authorgroup>
<!-- June 1996 -->
<authorgroup>
<author>
<firstname>Axel</firstname>
<surname>Gruner</surname>
<contrib>Übersetzt von </contrib>
</author>
</authorgroup>
</chapterinfo>
<title>Vorgaben und Richtlinien für das
Quelltextverzeichnis</title>
<para>Dieses Kapitel dokumentiert verschiedene Vorgaben und
Richtlinien für das FreeBSD-Quelltextverzeichnis.</para>
<sect1 id="policies-maintainer">
<title><makevar>MAINTAINER</makevar> eines Makefiles</title>
<indexterm><primary>Ports-Maintainer</primary></indexterm>
<para>Wenn ein bestimmter Bereich der FreeBSD-Distribution von
einer Person oder Gruppe gepflegt wird, kann dies durch
Hinzufügen der Zeile
<programlisting>MAINTAINER= email-addresses</programlisting>
im <filename>Makefile</filename> der Öffentlichkeit
mitgeteilt werden.</para>
<para>Dies bedeutet folgendes:</para>
<para>Der Maintainer ist verantwortlich für diesen Code.
Er muss einerseits für die Behebung von
Fehlern und das Beantworten von Problemberichten für diesen
Code die Verantwortung tragen und andererseits, falls es sich
um beigesteuerte Software handelt, neue Versionen verfolgen
und bereitstellen.</para>
<para>Änderungen an Verzeichnissen, die ein Maintainer
definiert hat, sollten an den Maintainer für eine
Überprüfung gesendet werden, bevor diese committet
werden. Nur wenn der Maintainer in einer inakzeptablen
Zeitspanne auf mehrere E-Mails nicht antwortet, können die
Änderungen, die mit dem Commit in Kraft treten, auch ohne
Überprüfung durch den Maintainer vollzogen werden.
Dennoch wird empfohlen, dass die Änderungen, falls
möglich, von jemand anderem überprüft
werden.</para>
<para>Es ist natürlich nicht akzeptabel, einer Person oder
Gruppe den Status eines Maintainers zu geben, so lange sie nicht
zustimmt, diese Pflicht auf sich zu nehmen. Andererseits muss es
kein einzelner Mensch sein. Eine Gruppe von Menschen ist genauso
in Ordnung.</para>
</sect1>
<sect1 id="policies-contributed">
<sect1info>
<authorgroup>
<author>
<firstname>Poul-Henning</firstname>
<surname>Kamp</surname>
<contrib>Beigesteuert von </contrib>
</author>
<author>
<firstname>David</firstname>
<surname>O'Brien</surname>
</author>
</authorgroup>
<!-- June 1996 -->
</sect1info>
<title>Beigesteuerte Software</title>
<indexterm><primary>Beigesteuerte Software</primary></indexterm>
<para>Einige Teile der FreeBSD-Distribution enthalten Software,
die aktiv außerhalb des FreeBSD-Projektes gepflegt wird.
Aus historischen Gründen nennen wir dies
<emphasis>contributed</emphasis> Software. Beispiele dafür
sind <application>sendmail</application>,
<application>gcc</application> und
<application>patch</application>.</para>
<para>Ü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.</para>
<para>Es wurde viel über diesen Umstand diskutiert und
eine Methode als die <quote>offizielle</quote>
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
<quote>offiziellen</quote> Quelltext-Versionen erzeugen kann
(auch ohne CVS-Zugang). Dies wird es deutlich vereinfachen,
Änderungen an die Hauptentwickler zurückfließen zu
lassen.</para>
<para>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.</para>
<note>
<para>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 <emphasis>dringend
abzuraten</emphasis>, die dem Herstellerzweig folgen.
<quote>Grammatikalische oder sprachliche
Fehlerbehebungen</quote> sind explizit unter der
<quote>Kosmetik</quote>-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.</para>
</note>
<para>Die eingebettete
<application>Tcl</application>-Programmiersprache soll als
Beispiel dienen, wie dieses Modell funktioniert:</para>
<para><filename>src/contrib/tcl</filename> 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 <filename>mac</filename>,
<filename>win</filename> und <filename>compat</filename>
vor dem Import entfernt.</para>
<para><filename>src/lib/libtcl</filename> enthält ein
<filename>Makefile</filename> im
<application>bmake</application>-Stil, das die Regeln des
Standard-Makefiles <filename>bsd.lib.mk</filename> nutzt, um
die Bibliothek zu erstellen und die Dokumentation zu
installieren.</para>
<para><filename>src/usr.bin/tclsh</filename> enthält ein
<filename>Makefile</filename> im
<application>bmake</application>-Stil, welches das
<command>tclsh</command>-Programm erstellt und installiert,
ebenso die dazugehörigen Manualpages, welche die Regeln von
<filename>bsd.prog.mk</filename> nutzen.</para>
<para><filename>src/tools/tools/tcl_bmake</filename> 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.</para>
<para>Das Entscheidende ist hier das
<filename>src/contrib/tcl</filename>-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 <quote>irgendwie tut</quote>. CVS verzeiht
keine Fehler beim Importieren und ein hoher Arbeitsaufwand
wäre die Folge, um diesen großen Fehler wieder
wettzumachen.</para>
<para>Aufgrund der eingangs schon erwähnten Einschränkungen
bei CVS-Herstellerzweigen ist es erforderlich,
dass <quote>offizielle</quote> 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 <quote>committet</quote> 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.</para>
<para>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 <emphasis>nicht</emphasis>
gelöscht werden.</para>
<para>Falls es einfacher erscheint, können die
<command>bmake</command>-<filename>Makefile</filename>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
<filename>src/tools</filename> gleich mit dem Port an sich
einzuchecken, sodass es für zukünftige Maintainer
verfügbar ist.</para>
<para>Im Verzeichnis <filename>src/contrib/tcl</filename> sollte
eine Datei mit dem Namen <filename>FREEBSD-upgrade</filename>
hinzugefügt werden und sie sollte den Stand wie folgt
anzeigen:</para>
<itemizedlist>
<listitem>
<para>Welche Dateien ausgelassen wurden.</para>
</listitem>
<listitem>
<para>Von wo die Original-Distribution stammt und/oder wo die
offizielle Hauptseite zu finden ist.</para>
</listitem>
<listitem>
<para>Wohin Fehlerbehebungen an den Originalautor gesendet
werden können.</para>
</listitem>
<listitem>
<para>Möglicherweise eine Übersicht, welche
FreeBSD-spezifischen Änderungen vorgenommen
wurden.</para>
</listitem>
</itemizedlist>
<para>Importieren Sie jedoch <filename>FREEBSD-upgrade</filename>
nicht mit den beigesteuerten Quelldateien. Stattdessen sollten
Sie <command>cvs add FREEBSD-upgrade ; cvs ci</command> nach
dem initialen Import nutzen. Ein Beispiel von
<filename>src/contrib/cpio</filename> sehen Sie hier:</para>
<programlisting>
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</programlisting>
</sect1>
<sect1 id="policies-encumbered">
<title>Belastende Dateien</title>
<para>Es kann gelegentlich notwendig sein, belastende Dateien
in den FreeBSD-Quelltextbaum zu integrieren. Braucht ein
Gerät zum Beispiel ein Stück binären Code, der
zuerst geladen werden muss, bevor das Gerät funktioniert,
und wir haben keine Quellen zu diesem Code, dann wird die
binäre Datei als belastend bezeichnet. Die folgenden
Richtlinien sind beim Aufnehmen von belastenden Dateien in den
FreeBSD-Quelltextbaum zu beachten.</para>
<orderedlist>
<listitem>
<para>Jede Datei, die durch die System-CPU(s) ausgeführt
wird und nicht als Quelltext vorliegt, ist belastend.</para>
</listitem>
<listitem>
<para>Jede Datei, deren Lizenz restriktiver ist als die BSD-
oder GNU-Lizenz, ist belastend.</para>
</listitem>
<listitem>
<para>Eine Datei, die herunterladbare Binär-Daten
enthält, ist nur belastend, wenn (1) oder (2)
zutreffen. Sie muss in einem ASCII-Format
gespeichert werden, das Architektur-neutral ist (file2c
oder uuencoding wird empfohlen).</para>
</listitem>
<listitem>
<para>Jede belastende Datei braucht eine spezielle
Genehmigung vom <ulink
url="&url.base;/administration.html#t-core">Core-Team</ulink>,
bevor diese in das CVS-Repository aufgenommen
werden darf.</para>
</listitem>
<listitem>
<para>Belastende Dateien liegen unter
<filename>src/contrib</filename> oder
<filename>src/sys/contrib</filename>.</para>
</listitem>
<listitem>
<para>Das komplette Modul sollte auch am Stück
aufbewahrt werden. Es gibt keinen Grund, dieses zu teilen,
außer es gibt einen Code-Austausch mit Quelltext, der
nicht belastend ist.</para>
</listitem>
<listitem>
<para>Objekt-Dateien werden wie folgt benannt:
<filename><replaceable>arch</replaceable>/<replaceable>filename</replaceable>.o.uu></filename>.</para>
</listitem>
<listitem>
<para>Kernel-Dateien:</para>
<orderedlist>
<listitem>
<para>Sollten immer nach
<filename>conf/files.*</filename> verweisen (um den Bau
einfach zu halten).</para>
</listitem>
<listitem>
<para>Sollten sich immer in <filename>LINT</filename>
befinden, jedoch entscheidet das <ulink
url="&url.base;/administration.html#t-core">Core-Team</ulink>
je nach Fall, ob es
auskommentiert wird oder nicht. Das <ulink
url="&url.base;/administration.html#t-core">Core-Team</ulink>
kann sich zu einem späteren Zeitpunkt
immer noch anders entscheiden.</para>
</listitem>
<listitem>
<para>Der <firstterm>Release-Engineer</firstterm>
entscheidet, ob es in ein Release aufgenommen wird oder
nicht.</para>
</listitem>
</orderedlist>
</listitem>
<listitem>
<para>Userland-Dateien:</para>
<orderedlist>
<listitem>
<indexterm><primary>Core-Team</primary></indexterm>
<para>Das <ulink
url="&url.base;/administration.html#t-core">Core-Team</ulink>
entscheidet, ob der Code von
<command>make world</command> gebaut wird oder nicht.</para>
</listitem>
<listitem>
<indexterm><primary>Release-Engineer</primary></indexterm>
<para>Der <ulink
url="&url.base;/administration.html#t-re">Release-Engineer</ulink>
entscheidet, ob es in das Release
aufgenommen wird oder nicht.</para>
</listitem>
</orderedlist>
</listitem>
</orderedlist>
</sect1>
<sect1 id="policies-shlib">
<sect1info>
<authorgroup>
<author>
<firstname>Satoshi</firstname>
<surname>Asami</surname>
<contrib>Beigesteuert von </contrib>
</author>
<author>
<firstname>Peter</firstname>
<surname>Wemm</surname>
</author>
<author>
<firstname>David</firstname>
<surname>O'Brien</surname>
</author>
</authorgroup>
<!-- 9 Dec 1996 -->
</sect1info>
<title>Shared-Libraries</title>
<para>Sollten Sie die Unterstützung für
Shared-Libraries bei einem Port oder einem Stück Software,
das dies nicht hat, hinzufügen, sollten die Versionsnummern
dessen Regeln folgen. Im Allgemeinen hat die sich daraus
resultierende Nummer nichts mit der Release-Version der Software
zu tun.</para>
<para>Die drei Grundsätze zum Erstellen von Shared-Libraries
sind:</para>
<itemizedlist>
<listitem>
<para>Sie beginnen mit <literal>1.0</literal>.</para>
</listitem>
<listitem>
<para>Gibt es eine Änderung, die
abwärtskompatibel ist, so springen Sie zur
nächsten Minor-Version (beachten Sie, dass ELF-Systeme
die Minor-Version ignorieren).</para>
</listitem>
<listitem>
<para>Gibt es eine inkompatible Änderung, so springen
Sie bitte zur nächsten Major-Version.</para>
</listitem>
</itemizedlist>
<para>Zum Beispiel wird beim Hinzufügen von Funktionen und
oder Fehlerbehebungen zur nächsten Minor-Version
gesprungen, beim Löschen einer Funktion, Ändern
von Funktionsaufrufen usw. ändert sich die Major-Version.</para>
<para>Bleiben Sie bei Versionsnummern in der Form major.minor
(<replaceable>x</replaceable>.<replaceable>y</replaceable>).
Unser dynamischer Linker a.out kann mit Versionsnummern
in der Form
<replaceable>x</replaceable>.<replaceable>y</replaceable>.<replaceable>z</replaceable>
nicht gut umgehen.
Jede Versionsnummer nach dem <replaceable>y</replaceable>
(die dritte Zahl) wird völlig ignoriert, wenn
Versionsnummern der Shared-Libraries verglichen werden, um
zu bestimmen, mit welcher Bibliothek eine Anwendung verlinkt wird.
Sind zwei Shared-Libraries vorhanden, die sich nur in der
<quote>micro</quote>-Revision unterscheiden, so wird
<command>ld.so</command> zu der höheren verlinken.
Dies bedeutet, dass wenn Sie mit <filename>libfoo.so.3.3.3</filename>
verlinken, der Linker nur <literal>3.3</literal> in den
Header aufnimmt und alles linkt, was mit
<replaceable>libfoo.so.3</replaceable>
.<replaceable>(irgendetwas
>= 3)</replaceable>.<replaceable>(höchste
verfügbare Nummer)</replaceable> beginnt.</para>
<note>
<para><command>ld.so</command> wird immer die höchste
<quote>Minor</quote>-Revision benutzen. Beispielsweise wird
es die <filename>libc.so.2.2</filename> bevorzugen
gegenüber der <filename>libc.so.2.0</filename>, auch
dann, wenn das Programm ursprünglich mit
<filename>libc.so.2.0</filename> verlinkt war.</para>
</note>
<para>Unser dynamischer ELF-Linker kann keine Minor-Versionen
handhaben. Dennoch sollten die Major- und Minor-Versionen genutzt
werden, da unsere <filename>Makefile</filename>s <quote>das
Richtige machen</quote> bezogen auf den Systemtyp.</para>
<para>Für nicht-Port-Bibliotheken lautet die Richtlinie,
die Shared-Library-Versionsnummer nur einmal zwischen den
Releases zu ändern. Weiterhin ist es vorgeschrieben, die
Major-Version der Shared-Libraries nur bei Major-OS-Releases zu
ändern (beispielsweise von 3.0 auf 4.0). Wenn Sie also eine
Änderung an einer Systembibliothek vornehmen, die eine neue
Versionsnummer benötigt, überprüfen Sie die
Commit-Logs des <filename>Makefile</filename>s. Es liegt in der
Verantwortung des Committers, dass sich eine erste solche
Änderung seit dem letzten Release in der aktualisierten
Versionsnummer der Shared-Library im
<filename>Makefile</filename> äußert, folgende
Änderungen werden nicht berücksichtigt.</para>
</sect1>
</chapter>
<!--
Local Variables:
mode: sgml
sgml-declaration: "../chapter.decl"
sgml-indent-data: t
sgml-omittag: nil
sgml-always-quote-attributes: t
sgml-parent-document: ("../book.sgml" "part" "chapter")
End:
-->