diff options
author | Andrey Zakhvatov <andy@FreeBSD.org> | 2005-07-14 04:47:04 +0000 |
---|---|---|
committer | Andrey Zakhvatov <andy@FreeBSD.org> | 2005-07-14 04:47:04 +0000 |
commit | 5a4e8ea30b1e676c8a373d089f421adc152a36e3 (patch) | |
tree | 0147893a52df03d82e1d3a30b6747591623bf26b /ru_RU.KOI8-R | |
parent | 7b63d5a37cb7fe243e2fe549733ebe998f437794 (diff) | |
download | doc-5a4e8ea30b1e676c8a373d089f421adc152a36e3.tar.gz doc-5a4e8ea30b1e676c8a373d089f421adc152a36e3.zip |
Synchronize with English 1.31
Submitted by: Vitaly Bogdanov <gad@gad.glazov.net>
Obtained from: The FreeBSD Russian Documentation Project
Notes
Notes:
svn path=/head/; revision=25103
Diffstat (limited to 'ru_RU.KOI8-R')
-rw-r--r-- | ru_RU.KOI8-R/books/developers-handbook/policies/chapter.sgml | 469 |
1 files changed, 469 insertions, 0 deletions
diff --git a/ru_RU.KOI8-R/books/developers-handbook/policies/chapter.sgml b/ru_RU.KOI8-R/books/developers-handbook/policies/chapter.sgml new file mode 100644 index 0000000000..7fedfc7fd8 --- /dev/null +++ b/ru_RU.KOI8-R/books/developers-handbook/policies/chapter.sgml @@ -0,0 +1,469 @@ +<!-- + The FreeBSD Russian Documentation Project + + $FreeBSD$ + $FreeBSDru: frdp/doc/ru_RU.KOI8-R/books/developers-handbook/policies/chapter.sgml,v 1.6 2005/07/11 12:44:48 gad Exp $ + + Original revision: 1.31 +--> + +<chapter id="policies"> + <chapterinfo> + <authorgroup> + <author> + <firstname>Poul-Henning</firstname> + <surname>Kamp</surname> + <contrib>Материал предоставил: </contrib> + </author> + </authorgroup> + <!-- June 1996 --> + </chapterinfo> + + <title>Рекомендации и требования к исходному коду</title> + + <para>В этой главе описываются различные рекомендации и требования, которые + должны соблюдаться в дереве исходных текстов FreeBSD.</para> + + <sect1 id="policies-maintainer"> + <title><makevar>MAINTAINER</makevar> в make-файлах</title> + <indexterm><primary>ports maintainer</primary></indexterm> + + <para>Если некоторая часть дистрибутива FreeBSD поддерживается некоторым + человеком или группой людей, они могут сообщить об этом миру, добавив + строчку + + <programlisting>MAINTAINER= email-addresses</programlisting> + + в файл <filename>Makefile</filename>, соответствующий этой части + исходного кода.</para> + + <para>Смысл этого в следующем:</para> + + <para>Сопровождающий владеет кодом и отвечает за него. Это означает, что + он несет ответственность за исправление ошибок и закрывает сообщения о + проблемах, имеющих отношение к этой части кода, а в случае программного + обеспечения, взятого из третьих источников, соответственно отвечает за + отслеживание новых версий.</para> + + <para>Изменения в каталогах, для которых известен сопровождающий, прежде + чем они будут внесены, должны быть посланы ему на рассмотрение. Только + если сопровождающий не отвечает в течение достаточно большого периода + времени на несколько посланий по электронной почте, разрешается внести + изменения без участия сопровождающего. Однако рекомендуется, чтобы вы + попытались передать изменения на рассмотрение кому-либо еще, если это + вообще возможно.</para> + + <para>Конечно же, нельзя назначать человека или группу лиц + сопровождающими, если они не согласны выполнять эту работу. С другой + стороны, необязательно это должен быть конкретный коммиттер, это может + быть и группа людей.</para> + </sect1> + + <sect1 id="policies-contributed"> + <sect1info> + <authorgroup> + <author> + <firstname>Poul-Henning</firstname> + <surname>Kamp</surname> + <contrib>Материал предоставили: </contrib> + </author> + <author> + <firstname>David</firstname> + <surname>O'Brien</surname> + </author> + </authorgroup> + <!-- June 1996 --> + </sect1info> + + <title>Программное обеспечение сторонних производителей</title> + + <indexterm><primary>contributed software</primary></indexterm> + + <para>Некоторые части дистрибутива FreeBSD состоят из программного + обеспечения, которое сопровождается вне проекта FreeBSD. По + историческим причинам мы называем такое программное обеспечение + <emphasis>контрибуцированным</emphasis> (contributed), или третьих + сторон. Примерами этого могут служить утилиты <application>sendmail</application>, <application>gcc</application> и + <application>patch</application>.</para> + + <para>За последние несколько лет для работы с таким программным + обеспечением использовались различные методы, и все они имели свои + достоинства и недостатки. Абсолютно подходящего метода так и не + нашлось.</para> + + <para>По этой причине после некоторых дебатов был выбран и признан + <quote>официальным</quote> один из этих методов, который необходимо + применять в будущем при импортировании такого рода программного + обеспечения. Более того, настоятельно рекомендуется с течением времени + перевести существующее программное обеспечение третьих сторон на этот + метод, так как он имеет значительные преимущества перед старым методом, + включая возможность легкого получения diff-файлов относительно + <quote>официальных</quote> версий исходных текстов кем угодно (даже + не имеющим доступа к cvs). Это делает данный метод гораздо проще + в использовании при необходимости выдачи изменений изначальным + разработчикам такого программного обеспечения.</para> + + <para>В конце концов, однако, это касается тех, кто делает реальную + работу. Если использование этой модели в конкретном случае не подходит + для пакета, с которым работает человек, могут быть сделаны и + исключения только с согласия основной команды разработчиков и при общем + одобрении других разработчиков. Возможность сопровождения пакета в + будущем будет являться ключевым моментом при принятии решений.</para> + + <note> + <para>Из-за досадных ограничений в дизайне формата файлов RCS и + использовании веток поставщика в CVS, мелкие, тривиальные и/или + косметические изменения <emphasis>сильно не рекомендуется</emphasis> + в файлах, которые все еще отслеживаются в ветке поставщика. Это + касается и <quote>исправления орфографических ошибок</quote> как + относящихся к категории <quote>косметических</quote> и избегаемых + для файлов с версиями 1.1.x.x. Рост объема хранилища, вызванный + изменением в один символ, может оказаться весьма большим.</para> + </note> + + <para>В качестве примера того, как работает эта модель, будем + использовать встраиваемый язык программирования + <application>TCL</application>:</para> + + <para>Каталог <filename>src/contrib/tcl</filename> содержит исходные + тексты пакета в том виде, в котором они распространяются его + создателями. Части, которые полностью не применимы во FreeBSD, могут + быть удалены. В случае Tcl подкаталоги <filename>mac</filename>, + <filename>win</filename> и <filename>compat</filename> были удалены + перед операцией импортирования</para> + + <para>Каталог <filename>src/lib/libtcl</filename> содержит только файл + <filename>Makefile</filename> в стиле <application>bmake</application>, который + использует стандартные правила <filename>bsd.lib.mk</filename> + make-файла для построения библиотеки и установки документации.</para> + + <para>В каталоге <filename>src/usr.bin/tclsh</filename> размещаются + make-файлы в стиле bmake, которые отвечают за построение и установку + программы <command>tclsh</command> и связанных с ней справочных + страниц при помощи стандартных правил из + <filename>bsd.prog.mk</filename>.</para> + + <para>Каталог <filename>src/tools/tools/tcl_bmake</filename> содержит + несколько shell-скриптов, которые могут помочь при обновлении + программного обеспечения tcl. Они не являются частью строящегося и + инсталлируемого программного обеспечения.</para> + + <para>Здесь важно то, что каталог <filename>src/contrib/tcl</filename> + создавался в соответствии с правилами: Предполагается, что он содержит + исходные тексты в том виде, в котором они распространяются (в + соответствующей ветви поставщика CVS и без расширения ключевых слов + RCS) с максимально малым количеством изменений, специфичных для + FreeBSD. Утилита 'easy-import' на машине <hostid>freefall</hostid> поможет в + импортировании, но если есть сомнения по поводу выполнения этой + операции, то обязательно спросите совета и не действуйте слепо в + расчете на то, что <quote>все сработает</quote>. CVS не прощает ошибок + импортирования и для ликвидации последствий больших ошибок требуются + значительные усилия.</para> + + <para>Из-за ранее отмеченных ограничений дизайна веток поставщиков в CVS + требуется, чтобы <quote>официальные</quote> патчи от разработчика + были сначала применены к распространяемым исходным текстам, а затем + результат снова импортирован в ветку поставщика. Официальные патчи + никогда не должны применяться к версии, извлеченной из хранилища + FreeBSD, а затем <quote>коммититься</quote>, так как это приведет к + рассинхронизации дерева производителя и усложнит импортирование + будущих версий, так как возникнут конфликты.</para> + + <para>Так как многие пакеты содержат файлы, имеющие значение при + обеспечении совместимости с другими, отличными от FreeBSD архитектурами + и окружениями, то разрешается удалять части дистрибутивного дерева, + не представляющие интереса для FreeBSD в целях уменьшения занимаемого + дискового пространства. Файлы, содержащие замечания о юридических + правах и информацию о релизе, касающуюся остальных файлов, удаляться + <emphasis>не</emphasis> должны.</para> + + <para>Если это видится легким, то файлы <filename>Makefile</filename> в + стиле <command>bmake</command> могут быть сгенерированы из + дистрибутивного дерева автоматически некоторой утилитой, чем-то, что + позволит еще проще обновляться до новой версии. Если это будет + сделано, то обязательно поместите эту утилиту (если необходимо) в + каталог <filename>src/tools</filename> вместе с самим портом, чтобы + она была доступна будущим сопровождающим лицам.</para> + + <para>В каталог <filename>src/contrib/tcl</filename> должен быть добавлен + файл <filename>FREEBSD-upgrade</filename>, в котором нужно перечислить + такие вещи:</para> + + <itemizedlist> + <listitem> + <para>Какие файлы были оставлены</para> + </listitem> + + <listitem> + <para>Где был взят оригинальный дистрибутив и/или на каком основном + официальном сайте он находится.</para> + </listitem> + + <listitem> + <para>Куда посылать патчи для разработчиков пакета</para> + </listitem> + + <listitem> + <para>Возможно, обзор сделанных изменений, специфичных для + FreeBSD.</para> + </listitem> + </itemizedlist> + + <para>Однако, пожалуйста, не импортируйте + <filename>FREEBSD-upgrade</filename> вместе с исходными текстами + этого программного обеспечения. Вместо этого вы должны выполнить + команды <command>cvs add FREEBSD-upgrade ; cvs ci</command> после + первоначального импортирования. Ниже дается пример описания из + каталога <filename>src/contrib/cpio</filename>:</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>Нежелательные файлы</title> + + <para>Иногда может быть необходимо включить некоторый нежелательный для + нас файл в дерево исходных текстов FreeBSD. Например, если устройство + требует загрузки в него некоторого маленького двоичного кода перед тем, + как устройство заработает, и мы не имеем исходных текстов этого кода, + то говорится, что двоичный файл является нежелательным. Для включения + нежелательных файлов в дерево исходных текстов FreeBSD имеются + следующие соглашения.</para> + + <orderedlist> + <listitem> + <para>Любой файл, интерпретируемый или выполняемый системным(и) CPU, + не в форме исходного кода, является нежелательным.</para> + </listitem> + + <listitem> + <para>Любой файл с лицензией, ограничивающей более, чем BSD или GNU, + является нежелательным.</para> + </listitem> + + <listitem> + <para>Файл, содержащий загружаемые двоичные данные, используемые + аппаратным обеспечением, не являются нежелательными, если только + к нему не применимы условия (1) или (2). Он должен быть сохранен в + нейтральном к архитектуре формате ASCII (рекомендуется применить + утилиты file2c или uuencode).</para> + </listitem> + + <listitem> + <para>Любой нежелательный файл требует особого одобрения со стороны + <ulink url="&url.articles.contributors;/staff-core.html">Правления</ulink> до + того, как он будет добавлен в хранилище CVS.</para> + </listitem> + + <listitem> + <para>Нежелательные файлы помещаются в каталог + <filename>src/contrib</filename> или + <filename>src/sys/contrib</filename>.</para> + </listitem> + + <listitem> + <para>Части одного модуля должны храниться вместе. Нет необходимости + разбивать их, если только нет совместного использования с кодом, + не являющимся нежелательным.</para> + </listitem> + + <listitem> + <para>Объектные файлы именуются + <filename><replaceable>arch</replaceable>/<replaceable>filename</replaceable>.o.uu></filename>.</para> + </listitem> + + <listitem> + <para>Файлы ядра;</para> + + <orderedlist> + <listitem> + <para>Должны всегда упоминаться в + <filename>conf/files.*</filename> (для упрощения + построения).</para> + </listitem> + + <listitem> + <para>Должны всегда присутствовать в <filename>LINT</filename>, + но <ulink + url="&url.articles.contributors;/staff-core.html">Правление</ulink> + решает в каждом конкретном случае, должны + ли они быть раскомментированы или нет. Конечно, позже <ulink + url="&url.articles.contributors;/staff-core.html">Правление</ulink> + может изменить свое решение.</para> + </listitem> + + <listitem> + <para>Вопрос о вхождении в состав релиза решается + <firstterm>Группой Выпусков Релизов</firstterm>.</para> + </listitem> + </orderedlist> + </listitem> + + <listitem> + <para>Файлы уровня пользователя:</para> + + <orderedlist> + <listitem> + <indexterm><primary>core team</primary></indexterm> + <para><ulink + url="&url.articles.contributors;/staff-core.html">Правление</ulink> + решает, должен ли код стать частью + выполнения команды <command>make world</command>.</para> + </listitem> + + <listitem> + <indexterm><primary>release engineer</primary></indexterm> + <para><ulink url="&url.articles.contributors;/staff-who.html">Релиз + инженер</ulink> решает, войдут ли они в релиз.</para> + </listitem> + </orderedlist> + </listitem> + </orderedlist> + </sect1> + + <sect1 id="policies-shlib"> + <sect1info> + <authorgroup> + <author> + <firstname>Satoshi</firstname> + <surname>Asami</surname> + <contrib>Материал предоставили: </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>Динамические библиотеки</title> + + <para>Если вы добавляете поддержку динамических библиотек к порту или + другой части программного обеспечения, которая этой возможностью не + обладает, то номера версий должны назначаться по нижеследующим + правилам. Как правило, получающиеся номера не имеют ничего общего с + номером релиза программного обеспечения.</para> + + <para>При построении динамической библиотеки используются три + принципа:</para> + + <itemizedlist> + <listitem> + <para>Начинаем с <literal>1.0</literal></para> + </listitem> + + <listitem> + <para>Если есть изменение, которое имеет обратную совместимость, + увеличиваем младший номер версии (заметьте, что системы ELF его + игнорируют)</para> + </listitem> + + <listitem> + <para>Если есть изменение, не соблюдающее совместимость, увеличиваем + старший номер версии</para> + </listitem> + </itemizedlist> + + <para>К примеру, добавление функций и исправление ошибок приводит к + увеличению младшего номера версии, а удаление функций, изменение + синтаксиса вызова функции и тому подобные изменения приводят к + изменению старшего номера версии.</para> + + <para>Следуйте схеме нумерации версий в форме старший.младший + (<replaceable>x</replaceable>.<replaceable>y</replaceable>). Наш + динамический загрузчик формата a.out не умеет нормально работать с + номерами версий в форме + <replaceable>x</replaceable>.<replaceable>y</replaceable>.<replaceable>z</replaceable>. + Любой номер версии после <replaceable>y</replaceable> (то есть третье + число) полностью игнорируется при сравнении номеров версий динамических + библиотек для определения того, с какой библиотекой осуществлять + компоновку. Если есть две динамические библиотеки, отличающиеся только + <quote>микро</quote>-номером версии, то <command>ld.so</command> будет + осуществлять компоновку с наибольшим номером. Другими словами: если + вы компонуете с <filename>libfoo.so.3.3.3</filename>, то компоновщик + запишет в заголовках только <literal>3.3</literal> и будет выполнять + компоновку с любой библиотекой, начинающейся с + <replaceable>libfoo.so.3</replaceable>.<replaceable>(все, что >= + 3)</replaceable>.<replaceable>(наибольшее из + доступного)</replaceable>.</para> + + <note> + <para><command>ld.so</command> всегда будет использовать наибольшую + <quote>младшую</quote> версию. Иными словами: он будет предпочитать + использовать <filename>libc.so.2.2</filename>, а не + <filename>libc.so.2.0</filename>, даже если программа изначально была + скомпонована с <filename>libc.so.2.0</filename>.</para> + </note> + + <para>Вдобавок наш динамический компоновщик ELF совсем не работает с + младшими версиями. Однако все же нужно указывать старший и младший + номер версии, а наши файлы <filename>Makefile</filename> <quote>сделают + все как нужно</quote> в зависимости от типа системы.</para> + + <para>Для библиотек не в составе портов, имеется наше соглашение на + изменение номера версии динамической библиотеки только один раз между + релизами. Кроме того, есть договоренность на изменение старшего + номера динамической библиотеки только один раз между главными релизами + ОС (например c 3.0 к 4.0). Когда вы делаете изменение в системной + библиотеке, которое требует увеличения номера версии, посмотрите + журналы коммитов изменений в файле <filename>Makefile</filename>. + Коммиттер отвечает за то, что первое такое изменение с момента релиза + приведет к обновлению номера версии динамической библиотеки в файле + <filename>Makefile</filename>, а при других последующих изменениях + этого бы не делалось.</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: +--> |