From fd52afda2a0cd9345a4ef693e0cd91e55b5d7915 Mon Sep 17 00:00:00 2001
From: Masafumi Max NAKANE <max@FreeBSD.org>
Date: Mon, 16 Dec 1996 14:02:55 +0000
Subject: [PATCH] Merge the en version changes (1.5 -> 1.8).

Use the same punctuation characters as other files do.

Submitted by:	mihoko@pa.yokogawa.co.jp
	Japanese Documentation Project.
---
 ja/handbook/policies.sgml        | 245 +++++++++++++++++++------------
 ja_JP.EUC/handbook/policies.sgml | 245 +++++++++++++++++++------------
 2 files changed, 298 insertions(+), 192 deletions(-)

diff --git a/ja/handbook/policies.sgml b/ja/handbook/policies.sgml
index 031f54fccb..4790464353 100644
--- a/ja/handbook/policies.sgml
+++ b/ja/handbook/policies.sgml
@@ -1,6 +1,6 @@
-<!-- $Id: policies.sgml,v 1.1.1.1 1996-11-15 05:14:44 asami Exp $ -->
+<!-- $Id: policies.sgml,v 1.2 1996-12-16 14:02:55 max Exp $ -->
 <!-- The FreeBSD Japanese Documentation Project -->
-<!-- Original revision: 1.5 -->
+<!-- Original revision: 1.8 -->
 
 <chapt><heading>ソースツリーのガイドラインおよび方針
 <label id="policies">
@@ -10,143 +10,196 @@
 <p><em>訳者: &a.mihoko;<newline>
 6 September 1996 </em>.
 
-本章は、FreeBSD のソースツリーについてのさまざまなガイドラインやポリ
-シーについて書かれています。
+本章は, FreeBSD のソースツリーについてのさまざまなガイドラインや
+ポリシーについて書かれています. 
 
 <sect><heading>Makefile 中の MAINTAINER
 <label id="policies:maintainer">
 </heading>
 
-<p>1996年6月。
+<p>1996年6月. 
 
-<p>FreeBSD 配布物の特定の部分が、一人の人やグループによって保守
-されている場合は、ソースツリーの当該 Makefile に
+<p>FreeBSD 配布物の特定の部分が, 一人の人やグループによって保守
+されている場合は, ソースツリーの当該 Makefile に
 
 <verb>
 	MAINTAINER= email-addresses
 </verb>
 
-<p>が付け加えられています。これを記述することによって、この部分が誰
-に保守管理されているかを世界中のユーザに伝えることができます。 
+<p>が付け加えられています. これを記述することによって, この部分が誰
+に保守管理されているかを世界中のユーザに伝えることができます.  
 
 <p>この意味は次のとおりです:
 
-<p>保守担当者がそのコードを所有し、そのコードに対する責任を持っ
-ています。すなわち、その人がそのコードに関するバグ吸収やトラブル報告
-に対する回答をします。また、そのコードが寄贈ソフトウェアの場合には、
-そのソフトウェアの新しいバージョンに適切に追従していきます。 
+<p>保守担当者がそのコードを所有し, そのコードに対する責任を持っ
+ています. すなわち, その人がそのコードに関するバグ吸収やトラブル報告
+に対する回答をします. また, そのコードが寄贈ソフトウェアの場合には, 
+そのソフトウェアの新しいバージョンに適切に追従していきます.  
 
-<p>保守担当者が決められているディレクトリに対して変更をおこなう場合は、
-変更をおこなう前に、その変更内容を保守担当者に送って、
-保守担当者にレビューをしてもらってください。
-保守担当者が、電子メールに一定期間応答しない場合にのみ、
-保守担当者がレビューすることなしに、変更をおこなうことが認められます。
-しかしながら、そのような場合でも可能な限り、変更点を第三者にレビュー
-してもらうようにしてください。
+<p>保守担当者が決められているディレクトリに対して変更をおこなう場合は, 
+変更をおこなう前に, その変更内容を保守担当者に送って, 
+保守担当者にレビューをしてもらってください. 
+保守担当者が, 電子メールに一定期間応答しない場合にのみ, 
+保守担当者がレビューすることなしに, 変更をおこなうことが認められます. 
+しかしながら, そのような場合でも可能な限り, 変更点を第三者にレビュー
+してもらうようにしてください. 
 
-<p>もちろん、この義務を引き受けることができない人やグループを保守管
-理者として追加することはできません。
-また、保守管理者がソースツリー管理者 ("committer") である必要は
-ありません。
+<p>もちろん, この義務を引き受けることができない人やグループを
+保守管理者として追加することはできません. 
+また, 保守管理者がソースツリー管理者 ("committer") である必要は
+ありません. 
 
 <sect><heading>寄贈ソフトウェア</heading>
 
-<p>1996年6月。
+<p>1996年6月. 
 
 <p>FreeBSD 配布物のうちのいくつかのソフトウェアは FreeBSD プロジェクト
-以外のところで保守されています。
-歴史的な経緯から、私たちはこれを <em> 寄贈 </em> ソフトウェアと呼
-んでいます。perl や gcc, patch などがその例です。
+以外のところで保守されています. 
+歴史的な経緯から, 私たちはこれを <em> 寄贈 </em> ソフトウェアと
+呼んでいます. perl や gcc, patch などがその例です. 
 
-<p>ここ数年来、この種のソフトウェアの取り扱いには、さまざまな方法が取ら
-れてきましたが、どの方法にもいくつかの利点と欠点があります。
-これまで欠点のない明確な方法はありませんでした。
+<p>ここ数年来, この種のソフトウェアの取り扱いには, さまざまな方法が
+取られてきましたが, どの方法にもいくつかの利点と欠点があります. 
+これまで欠点のない明確な方法はありませんでした. 
 
 <p>
-議論した結果、これらの方法のうちの一つが「公式な」方法として選択され
-ました。その方法が、今後、この種のソフトウェアを取り込む場合に、使用
-されます。
-その上、この方法では、だれもが(cvs にアクセス権のない人でさえ)「公式」
-バージョンのソースに対する差分を簡単に得ることができます。
-これは古い方法にはなかった大きな利点です。ですから、
-既存の寄贈ソフトウェアも、この方法に収束していくことを強く望んでいます。
-この方法を使用することにより、寄贈ソフトウェアの主な開発者に、変更
-点を返すのがとても容易になります。
+議論した結果, これらの方法のうちの一つが「公式な」方法として選択され
+ました. その方法が, 今後, この種のソフトウェアを取り込む場合に, 使用
+されます. 
+その上, この方法では, だれもが(cvs にアクセス権のない人でさえ)「公式」
+バージョンのソースに対する差分を簡単に得ることができます. 
+これは古い方法にはなかった大きな利点です. ですから, 
+既存の寄贈ソフトウェアも, この方法に収束していくことを強く望んでいます. 
+この方法を使用することにより, 寄贈ソフトウェアの主な開発者に, 変更
+点を返すのがとても容易になります. 
 
-<p>しかしながら結局、寄贈ソフトウェアの取扱は、実際に作業を行って
-いる人々に委ねられています。
-もしこの方法を使用することが、その人が扱っているパッケージには
-極端に合わないような場合には、コアチームの承認さえあれば、これらの
-ルールに反しても、他の開発者の一般的な合意は得られるでしょう。
-将来にわたってパッケージを保守できるということは、大変重要な事柄に
-なってきます。
+<p>しかしながら結局, 寄贈ソフトウェアの取扱は, 実際に作業を行って
+いる人々に委ねられています. 
+もしこの方法を使用することが, その人が扱っているパッケージには
+極端に合わないような場合には, コアチームの承認さえあれば, これらの
+ルールに反しても, 他の開発者の一般的な合意は得られるでしょう. 
+将来にわたってパッケージを保守できるということは, 大変重要な事柄に
+なってきます. 
 
-<p>プログラミング言語 <tt>Tcl</tt> は、
+<p>プログラミング言語 <tt>Tcl</tt> は, 
 この方法が活用されているよい例になっています:
 
-<p><verb>src/contrib/tcl</verb> には、このパッケージの保守管理者が
-配布したソースが含まれています。この中からは FreeBSD に完全には適用
-できない部分が削除されています。Tcl の場合は、"mac"、 "win"、
-"compat" というサブディレクトリは、FreeBSD に取り込む前に削除されて
-いました。 
+<p><verb>src/contrib/tcl</verb> には, このパッケージの保守管理者が
+配布したソースが含まれています. この中からは FreeBSD に完全には適用
+できない部分が削除されています. Tcl の場合は, "mac",  "win", 
+"compat" というサブディレクトリは, FreeBSD に取り込む前に削除されて
+いました.  
 
-<p><verb>src/lib/libtcl</verb> には、ライブラリを生成したり、ドキュ
-メントをインストールする際に使用される、標準の bsd.lib.mk の
-規則を使用した「bmake スタイル」の Makefile だけが 含まれています。
+<p><verb>src/lib/libtcl</verb> には, ライブラリを生成したり, ドキュ
+メントをインストールする際に使用される, 標準の bsd.lib.mk の
+規則を使用した「bmake スタイル」の Makefile だけが 含まれています. 
 
-<p><verb>src/usr.bin/tclsh</verb> には、bsd.prog.mk 規則 を使用して、
+<p><verb>src/usr.bin/tclsh</verb> には, bsd.prog.mk 規則 を使用して, 
 "tclsh" プログラムや関連するマニュアルページを生成 /インストール
-する bmake スタイルの Makefile だけが含まれています。
+する bmake スタイルの Makefile だけが含まれています. 
 
-<p><verb>src/tools/tools/tcl_bmake</verb> には、
+<p><verb>src/tools/tools/tcl_bmake</verb> には, 
 tcl ソフトウェアを更新する必要が生じたときの助けになる2つのシェルス
-クリプトが含まれています。これらは、ソフトウェアを構築するのに使用し
-たり、インストール対象になるソフトウェアではありません。
+クリプトが含まれています. これらは, ソフトウェアを構築するのに使用し
+たり, インストール対象になるソフトウェアではありません. 
 
-<p>ここ重要なのは、"src/contrib/tcl" ディレクトリが、規則にしたがっ
-て作られているということです。つまり、できるだけ FreeBSD に特化した
+<p>ここ重要なのは, "src/contrib/tcl" ディレクトリが, 規則にしたがっ
+て作られているということです. つまり, できるだけ FreeBSD に特化した
 変更をおこなわないようにしたソースを(CVS のベンダブランチに)おくようにし
-ています。   
-freefall 上の「簡易取り込み」ツールは、寄贈ソフトウェアを取り込む手助
-けとなります。けれども、このツールの実行方法に疑問が生じた場合は、ま
-ずはじめに質問して、失敗をしないようにしてください。そして、
-その疑問を「解決して」からツールを使用してください。
-CVS に寄贈ソフトウェアを取り込む際には、事故があってはいけません。
-よくあるような間違いをおかさないように、十分注意してください。
+ています.    
+freefall 上の「簡易取り込み」ツールは, 寄贈ソフトウェアを取り込む
+手助けとなります. けれども, このツールの実行方法に疑問が生じた場合は, 
+まずはじめに質問して, 失敗をしないようにしてください. そして, 
+その疑問を「解決して」からツールを使用してください. 
+CVS に寄贈ソフトウェアを取り込む際には, 事故があってはいけません. 
+よくあるような間違いをおかさないように, 十分注意してください. 
 
-<p>CVS には、残念なことにベンダブランチという設計制限があります。このた
-め、CVS に寄贈ソフトウェアを取り込むには、オリジナル配布ソースに 
-適用されるベンダからの「公式」パッチと、ベンダブランチに逆輸入された結
-果が必要です。 
-ベンダブランチの一貫性を破壊したり、将来、新しいバージョンを取り込む
+<p>CVS には, 残念なことにベンダブランチという設計制限があります.
+このため, CVS に寄贈ソフトウェアを取り込むには, オリジナル配布ソースに 
+適用されるベンダからの「公式」パッチと, ベンダブランチに逆輸入された
+結果が必要です.  
+ベンダブランチの一貫性を破壊したり, 将来, 新しいバージョンを取り込む
 時に衝突を起こしてしまったりというような 困難な事態に陥らないように
-しなければなりません。そのために、FreeBSD が管理しているバージョンに
-対して、公式パッチを決して当ててはいけませんし、公式パッチを 
-"commit" してはいけません。 
+しなければなりません. そのために, FreeBSD が管理しているバージョンに
+対して, 公式パッチを決して当ててはいけませんし, 公式パッチを 
+"commit" してはいけません.  
 
-<p>多くのパッケージが、他のアーキテクチャや他の環境と FreeBSD 
-との互換性を保ためのファイルをいくつか含んでいます。そこで、
-スペースを節約するために、FreeBSD にとっては無意味な配布ツリー上の一
-部を削除することが許されています。
-けれども、削除されずに残ったファイルに対する、著作権の通知やリリース
-ノートのような情報を含んだファイルは、決して削除しては <em> いけませ
-ん </em>。 
+<p>多くのパッケージが, 他のアーキテクチャや他の環境と FreeBSD 
+との互換性を保ためのファイルをいくつか含んでいます. そこで, 
+スペースを節約するために, FreeBSD にとっては無意味な配布ツリー上の一
+部を削除することが許されています. 
+けれども, 削除されずに残ったファイルに対する, 著作権の通知やリリース
+ノートのような情報を含んだファイルは, 決して削除しては <em> いけませ
+ん </em>.  
 
-<p>"bmake" Makefile が何らかのユーティリティによって、配布ツリーか
-ら自動的に生成できると、うまくいけば、新しいバージョンへのアップグレー
-ドをより簡単におこなうことができます。 
-もしこのようなユーティリティを作成できた場合には、将来の管理者にとっ
-て便利になるように、移植の際に、src/tools ディレクトリ上に、(必要に
-応じて)そのユーティリティを必ずチェックインしてください。
+<p>"bmake" Makefile が何らかのユーティリティによって, 配布ツリー
+から自動的に生成できると, うまくいけば, 新しいバージョンへの
+アップグレードをより簡単におこなうことができます.  
+もしこのようなユーティリティを作成できた場合には, 将来の管理者に
+とって便利になるように, 移植の際に, src/tools ディレクトリ上に, 
+(必要に応じて)そのユーティリティを必ずチェックインしてください. 
 
-<p> src/contrib/tcl レベルのディレクトリには、 README.FreeBSD と呼ば
-れるファイルが追加されており、そのファイルでは 次のような内容が
-記述されています。
+<p> src/contrib/tcl レベルのディレクトリには,  README.FreeBSD と
+呼ばれるファイルが追加されており, そのファイルでは 次のような内容が
+記述されています. 
 
 <itemize>
  <item> ディレクトリ上に存在するファイル
- <item> オリジナルの配布物をどこから入手すればよいか また、公式配布
+ <item> オリジナルの配布物をどこから入手すればよいか また, 公式配布
 サイトはどこか 
- <item> オリジナルの作者にパッチを送り返すためには、どこに送ればよいか
+ <item> オリジナルの作者にパッチを送り返すためには, どこに送ればよいか
  <item> FreeBSD に特化した変更点の概要
 </itemize>
+
+<sect><heading>共有ライブラリ
+<label id="policies:shlib">
+</heading>
+
+<p><em>Contributed by &a.asami;, &a.peter;, and &a.obrien;.
+  <newline>9 December 1996.</em></p>
+
+  <p>もしあなたが共有ライブラリをサポートする機能を port に追加した
+     り, 共有ライブラリをサポートしていない他のソフトウェアに追加する
+     場合には, 共有ライブラリのバージョン番号を次の規則にしたがって
+     つけてください.  
+     一般的には, この規則は, ソフトウェアのリリースバージョンとは
+     全く関係ありません. 
+  <p>共有ライブラリを作成する三つの重要な規則は次の通りです:
+
+  <itemize>
+    <item>1.0 から始める
+    <item>過去のバージョンに互換性のある変更の場合は, マイナー番号を増やす
+    <item>互換性のない変更の場合は, メジャー番号を増やす
+  </itemize>
+
+  <p>例えば, 機能追加とバグ吸収の場合は, マイナー番号を増やします.
+     機能削除, 関数呼び出しのシンタックスなどが変更された場合は, 
+     強制的にメジャー番号を変更します. 
+
+  <p>メジャー.マイナーー (x,y) の形式のバージョン番号を使用します. 
+     FreeBSD のダイナミックリンカは, x.y.z という形式のバージョン番号
+     は扱えません.
+     この場合, 「y」の後のバージョン番号(つまり三つ目の数字)は,
+     どのライブラリがリンクされているかを決めるために, 共有ライブラ
+     リ番号を比較する際に, すべて無視されます.
+     「小さな」リビジョンだけが異なる二つの共有ライブラリが指定
+     されると, ld.so は, リビジョンの大きい方の共有ライブラリを
+     リンクします. すなわち, もしあなたが libfoo.so.3.3.3 をリンク
+     していたとすると, リンカは頭の 3.3 という部分だけを認識し, 
+     libfoo.so.3 ではじまり その後に 3 以上の数字が続くもののうち、
+     最も大きい番号の付いているライブラリをリンクします. 
+  <p>ld.so はいつも最も大きい「マイナー」リビジョンのものを使うことに
+     注意してください. 例えば, プログラムがはじめ libc.so.2.0 を
+     リンクしていたとしても, libc.so.2.0 よりも libc.so.2.2 を優先
+     して使用します.
+
+  <p>移植されていないライブラリに対しては, リリースごとに共有ライブラリの
+     バージョン番号を一度だけ変更するのが私たちのポリシーです.
+     あなたがシステムライブラリのバージョン番号を上げた場合は,
+     Makefile の commit ログを確認してください.
+     結果としてそのリリースには, 共有ライブラリのバージョン番号が
+     アップデートされた Makefile に入るので、最初にその変更を
+     確かめるのがソースツリー管理者 ("committer") の責務です.
+     その後のどんな変更も, そのリリースには入りません.
+
+
diff --git a/ja_JP.EUC/handbook/policies.sgml b/ja_JP.EUC/handbook/policies.sgml
index 031f54fccb..4790464353 100644
--- a/ja_JP.EUC/handbook/policies.sgml
+++ b/ja_JP.EUC/handbook/policies.sgml
@@ -1,6 +1,6 @@
-<!-- $Id: policies.sgml,v 1.1.1.1 1996-11-15 05:14:44 asami Exp $ -->
+<!-- $Id: policies.sgml,v 1.2 1996-12-16 14:02:55 max Exp $ -->
 <!-- The FreeBSD Japanese Documentation Project -->
-<!-- Original revision: 1.5 -->
+<!-- Original revision: 1.8 -->
 
 <chapt><heading>ソースツリーのガイドラインおよび方針
 <label id="policies">
@@ -10,143 +10,196 @@
 <p><em>訳者: &a.mihoko;<newline>
 6 September 1996 </em>.
 
-本章は、FreeBSD のソースツリーについてのさまざまなガイドラインやポリ
-シーについて書かれています。
+本章は, FreeBSD のソースツリーについてのさまざまなガイドラインや
+ポリシーについて書かれています. 
 
 <sect><heading>Makefile 中の MAINTAINER
 <label id="policies:maintainer">
 </heading>
 
-<p>1996年6月。
+<p>1996年6月. 
 
-<p>FreeBSD 配布物の特定の部分が、一人の人やグループによって保守
-されている場合は、ソースツリーの当該 Makefile に
+<p>FreeBSD 配布物の特定の部分が, 一人の人やグループによって保守
+されている場合は, ソースツリーの当該 Makefile に
 
 <verb>
 	MAINTAINER= email-addresses
 </verb>
 
-<p>が付け加えられています。これを記述することによって、この部分が誰
-に保守管理されているかを世界中のユーザに伝えることができます。 
+<p>が付け加えられています. これを記述することによって, この部分が誰
+に保守管理されているかを世界中のユーザに伝えることができます.  
 
 <p>この意味は次のとおりです:
 
-<p>保守担当者がそのコードを所有し、そのコードに対する責任を持っ
-ています。すなわち、その人がそのコードに関するバグ吸収やトラブル報告
-に対する回答をします。また、そのコードが寄贈ソフトウェアの場合には、
-そのソフトウェアの新しいバージョンに適切に追従していきます。 
+<p>保守担当者がそのコードを所有し, そのコードに対する責任を持っ
+ています. すなわち, その人がそのコードに関するバグ吸収やトラブル報告
+に対する回答をします. また, そのコードが寄贈ソフトウェアの場合には, 
+そのソフトウェアの新しいバージョンに適切に追従していきます.  
 
-<p>保守担当者が決められているディレクトリに対して変更をおこなう場合は、
-変更をおこなう前に、その変更内容を保守担当者に送って、
-保守担当者にレビューをしてもらってください。
-保守担当者が、電子メールに一定期間応答しない場合にのみ、
-保守担当者がレビューすることなしに、変更をおこなうことが認められます。
-しかしながら、そのような場合でも可能な限り、変更点を第三者にレビュー
-してもらうようにしてください。
+<p>保守担当者が決められているディレクトリに対して変更をおこなう場合は, 
+変更をおこなう前に, その変更内容を保守担当者に送って, 
+保守担当者にレビューをしてもらってください. 
+保守担当者が, 電子メールに一定期間応答しない場合にのみ, 
+保守担当者がレビューすることなしに, 変更をおこなうことが認められます. 
+しかしながら, そのような場合でも可能な限り, 変更点を第三者にレビュー
+してもらうようにしてください. 
 
-<p>もちろん、この義務を引き受けることができない人やグループを保守管
-理者として追加することはできません。
-また、保守管理者がソースツリー管理者 ("committer") である必要は
-ありません。
+<p>もちろん, この義務を引き受けることができない人やグループを
+保守管理者として追加することはできません. 
+また, 保守管理者がソースツリー管理者 ("committer") である必要は
+ありません. 
 
 <sect><heading>寄贈ソフトウェア</heading>
 
-<p>1996年6月。
+<p>1996年6月. 
 
 <p>FreeBSD 配布物のうちのいくつかのソフトウェアは FreeBSD プロジェクト
-以外のところで保守されています。
-歴史的な経緯から、私たちはこれを <em> 寄贈 </em> ソフトウェアと呼
-んでいます。perl や gcc, patch などがその例です。
+以外のところで保守されています. 
+歴史的な経緯から, 私たちはこれを <em> 寄贈 </em> ソフトウェアと
+呼んでいます. perl や gcc, patch などがその例です. 
 
-<p>ここ数年来、この種のソフトウェアの取り扱いには、さまざまな方法が取ら
-れてきましたが、どの方法にもいくつかの利点と欠点があります。
-これまで欠点のない明確な方法はありませんでした。
+<p>ここ数年来, この種のソフトウェアの取り扱いには, さまざまな方法が
+取られてきましたが, どの方法にもいくつかの利点と欠点があります. 
+これまで欠点のない明確な方法はありませんでした. 
 
 <p>
-議論した結果、これらの方法のうちの一つが「公式な」方法として選択され
-ました。その方法が、今後、この種のソフトウェアを取り込む場合に、使用
-されます。
-その上、この方法では、だれもが(cvs にアクセス権のない人でさえ)「公式」
-バージョンのソースに対する差分を簡単に得ることができます。
-これは古い方法にはなかった大きな利点です。ですから、
-既存の寄贈ソフトウェアも、この方法に収束していくことを強く望んでいます。
-この方法を使用することにより、寄贈ソフトウェアの主な開発者に、変更
-点を返すのがとても容易になります。
+議論した結果, これらの方法のうちの一つが「公式な」方法として選択され
+ました. その方法が, 今後, この種のソフトウェアを取り込む場合に, 使用
+されます. 
+その上, この方法では, だれもが(cvs にアクセス権のない人でさえ)「公式」
+バージョンのソースに対する差分を簡単に得ることができます. 
+これは古い方法にはなかった大きな利点です. ですから, 
+既存の寄贈ソフトウェアも, この方法に収束していくことを強く望んでいます. 
+この方法を使用することにより, 寄贈ソフトウェアの主な開発者に, 変更
+点を返すのがとても容易になります. 
 
-<p>しかしながら結局、寄贈ソフトウェアの取扱は、実際に作業を行って
-いる人々に委ねられています。
-もしこの方法を使用することが、その人が扱っているパッケージには
-極端に合わないような場合には、コアチームの承認さえあれば、これらの
-ルールに反しても、他の開発者の一般的な合意は得られるでしょう。
-将来にわたってパッケージを保守できるということは、大変重要な事柄に
-なってきます。
+<p>しかしながら結局, 寄贈ソフトウェアの取扱は, 実際に作業を行って
+いる人々に委ねられています. 
+もしこの方法を使用することが, その人が扱っているパッケージには
+極端に合わないような場合には, コアチームの承認さえあれば, これらの
+ルールに反しても, 他の開発者の一般的な合意は得られるでしょう. 
+将来にわたってパッケージを保守できるということは, 大変重要な事柄に
+なってきます. 
 
-<p>プログラミング言語 <tt>Tcl</tt> は、
+<p>プログラミング言語 <tt>Tcl</tt> は, 
 この方法が活用されているよい例になっています:
 
-<p><verb>src/contrib/tcl</verb> には、このパッケージの保守管理者が
-配布したソースが含まれています。この中からは FreeBSD に完全には適用
-できない部分が削除されています。Tcl の場合は、"mac"、 "win"、
-"compat" というサブディレクトリは、FreeBSD に取り込む前に削除されて
-いました。 
+<p><verb>src/contrib/tcl</verb> には, このパッケージの保守管理者が
+配布したソースが含まれています. この中からは FreeBSD に完全には適用
+できない部分が削除されています. Tcl の場合は, "mac",  "win", 
+"compat" というサブディレクトリは, FreeBSD に取り込む前に削除されて
+いました.  
 
-<p><verb>src/lib/libtcl</verb> には、ライブラリを生成したり、ドキュ
-メントをインストールする際に使用される、標準の bsd.lib.mk の
-規則を使用した「bmake スタイル」の Makefile だけが 含まれています。
+<p><verb>src/lib/libtcl</verb> には, ライブラリを生成したり, ドキュ
+メントをインストールする際に使用される, 標準の bsd.lib.mk の
+規則を使用した「bmake スタイル」の Makefile だけが 含まれています. 
 
-<p><verb>src/usr.bin/tclsh</verb> には、bsd.prog.mk 規則 を使用して、
+<p><verb>src/usr.bin/tclsh</verb> には, bsd.prog.mk 規則 を使用して, 
 "tclsh" プログラムや関連するマニュアルページを生成 /インストール
-する bmake スタイルの Makefile だけが含まれています。
+する bmake スタイルの Makefile だけが含まれています. 
 
-<p><verb>src/tools/tools/tcl_bmake</verb> には、
+<p><verb>src/tools/tools/tcl_bmake</verb> には, 
 tcl ソフトウェアを更新する必要が生じたときの助けになる2つのシェルス
-クリプトが含まれています。これらは、ソフトウェアを構築するのに使用し
-たり、インストール対象になるソフトウェアではありません。
+クリプトが含まれています. これらは, ソフトウェアを構築するのに使用し
+たり, インストール対象になるソフトウェアではありません. 
 
-<p>ここ重要なのは、"src/contrib/tcl" ディレクトリが、規則にしたがっ
-て作られているということです。つまり、できるだけ FreeBSD に特化した
+<p>ここ重要なのは, "src/contrib/tcl" ディレクトリが, 規則にしたがっ
+て作られているということです. つまり, できるだけ FreeBSD に特化した
 変更をおこなわないようにしたソースを(CVS のベンダブランチに)おくようにし
-ています。   
-freefall 上の「簡易取り込み」ツールは、寄贈ソフトウェアを取り込む手助
-けとなります。けれども、このツールの実行方法に疑問が生じた場合は、ま
-ずはじめに質問して、失敗をしないようにしてください。そして、
-その疑問を「解決して」からツールを使用してください。
-CVS に寄贈ソフトウェアを取り込む際には、事故があってはいけません。
-よくあるような間違いをおかさないように、十分注意してください。
+ています.    
+freefall 上の「簡易取り込み」ツールは, 寄贈ソフトウェアを取り込む
+手助けとなります. けれども, このツールの実行方法に疑問が生じた場合は, 
+まずはじめに質問して, 失敗をしないようにしてください. そして, 
+その疑問を「解決して」からツールを使用してください. 
+CVS に寄贈ソフトウェアを取り込む際には, 事故があってはいけません. 
+よくあるような間違いをおかさないように, 十分注意してください. 
 
-<p>CVS には、残念なことにベンダブランチという設計制限があります。このた
-め、CVS に寄贈ソフトウェアを取り込むには、オリジナル配布ソースに 
-適用されるベンダからの「公式」パッチと、ベンダブランチに逆輸入された結
-果が必要です。 
-ベンダブランチの一貫性を破壊したり、将来、新しいバージョンを取り込む
+<p>CVS には, 残念なことにベンダブランチという設計制限があります.
+このため, CVS に寄贈ソフトウェアを取り込むには, オリジナル配布ソースに 
+適用されるベンダからの「公式」パッチと, ベンダブランチに逆輸入された
+結果が必要です.  
+ベンダブランチの一貫性を破壊したり, 将来, 新しいバージョンを取り込む
 時に衝突を起こしてしまったりというような 困難な事態に陥らないように
-しなければなりません。そのために、FreeBSD が管理しているバージョンに
-対して、公式パッチを決して当ててはいけませんし、公式パッチを 
-"commit" してはいけません。 
+しなければなりません. そのために, FreeBSD が管理しているバージョンに
+対して, 公式パッチを決して当ててはいけませんし, 公式パッチを 
+"commit" してはいけません.  
 
-<p>多くのパッケージが、他のアーキテクチャや他の環境と FreeBSD 
-との互換性を保ためのファイルをいくつか含んでいます。そこで、
-スペースを節約するために、FreeBSD にとっては無意味な配布ツリー上の一
-部を削除することが許されています。
-けれども、削除されずに残ったファイルに対する、著作権の通知やリリース
-ノートのような情報を含んだファイルは、決して削除しては <em> いけませ
-ん </em>。 
+<p>多くのパッケージが, 他のアーキテクチャや他の環境と FreeBSD 
+との互換性を保ためのファイルをいくつか含んでいます. そこで, 
+スペースを節約するために, FreeBSD にとっては無意味な配布ツリー上の一
+部を削除することが許されています. 
+けれども, 削除されずに残ったファイルに対する, 著作権の通知やリリース
+ノートのような情報を含んだファイルは, 決して削除しては <em> いけませ
+ん </em>.  
 
-<p>"bmake" Makefile が何らかのユーティリティによって、配布ツリーか
-ら自動的に生成できると、うまくいけば、新しいバージョンへのアップグレー
-ドをより簡単におこなうことができます。 
-もしこのようなユーティリティを作成できた場合には、将来の管理者にとっ
-て便利になるように、移植の際に、src/tools ディレクトリ上に、(必要に
-応じて)そのユーティリティを必ずチェックインしてください。
+<p>"bmake" Makefile が何らかのユーティリティによって, 配布ツリー
+から自動的に生成できると, うまくいけば, 新しいバージョンへの
+アップグレードをより簡単におこなうことができます.  
+もしこのようなユーティリティを作成できた場合には, 将来の管理者に
+とって便利になるように, 移植の際に, src/tools ディレクトリ上に, 
+(必要に応じて)そのユーティリティを必ずチェックインしてください. 
 
-<p> src/contrib/tcl レベルのディレクトリには、 README.FreeBSD と呼ば
-れるファイルが追加されており、そのファイルでは 次のような内容が
-記述されています。
+<p> src/contrib/tcl レベルのディレクトリには,  README.FreeBSD と
+呼ばれるファイルが追加されており, そのファイルでは 次のような内容が
+記述されています. 
 
 <itemize>
  <item> ディレクトリ上に存在するファイル
- <item> オリジナルの配布物をどこから入手すればよいか また、公式配布
+ <item> オリジナルの配布物をどこから入手すればよいか また, 公式配布
 サイトはどこか 
- <item> オリジナルの作者にパッチを送り返すためには、どこに送ればよいか
+ <item> オリジナルの作者にパッチを送り返すためには, どこに送ればよいか
  <item> FreeBSD に特化した変更点の概要
 </itemize>
+
+<sect><heading>共有ライブラリ
+<label id="policies:shlib">
+</heading>
+
+<p><em>Contributed by &a.asami;, &a.peter;, and &a.obrien;.
+  <newline>9 December 1996.</em></p>
+
+  <p>もしあなたが共有ライブラリをサポートする機能を port に追加した
+     り, 共有ライブラリをサポートしていない他のソフトウェアに追加する
+     場合には, 共有ライブラリのバージョン番号を次の規則にしたがって
+     つけてください.  
+     一般的には, この規則は, ソフトウェアのリリースバージョンとは
+     全く関係ありません. 
+  <p>共有ライブラリを作成する三つの重要な規則は次の通りです:
+
+  <itemize>
+    <item>1.0 から始める
+    <item>過去のバージョンに互換性のある変更の場合は, マイナー番号を増やす
+    <item>互換性のない変更の場合は, メジャー番号を増やす
+  </itemize>
+
+  <p>例えば, 機能追加とバグ吸収の場合は, マイナー番号を増やします.
+     機能削除, 関数呼び出しのシンタックスなどが変更された場合は, 
+     強制的にメジャー番号を変更します. 
+
+  <p>メジャー.マイナーー (x,y) の形式のバージョン番号を使用します. 
+     FreeBSD のダイナミックリンカは, x.y.z という形式のバージョン番号
+     は扱えません.
+     この場合, 「y」の後のバージョン番号(つまり三つ目の数字)は,
+     どのライブラリがリンクされているかを決めるために, 共有ライブラ
+     リ番号を比較する際に, すべて無視されます.
+     「小さな」リビジョンだけが異なる二つの共有ライブラリが指定
+     されると, ld.so は, リビジョンの大きい方の共有ライブラリを
+     リンクします. すなわち, もしあなたが libfoo.so.3.3.3 をリンク
+     していたとすると, リンカは頭の 3.3 という部分だけを認識し, 
+     libfoo.so.3 ではじまり その後に 3 以上の数字が続くもののうち、
+     最も大きい番号の付いているライブラリをリンクします. 
+  <p>ld.so はいつも最も大きい「マイナー」リビジョンのものを使うことに
+     注意してください. 例えば, プログラムがはじめ libc.so.2.0 を
+     リンクしていたとしても, libc.so.2.0 よりも libc.so.2.2 を優先
+     して使用します.
+
+  <p>移植されていないライブラリに対しては, リリースごとに共有ライブラリの
+     バージョン番号を一度だけ変更するのが私たちのポリシーです.
+     あなたがシステムライブラリのバージョン番号を上げた場合は,
+     Makefile の commit ログを確認してください.
+     結果としてそのリリースには, 共有ライブラリのバージョン番号が
+     アップデートされた Makefile に入るので、最初にその変更を
+     確かめるのがソースツリー管理者 ("committer") の責務です.
+     その後のどんな変更も, そのリリースには入りません.
+
+