b2bd8eb00c
Thanks to the efforts of Frank Börner, we were able to update multiple documents to the current version. books/developers-handbook/policies/chapter.sgml 1.33 -> 1.34 [1] books/handbook/book.sgml 1.175 -> 1.176 [1] books/handbook/cutting-edge/chapter.sgml 1.245 -> 1.246 books/handbook/kernelconfig/chapter.sgml 1.193 -> 1.194 books/handbook/ports/chapter.sgml 1.278 -> 1.290 [1] books/handbook/x11/chapter.sgml 1.186 -> 1.201 flyer/flyer.tex 1.16 -> 1.17 [1] share/sgml/trademarks.sgml 1.6 -> 1.7 [1] [1] Contributed by: Frank Börner (frank dash freebsd at online dot de) Obtained from: The FreeBSD German Documentation Project
522 lines
20 KiB
Text
522 lines
20 KiB
Text
<!--
|
|
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:
|
|
-->
|