1.435 -> 1.440	book.sgml

ispell-ru and style fixes [1].

Inspired by:    Max Kosmach <max@tcen.ru> [1]
Obtained from:	The FreeBSD Russian Documentation Project
This commit is contained in:
Dmitry Morozovsky 2006-08-04 16:34:30 +00:00
parent eee94f44b7
commit cc8ed2d6f2
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=28411

View file

@ -2,9 +2,9 @@
The FreeBSD Russian Documentation Project
$FreeBSD$
$FreeBSDru: frdp/doc/ru_RU.KOI8-R/books/porters-handbook/book.sgml,v 1.133 2005/10/17 08:07:15 gad Exp $
$FreeBSDru: frdp/doc/ru_RU.KOI8-R/books/porters-handbook/book.sgml,v 1.135 2006/08/04 16:33:24 marck Exp $
Original revision: 1.435
Original revision: 1.440
-->
<!DOCTYPE BOOK PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
@ -151,7 +151,7 @@ USE_IMAKE= yes
<title>Создание информационных файлов</title>
<para>Имеется два информационных файла, которые требуются для любого
порта, вне зависимости от того, является ли он пакаджем или нет. Это
порта, вне зависимости от того, является ли он пакетом или нет. Это
<filename>pkg-descr</filename> и <filename>pkg-plist</filename>.
Префикс <filename>pkg-</filename> отличает их от других файлов.</para>
@ -195,7 +195,7 @@ asami@cs.berkeley.edu</programlisting>
<para>Здесь перечисляются все файлы, устанавливаемые портом. Его
также называют <quote>списком для упаковки</quote>, потому что
пакадж генерируется упаковкой файлов, которые здесь указаны.
пакет генерируется упаковкой файлов, которые здесь указаны.
Имена путей указываются относительно установочного префикса
(обычно <filename>/usr/local</filename> или
<filename>/usr/X11R6</filename>). Если вы используете переменные
@ -232,6 +232,41 @@ lib/X11/oneko/mouse.xpm
linkend="porting-autoplist">автоматическом построении списка
упаковки</link> может помочь сэкономить время.</para>
</note>
<para>Существует только одно исключение, когда у порта может
отсутствовать <filename>pkg-plist</filename>. Если порт
устанавливает лишь несколько файлов, а возможно, и каталогов, то
они могут быть перечислены в переменных
<makevar>PLIST_FILES</makevar> и <makevar>PLIST_DIRS</makevar>,
соответственно, внутри файла <filename>Makefile</filename> порта.
К примеру, мы можем обойтись без файла
<filename>pkg-plist</filename> у приведённого выше порта
<filename>oneko</filename>, добавив следующие строки в
<filename>Makefile</filename>:</para>
<programlisting>PLIST_FILES= bin/oneko \
lib/X11/app-defaults/Oneko \
lib/X11/oneko/cat1.xpm \
lib/X11/oneko/cat2.xpm \
lib/X11/oneko/mouse.xpm
PLIST_DIRS= lib/X11/oneko</programlisting>
<para>Конечно, переменная <makevar>PLIST_DIRS</makevar> не должна
задаваться, если порт не устанавливает никаких каталогов.</para>
<para>Обратной стороной такого способа перечисления файлов и
каталогов порта является невозможность использования
последовательностей команд, описанных в &man.pkg.create.1;.
Поэтому он подходит для простых портов, что делает их ещё более
простыми. Одновременно с этим положительным моментом является
уменьшение количества файлов в коллекции портов. Пожалуйста,
подумайте над использованием этой техники, прежде чем создавать
<filename>pkg-plist</filename>.</para>
<para>Далее мы увидим, как можно использовать файлы
<filename>pkg-plist</filename> и <makevar>PLIST_FILES</makevar>
выполнения <link linkend="porting-plist">более сложных
задач</link>.</para>
</sect2>
</sect1>
@ -247,7 +282,7 @@ lib/X11/oneko/mouse.xpm
<title>Тестирование порта</title>
<para>Вы должны удостовериться, что правила построения порта выполняют
именно то, что вы хотите, включая создание пакаджа для порта. Вот
именно то, что вы хотите, включая создание пакета для порта. Вот
те важные вещи, которые вы должны проверить.</para>
<itemizedlist>
@ -310,7 +345,7 @@ lib/X11/oneko/mouse.xpm
предупреждений. После выполнения шага 3 проверьте, что все новые
каталоги были успешно удалены. Также попробуйте запустить
программное обеспечение после выполнения шага 4, чтобы убедиться, что
оно работает правильно при установке из пакаджа.</para>
оно работает правильно при установке из пакета.</para>
</sect1>
<sect1 id="porting-portlint">
@ -323,7 +358,7 @@ lib/X11/oneko/mouse.xpm
Портов. В частности, вы можете захотеть проверить, правильно ли
сформирован файл <link linkend="porting-samplem">Makefile</link> и
соответствующим ли образом наименован <link
linkend="porting-pkgname">пакадж</link>.</para>
linkend="porting-pkgname">пакет</link>.</para>
</sect1>
<sect1 id="porting-submitting">
@ -336,7 +371,7 @@ lib/X11/oneko/mouse.xpm
<para>Теперь, когда вы счастливы от своего первого порта, единственное,
что осталось сделать, это включить его в основное дерево портов
FreeBSD и осчастливить этим всех остальных. Нам не нужен ни ваш
каталог <filename>work</filename>, ни пакадж
каталог <filename>work</filename>, ни пакет
<filename>pkgname.tgz</filename>, так что удалите их прямо сейчас.
Затем просто включите вывод команды
<command>shar `find port_dir`</command> в сообщение об ошибке и пошлите
@ -369,7 +404,7 @@ lib/X11/oneko/mouse.xpm
<para>Повторим ещё раз, что <emphasis>не нужно включать ни оригинальный
файл с дистрибутивом, ни каталог <filename>work</filename>,
ни пакадж, построенный вами командой
ни пакет, построенный вами командой
<command>make package</command></emphasis>.</para>
<para>После того как вы послали порт, пожалуйста, потерпите.
@ -669,11 +704,11 @@ lib/X11/oneko/mouse.xpm
<command>configure</command>, не нужно включать файлы diff для
<command>configure</command> (они частенько вырастают до нескольких
тысяч строк!); задайте <literal>USE_AUTOCONF_VER=213</literal> и
включите дифф-файл для <filename>configure.in</filename>.</para>
включите diff-файл для <filename>configure.in</filename>.</para>
<para>Кроме того, если вы удаляете файл, то это можно сделать и в цели
<maketarget>post-extract</maketarget>, а не внутри патча. Как только
вы будете удовлетворены получающимся дифф-файлом, разбейте его на
вы будете удовлетворены получающимся diff-файлом, разбейте его на
несколько по одному патчу на отдельный файл.</para>
</sect1>
@ -706,7 +741,7 @@ lib/X11/oneko/mouse.xpm
<para>При наличии разумных ответов на задаваемые вопросы, подходящих по
умолчанию, также рекомендуется проверять переменную
<makevar>PACKAGE_BUILDING</makevar> и выключать интерактивный скрипт,
если он есть. Это позволит нам строить пакаджи для помещения на
если он есть. Это позволит нам строить пакеты для помещения на
компакт-диски и FTP-серверы.</para>
</sect1>
</chapter>
@ -775,15 +810,15 @@ lib/X11/oneko/mouse.xpm
монотонно увеличивающееся число, которое обнуляется при каждом
увеличении значения переменной <makevar>PORTVERSION</makevar> (то
есть каждый раз, когда создателями выпускается новый официальный
релиз), и добавляется к имени пакаджа, если оно не равно нулю.
релиз), и добавляется к имени пакета, если оно не равно нулю.
Изменения в <makevar>PORTREVISION</makevar> используются
автоматизированными инструментами (например, &man.pkg.version.1;)
для определения факта появления нового пакаджа.</para>
для определения факта появления нового пакета.</para>
<para>Значение <makevar>PORTREVISION</makevar> должно увеличиваться
каждый раз, когда в порте FreeBSD делаются изменения, которые
достаточно сильно затрагивают содержимое или структуру
соответствующего пакаджа.</para>
соответствующего пакета.</para>
<para>Примеры случаев, когда значение <makevar>PORTREVISION</makevar>
должно быть увеличено:</para>
@ -797,20 +832,20 @@ lib/X11/oneko/mouse.xpm
<listitem>
<para>Изменения в файле <filename>Makefile</filename> порта для
включения и выключения параметров, определяемых при компиляции
пакаджа.</para>
пакета.</para>
</listitem>
<listitem>
<para>Изменения в списке упаковки или в поведении пакаджа во
<para>Изменения в списке упаковки или в поведении пакета во
время его установки (например, изменение скрипта, генерирующего
начальные данные для пакаджа, такие, как ssh-ключи для
начальные данные для пакета, такие, как ssh-ключи для
хоста).</para>
</listitem>
<listitem>
<para>Увеличение версии динамической библиотеки, от которой
зависит порт (в этом случае тот, кто попытается установить
старый пакадж после установки более новой версии библиотеки,
старый пакет после установки более новой версии библиотеки,
не сможет этого сделать, потому что при этом будет делаться
поиск старой библиотеки libfoo.x, а не libfoo.(x+1)).</para>
</listitem>
@ -833,28 +868,28 @@ lib/X11/oneko/mouse.xpm
<itemizedlist>
<listitem>
<para>Изменения стиля в скелете порта без функциональных изменений
в пакадже.</para>
в пакете.</para>
</listitem>
<listitem>
<para>Изменения в переменной <makevar>MASTER_SITES</makevar> или
другие функциональные изменения порта, которые не затрагивают
получающегося пакаджа.</para>
получающегося пакета.</para>
</listitem>
<listitem>
<para>Тривиальные патчи к дистрибутивному файлу, такие, как
исправления опечаток, которые не так уж важны, что пользователи
пакаджа должны озаботиться обновлением.</para>
пакета должны озаботиться обновлением.</para>
</listitem>
<listitem>
<para>Исправления, касающиеся этапа построения, которые делают
возможным построение пакаджа, если ранее это было невозможно
возможным построение пакета, если ранее это было невозможно
сделать (пока изменения не приводят к изменению работы на любых
других платформах, на которых порт ранее строился). Так как
<makevar>PORTREVISION</makevar> отражает содержимое пакаджа,
то, если ранее пакадж не строился, то нет нужды увеличивать
<makevar>PORTREVISION</makevar> отражает содержимое пакета,
то, если ранее пакет не строился, то нет нужды увеличивать
<makevar>PORTREVISION</makevar> для отметки изменения.</para>
</listitem>
</itemizedlist>
@ -863,7 +898,7 @@ lib/X11/oneko/mouse.xpm
том, что нужно спрашивать себя, является ли вносимое в порт
изменение таким, что от него выиграют все (в виде
усовершенствования, исправления или благодаря тому, что новый
пакадж будет вообще работоспособным), и примите во внимание тот
пакет будет вообще работоспособным), и примите во внимание тот
факт, что при этом все, кто регулярно обновляют своё дерево портов,
будут обязаны это сделать. Если это так, то переменная
<makevar>PORTREVISION</makevar> должна быть увеличена.</para>
@ -882,17 +917,17 @@ lib/X11/oneko/mouse.xpm
<para>В ситуациях, подобных этой, должно быть увеличено значение
<makevar>PORTEPOCH</makevar>. Если значение
<makevar>PORTEPOCH</makevar> не равно нулю, то оно добавляется к
имени пакаджа, как описано в разделе выше. Значение
имени пакета, как описано в разделе выше. Значение
<makevar>PORTEPOCH</makevar> никогда не должно уменьшаться или
сбрасываться в ноль, потому что это приведёт к ошибке сравнения с
пакаджем с меньшим номером эпохи (то есть то, что пакадж устарел,
пакетом с меньшим номером эпохи (то есть то, что пакет устарел,
обнаружено не будет): номер новой версии (например,
<literal>1.0,1</literal> в примере выше) останется меньше, чем
номер предыдущей версии (20000801), однако суффикс
<literal>,1</literal> интерпретируется различными
автоматизированными утилитами особым образом, и окажется больше,
чем предполагаемый суффикс <literal>,0</literal> более раннего
пакаджа).</para>
пакета).</para>
<para>Некорректное уменьшение или сброс <makevar>PORTEPOCH</makevar>
приводит к печальным последствиям; если вы не поняли, о чём шла
@ -952,7 +987,7 @@ PORTREVISION= 1</programlisting>
младший номер версии <literal>2</literal> по значению меньше, чем
номер предыдущей версии <literal>10</literal>, то должно быть
увеличено значение <makevar>PORTEPOCH</makevar> для того, чтобы
заставить распознавать вновь создаваемый пакадж как <quote>более
заставить распознавать вновь создаваемый пакет как <quote>более
новый</quote>. Так как это новый релиз программы, то
<makevar>PORTREVISION</makevar> обнуляется (или удаляется из
файла <filename>Makefile</filename>).</para>
@ -978,8 +1013,8 @@ PORTEPOCH= 1</programlisting>
<note>
<para>Если значение <makevar>PORTEPOCH</makevar> этим обновлением
было бы сброшено в <literal>0</literal>, то кто-нибудь, имеющий
установленный пакадж <literal>gtkmumble-0.10_1</literal>, не
смог бы опознать пакадж <literal>gtkmumble-0.3</literal> как
установленный пакет <literal>gtkmumble-0.10_1</literal>, не
смог бы опознать пакет <literal>gtkmumble-0.3</literal> как
более новый, так как <literal>3</literal> было бы меньше, чем
<literal>10</literal>. Помните, что в первую очередь это
касается <makevar>PORTEPOCH</makevar>.</para>
@ -999,10 +1034,10 @@ PORTEPOCH= 1</programlisting>
<literal>${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}</literal>.
Добейтесь того, чтобы это соответствовало нашим <link
linkend="porting-pkgname">рекомендациям по правильному выбору
названий для пакаджей</link>. В частности, в переменной
названий для пакетов</link>. В частности, в переменной
<makevar>PORTVERSION</makevar> <emphasis>не разрешается</emphasis>
использование дефиса (<literal>-</literal>). Кроме того, если в
имени пакаджа присутствует часть <replaceable>language-</replaceable>
имени пакета присутствует часть <replaceable>language-</replaceable>
или <replaceable>-compiled.specifics</replaceable> (смотрите ниже),
то используйте переменные <makevar>PKGNAMEPREFIX</makevar> и
<makevar>PKGNAMESUFFIX</makevar>, соответственно. Не делайте их
@ -1010,18 +1045,18 @@ PORTEPOCH= 1</programlisting>
</sect2>
<sect2 id="porting-pkgname">
<title>Соглашения по именованию пакаджей</title>
<title>Соглашения по именованию пакетов</title>
<para>Далее описаны некоторые соглашения, которым вы должны следовать
в именовании ваших пакаджей. Они были разработаны для облегчения
просмотра каталога, так как имеется уже тысячи пакаджей, а
в именовании ваших пакетов. Они были разработаны для облегчения
просмотра каталога, так как имеется уже тысячи пакетов, а
пользователи отвернутся от нас, если список не понравится их
взору!</para>
<para>Имя пакаджа должно иметь вид
<para>Имя пакета должно иметь вид
<filename><replaceable><optional>language<optional>_region</optional></optional>-name<optional><optional>-</optional>compiled.specifics</optional>-version.numbers</replaceable></filename>.</para>
<para>Имя пакаджа определяется как
<para>Имя пакета определяется как
<literal>${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}</literal>.
Вы должны задавать значения переменных в соответствии с этим
форматом.</para>
@ -1104,7 +1139,7 @@ PORTEPOCH= 1</programlisting>
<para>Вот несколько (реальных) примеров того, как преобразовать имя из
оригинального, придуманного авторами, к подходящему для имени
пакаджа:</para>
пакета:</para>
<informaltable frame="none">
<tgroup cols="6">
@ -1233,7 +1268,7 @@ PORTEPOCH= 1</programlisting>
<entry>-letter</entry>
<entry>1.13</entry>
<entry>Размер бумаги задается статически во время построения
пакаджа</entry>
пакета</entry>
</row>
<row>
@ -1242,7 +1277,7 @@ PORTEPOCH= 1</programlisting>
<entry>pkfonts</entry>
<entry>300</entry>
<entry>1.0</entry>
<entry>Пакадж для шрифтов 300dpi</entry>
<entry>пакет для шрифтов 300dpi</entry>
</row>
</tbody>
</tgroup>
@ -1264,13 +1299,13 @@ PORTEPOCH= 1</programlisting>
<sect2>
<title><makevar>CATEGORIES</makevar></title>
<para>В процессе создания пакаджа он помещается в каталог
<para>В процессе создания пакета он помещается в каталог
<filename>/usr/ports/packages/All</filename>, а в одном или более
подкаталогов из <filename>/usr/ports/packages</filename>
создаются на него ссылки. Имена этих подкаталогов определяются
переменной <makevar>CATEGORIES</makevar>. Такая схема нужна для
облегчения жизни пользователя, когда он сталкивается с массой
пакаджей на FTP-сервере или компакт-диске. Пожалуйста, посмотрите на
пакетов на FTP-сервере или компакт-диске. Пожалуйста, посмотрите на
список существующих <link
linkend="porting-categories">категорий</link> и выберите те из них,
которые более всего подходят к вашему порту.</para>
@ -3013,19 +3048,19 @@ PATCHFILES= patch1:test</programlisting>
url="../developers-handbook/policies.html#POLICIES-MAINTAINER">
MAINTAINER в Makefiles</ulink>.</para>
<para>Если мэйнтейнер порта не ответил на запрос пользователя об
<para>Если мейнтейнер порта не ответил на запрос пользователя об
обновлении в течение двух недель (исключая большие праздники),
то это можно считать тайм-аутом от мэйнтейнера, и обновление может
быть выполнено без явного подтверждения от мэйнтейнера. Если
мэйнтейнер не отвечает в течение трёх месяцев, то считается, что
он отсутствует, и как мэйнтейнер порта, о котором идёт речь, может
то это можно считать тайм-аутом от мейнтейнера, и обновление может
быть выполнено без явного подтверждения от мейнтейнера. Если
мейнтейнер не отвечает в течение трёх месяцев, то считается, что
он отсутствует, и как мейнтейнер порта, о котором идёт речь, может
быть заменён. Исключениями из этого правила является всё, что
сопровождает &a.portmgr; или &a.security-officer;. Запрещено делать
любые несанкционированные изменения в портах, которые ведут эти
группы.</para>
<para>За &a.portmgr; оставляется право снять или назначить кого-либо
мэйнтейнером, по любой причине, а за the &a.security-officer;
мейнтейнером, по любой причине, а за the &a.security-officer;
оставляется право лишать или назначать права на сопровождение порта
по соображениям информационной безопасности.</para>
</sect1>
@ -3034,7 +3069,7 @@ PATCHFILES= patch1:test</programlisting>
<title><makevar>COMMENT</makevar></title>
<para>Это однострочное описание порта. <emphasis>Пожалуйста</emphasis>,
не включайте сюда название пакаджа (или номер версии программного
не включайте сюда название пакета (или номер версии программного
обеспечения). Комментарий должен начинаться с заглавной буквы и не
заканчиваться точкой. Вот пример:</para>
@ -3086,7 +3121,7 @@ PATCHFILES= patch1:test</programlisting>
<para>Зависимость проверяется дважды, один раз внутри цели
<maketarget>extract</maketarget>, а затем из цели
<maketarget>install</maketarget>. Кроме того, имя зависимости
помещается в пакадж, так что &man.pkg.add.1; будет
помещается в пакет, так что &man.pkg.add.1; будет
автоматически его устанавливать, если его нет на пользовательской
системе.</para>
</sect2>
@ -3133,7 +3168,7 @@ PATCHFILES= patch1:test</programlisting>
<para>Зависимость проверяется внутри цели
<maketarget>install</maketarget>. Кроме того, имя зависимости
помещается в пакадж, так что программа &man.pkg.add.1;
помещается в пакет, так что программа &man.pkg.add.1;
будет автоматически его устанавливать, если он не будет найден
в пользовательской системе. Часть
<replaceable>target</replaceable> может быть опущена, если она
@ -3421,7 +3456,7 @@ PATCHFILES= patch1:test</programlisting>
другой способ получить требуемый результат. Это может привести к
тому, что какой-то другой порт всегда будет строиться (и по
умолчанию устанавливаться). и такая зависимость отразится и на
пакадже. Если это именно то, что вам нужно, то вам, наверное,
пакете. Если это именно то, что вам нужно, то вам, наверное,
следует описывать это через <literal>BUILD_DEPENDS</literal> и
<literal>RUN_DEPENDS</literal>&mdash;по крайней мере смысл
будет более понятен.</para>
@ -3531,14 +3566,14 @@ PORTVERSION= 1.0</programlisting>
<sect1 id="conflicts">
<title><makevar>CONFLICTS</makevar></title>
<para>Если ваш пакадж не может существовать одновременно с другими
<para>Если ваш пакет не может существовать одновременно с другими
(из-за конфликтов файлов, несовместимости во время выполнения и так
далее), перечислите имена остальных пакаджей в переменной
далее), перечислите имена остальных пакетов в переменной
<makevar>CONFLICTS</makevar>. Здесь вы можете использовать шаблоны
командного процессора типа <literal>*</literal> и
<literal>?</literal>. Имена пакаджей должны выглядеть так же, как
<literal>?</literal>. Имена пакетов должны выглядеть так же, как
в <filename>/var/db/pkg</filename>. Пожалуйста, убедитесь, что
<makevar>CONFLICTS</makevar> не содержит пакадж самого этого порта
<makevar>CONFLICTS</makevar> не содержит пакет самого этого порта
или еще, что установка с помощью переменной <makevar>FORCE_PKG_REGISTER</makevar>
больше не будет использоваться.</para>
</sect1>
@ -3546,10 +3581,10 @@ PORTVERSION= 1.0</programlisting>
<sect1 id="makefile-build">
<title>Механизмы построения</title>
<para>Если ваш пакадж использует GNU-версию утилиты
<para>Если ваш пакет использует GNU-версию утилиты
<command>make</command>, задайте <literal>USE_GMAKE=yes</literal>.
Если ваш пакадж использует <command>configure</command>, задайте
<literal>HAS_CONFIGURE=yes</literal>. Если ваш пакадж использует
Если ваш пакет использует <command>configure</command>, задайте
<literal>HAS_CONFIGURE=yes</literal>. Если ваш пакет использует
GNU-версию <command>configure</command>, задайте
<literal>GNU_CONFIGURE=yes</literal> (это также подразумевает
<literal>HAS_CONFIGURE</literal>). Если вы хотите передать
@ -3558,7 +3593,7 @@ PORTVERSION= 1.0</programlisting>
<literal>--prefix=&dollar;{PREFIX}</literal> для GNU
<command>configure</command> и пустую строку для не-GNU
<command>configure</command>), укажите эти дополнительные параметры в
<makevar>CONFIGURE_ARGS</makevar>. Если ваш пакадж использует
<makevar>CONFIGURE_ARGS</makevar>. Если ваш пакет использует
GNU-версию <command>autoconf</command>, задайте
<literal>USE_AUTOCONF_VER=213</literal>. Это подразумевает
<makevar>GNU_CONFIGURE</makevar>, и приведет к вызову
@ -3580,7 +3615,7 @@ PORTVERSION= 1.0</programlisting>
<para><literal>CONFIGURE_TARGET=--build=${MACHINE_ARCH}-portbld-freebsd${OSREL}</literal></para>
</note>
<para>Если ваш пакадж является приложением для X, которое создает
<para>Если ваш пакет является приложением для X, которое создает
файлы <filename>Makefile</filename> из соответствующих файлов
<filename>Imakefile</filename> при помощи утилиты
<command>imake</command>, то задайте <literal>USE_IMAKE=yes</literal>.
@ -3625,8 +3660,8 @@ PORTVERSION= 1.0</programlisting>
<literal>@exec /sbin/ldconfig -m</literal> и
<literal>@unexec /sbin/ldconfig -R</literal> в ваш файл
<filename>pkg-plist</filename>, так что пользователь, устанавливающий
пакадж, сможет сразу же использовать динамическую библиотеку, а
удаление пакаджа не приведёт к тому, что система будет предполагать,
пакет, сможет сразу же использовать динамическую библиотеку, а
удаление пакета не приведёт к тому, что система будет предполагать,
что библиотека всё ещё имеется в наличии.</para>
<para>Если нужно, вы можете переопределить каталог, в который по
@ -3675,7 +3710,7 @@ LDCONFIG_DIRS= %%PREFIX%%/lib/foo %%PREFIX%%/lib/bar</programlisting>
<title><makevar>NO_PACKAGE</makevar></title>
<para>Эта переменная указывает, что мы не можем создавать для
приложения двоичный пакадж. К примеру, лицензия не позволяет
приложения двоичный пакет. К примеру, лицензия не позволяет
бинарное распространение или она может запрещать распространение
пакетов, созданных из изменённых исходников.</para>
@ -3685,14 +3720,14 @@ LDCONFIG_DIRS= %%PREFIX%%/lib/foo %%PREFIX%%/lib/bar</programlisting>
переменная <makevar>NO_CDROM</makevar>.</para>
<para><makevar>NO_PACKAGE</makevar> должна также использоваться, если
двоичный пакадж, как правило, бесполезен, а приложение должно всегда
двоичный пакет, как правило, бесполезен, а приложение должно всегда
компилироваться из исходного кода. К примеру, если в приложение
во время компиляции жёстко включается конфигурационная информация,
привязанная к конкретной системе, то задайте переменную
<makevar>NO_PACKAGE</makevar>.</para>
<para>Значением переменной <makevar>NO_PACKAGE</makevar> должна быть
строка, описывающая причину, по которой пакадж не должен
строка, описывающая причину, по которой пакет не должен
создаваться.</para>
</sect2>
@ -3702,7 +3737,7 @@ LDCONFIG_DIRS= %%PREFIX%%/lib/foo %%PREFIX%%/lib/bar</programlisting>
<para>Эта переменная указывает на то, что, хотя мы имеем право
создавать бинарные пакеты, мы не можем помещать эти пакеты или
файлы <makevar>DISTFILES</makevar> порта на CD-ROM (или на похожие носители) для
перепродажи. Однако бинарные пакаджи и файлы
перепродажи. Однако бинарные пакеты и файлы
<makevar>DISTFILES</makevar> порта будут оставаться
доступными посредством FTP/HTTP.</para>
@ -3723,7 +3758,7 @@ LDCONFIG_DIRS= %%PREFIX%%/lib/foo %%PREFIX%%/lib/bar</programlisting>
<para>Задайте эту переменную, если лицензия на приложение не позволяет
ни зеркалировать файлы <makevar>DISTFILES</makevar>, ни распространять
бинарный пакадж через FTP/HTTP или на CD-ROM.</para>
бинарный пакет через FTP/HTTP или на CD-ROM.</para>
<para>Ни <makevar>NO_CDROM</makevar>, ни <makevar>NO_PACKAGE</makevar>
не стоит устанавливать вместе с <makevar>RESTRICTED</makevar>, так
@ -3861,7 +3896,7 @@ LDCONFIG_DIRS= %%PREFIX%%/lib/foo %%PREFIX%%/lib/bar</programlisting>
<entry><makevar>SITE_PERL</makevar></entry>
<entry>Имя каталога, куда помещаются специфичные для сайта
пакаджи <literal>perl</literal>. Это значение добавляется к
пакеты <literal>perl</literal>. Это значение добавляется к
PLIST_SUB.</entry>
</row>
</tbody>
@ -4551,13 +4586,11 @@ LDCONFIG_DIRS= %%PREFIX%%/lib/foo %%PREFIX%%/lib/bar</programlisting>
JDK, таким образом становится проблематичным определить список файлов
для упаковки (<filename>pkg-plist</filename>). Это одна из причин,
по которой создателям портов настоятельно рекомендуется использовать
макрос <makevar>PORTDOCS</makevar>. Эта функцию ещё предстоит хорошо
документировать, поэтому вы должны обратиться непосредственно к файлу
<filename>bsd.port.mk</filename> для получения более полной
информации. Более того, даже если вы сможете угадать набор файлов,
который будет сгенерирован утилитой <command>javadoc</command>,
размер получающегося файла <filename>pkg-plist</filename> голосует за
использование <makevar>PORTDOCS</makevar>.</para>
макрос <makevar>PORTDOCS</makevar>. Более того, даже если вы сможете
угадать набор файлов, который будет сгенерирован утилитой
<command>javadoc</command>, размер получающегося файла
<filename>pkg-plist</filename> голосует за использование
<makevar>PORTDOCS</makevar>.</para>
<para>Значением по умолчанию для переменной <makevar>DATADIR</makevar>
является <filename>${PREFIX}/share/${PORTNAME}</filename>. Хорошей
@ -4761,7 +4794,7 @@ USE_SDL+= mixer
<sect1>
<title>Формат</title>
<para>Пакаджи в дереве портов будут строиться в том формате, в котором
<para>пакеты в дереве портов будут строиться в том формате, в котором
работает машина. Это означает формат a.out для 2.2 и a.out или ELF
для 3.0 в зависимости от результата работы команды
<command>`objformat`</command>. Кроме того, как только пользователь
@ -4902,7 +4935,7 @@ PORTOBJFORMAT!= test -x /usr/bin/objformat && /usr/bin/objformat || echo aout
</programlisting>
<para>Это нужно для того, чтобы утилита <command>ldconfig</command>
была вызвана правильно в зависимости от формата пакаджа, а не
была вызвана правильно в зависимости от формата пакета, а не
формата, используемого в системе по умолчанию.</para>
</sect1>
</chapter>
@ -4913,10 +4946,10 @@ PORTOBJFORMAT!= test -x /usr/bin/objformat && /usr/bin/objformat || echo aout
<title><makevar>MASTERDIR</makevar></title>
<para>Если вашему порту требуется построение довольно различающихся
версий пакаджей через переменную (задающую, например, разрешение,
версий пакетов через переменную (задающую, например, разрешение,
или размер бумаги), которая принимает различные значения, создайте для
каждого пакаджа отдельный подкаталог, чтобы пользователям было легче
определить, каким пакаджем воспользоваться, но попробуйте использовать
каждого пакета отдельный подкаталог, чтобы пользователям было легче
определить, каким пакетом воспользоваться, но попробуйте использовать
совместно между портами как можно больше файлов. В типичном случае вам
потребуются только очень короткие файлы <filename>Makefile</filename>
во всех каталогах, кроме одного, если вы будете использовать переменные
@ -4925,7 +4958,7 @@ PORTOBJFORMAT!= test -x /usr/bin/objformat && /usr/bin/objformat || echo aout
каталога, в котором находятся все остальные файлы. Также используйте
переменную как часть <link
linkend="porting-pkgname"><makevar>PKGNAMESUFFIX</makevar></link>, чтобы
пакаджи имели разные имена.</para>
пакеты имели разные имена.</para>
<para>Продемонстрируем это на примере. Вот часть файла
<filename>japanese/xdvi300/Makefile</filename>:</para>
@ -4947,7 +4980,7 @@ RESOLUTION?= 300
</programlisting>
<para>Порт <filename role="package">japanese/xdvi300</filename> содержит
также все обычные патчи, файлы для пакаджа и так далее. Если вы введете
также все обычные патчи, файлы для пакета и так далее. Если вы введете
здесь команду <command>make</command>, она возьмет в качестве разрешения
значение по умолчанию (300) и построит порт обычным образом.</para>
@ -5113,7 +5146,7 @@ ${PREFIX}/man/ja/man4/baz.4.gz
на работу с портами, которым требуется Motif, так чтобы мы могли
легко создавать бинарные файлы, скомпонованные как динамически (для
тех, кто строит приложение из порта), так и статически (для тех, кто
будет распространять приложения в виде пакаджей).</para>
будет распространять приложения в виде пакетов).</para>
<sect1 id="motif-use">
<title><makevar>USE_MOTIF</makevar></title>
@ -5176,9 +5209,9 @@ ${PREFIX}/man/ja/man4/baz.4.gz
<chapter id="porting-info">
<title>Файлы в формате info</title>
<para>Если в вашем пакадже нужна установка файлов GNU info, они должны
<para>Если в вашем пакете нужна установка файлов GNU info, они должны
быть перечислены в переменной <makevar>INFO</makevar> (без окончания
<literal>.info</literal>), и тогда перед регистрации пакаджа во
<literal>.info</literal>), и тогда перед регистрации пакета во
временный файл <filename>pkg-plist</filename> будет автоматически
добавлен соответствующий код установки/удаления.</para>
</chapter>
@ -5203,7 +5236,7 @@ ${PREFIX}/man/ja/man4/baz.4.gz
<note>
<para>Файл <filename>pkg-message</filename> не нужно добавлять в
<filename>pkg-plist</filename>. И он не будет автоматически
выводиться, если пользователь использует порт, а не пакадж, так что
выводиться, если пользователь использует порт, а не пакет, так что
вы должны будете сами выводить его при выполнении цели
<maketarget>post-install</maketarget>.</para>
</note>
@ -5212,11 +5245,11 @@ ${PREFIX}/man/ja/man4/baz.4.gz
<sect1 id="pkg-install">
<title><filename>pkg-install</filename></title>
<para>Если при установке бинарного пакаджа по команде
<para>Если при установке бинарного пакета по команде
&man.pkg.add.1; вашему порту нужно выполнить какие-то
дополнительные действия или команды, то вы можете сделать это с
помощью скрипта <filename>pkg-install</filename>. Этот скрипт будет
автоматически добавлен к пакаджу, и будет дважды запускаться по
автоматически добавлен к пакету, и будет дважды запускаться по
команде &man.pkg.add.1;: первый раз в виде
<literal>&dollar;{SH} pkg-install &dollar;{PKGNAME}
PRE-INSTALL</literal>, а второй раз как <literal>&dollar;{SH} {PKGNAME}
@ -5224,7 +5257,7 @@ ${PREFIX}/man/ja/man4/baz.4.gz
Для распознавания того, в каком режиме запущен скрипт, можно
использовать параметр <literal>&dollar;2</literal>. Переменная
окружения <envar>PKG_PREFIX</envar> будет принимать значение,
соответствующее каталогу, в который устанавливается пакадж.
соответствующее каталогу, в который устанавливается пакет.
Дополнительная информация находится на странице Справочника о
команде &man.pkg.add.1;.</para>
@ -5239,7 +5272,7 @@ ${PREFIX}/man/ja/man4/baz.4.gz
<sect1 id="pkg-deinstall">
<title><filename>pkg-deinstall</filename></title>
<para>Этот скрипт вызывается при удалении пакаджа.</para>
<para>Этот скрипт вызывается при удалении пакета.</para>
<para>Этот скрипт утилитой &man.pkg.delete.1; будет запускаться
дважды. Первый раз как <literal>&dollar;{SH} pkg-install
@ -5316,6 +5349,24 @@ PLIST_SUB= OCTAVE_VERSION=${OCTAVE_VERSION}</programlisting>
требуется отредактировать получающийся файл, делайте это в цели
<maketarget>post-install</maketarget> изменением файла
<filename><makevar>TMPPLIST</makevar></filename>.</para>
<para>Другой способ изменения списка сборки порта основан на
определении значений переменных <makevar>PLIST_FILES</makevar> и
<makevar>PLIST_DIRS</makevar>. Каждое из них рассматривается как
перечень путей для записи в
<filename><makevar>TMPPLIST</makevar></filename> содержимого
<filename><makevar>PLIST</makevar></filename>. Имена, перечисленные
в <makevar>PLIST_FILES</makevar> и <makevar>PLIST_DIRS</makevar>,
подвергаются подстановке <literal>%%VAR%%</literal>, как описано
выше. За исключением этого, имена из <makevar>PLIST_FILES</makevar>
будут появляться в окончательном варианте перечня сборки без
изменений, когда как <literal>@dirrm</literal> будет предшествовать
именам из <makevar>PLIST_DIRS</makevar>. Для того, чтобы возыметь
действие, <makevar>PLIST_FILES</makevar> и
<makevar>PLIST_DIRS</makevar> должны задаваться до того, как будет
записываться <filename><makevar>TMPPLIST</makevar></filename>, то
есть в цели <maketarget>pre-install</maketarget> или ещё
раньше.</para>
</sect1>
<sect1 id="pkg-names">
@ -5495,7 +5546,7 @@ IGNORE=POINTYHAT is not supported
<screen>&prompt.root; <userinput>make clean; make package PREFIX=/var/tmp/<replaceable>port-name</replaceable></userinput></screen>
<para>Если что-то было установлено за пределами
<makevar>PREFIX</makevar>, то процесс создания пакаджа сообщит об
<makevar>PREFIX</makevar>, то процесс создания пакета сообщит об
отсутствии файлов.</para>
<!-- XXX This paragraph is confusing and poorly indented. -->
@ -5580,13 +5631,13 @@ IGNORE=POINTYHAT is not supported
причину не обновлять порт прямо сейчас (например, из-за проблем со
стабильностью функционирования новой версии);
вам нет нужды дублировать их работу. Заметьте, что неподдерживаемые
порты перечисляются с адресом мэйнтейнера
порты перечисляются с адресом мейнтейнера
<literal>ports@FreeBSD.org</literal>, который является всего лишь
адресом общего списка рассылки, так что отправка туда сообщений,
скорее всего, в данном случае не поможет.</para>
<para>Если мэйнтейнер просит вас выполнить обновление, либо
или мэйнтейнер отсутствует, то у вас появляется шанс помочь &os;,
<para>Если мейнтейнер просит вас выполнить обновление, либо
или мейнтейнер отсутствует, то у вас появляется шанс помочь &os;,
приготовив обновление самим! Пожалуйста, внесите изменения и сохраните
результат рекурсивного <command>diff</command>
между новым и старым каталогами порта (например, если каталог с
@ -5608,9 +5659,9 @@ IGNORE=POINTYHAT is not supported
<para>Если порт никем не поддерживается, а вы активно его используете,
пожалуйста, подумайте над тем, чтобы добровольно стать его
мэйнтэйнером. Во &os; имеется более 2000 портов без поддержки, и это
мейнтейнером. Во &os; имеется более 2000 портов без поддержки, и это
как раз та область, где всегда нужны добровольцы. (Детальное описание
обязанностей мэйнтэйнеров можно найти в разделе <ulink
обязанностей мейнтейнеров можно найти в разделе <ulink
url="../developers-handbook/policies.html#POLICIES-MAINTAINER">
MAINTAINER в Make-файлах</ulink>.)</para>
@ -5623,7 +5674,7 @@ IGNORE=POINTYHAT is not supported
В противном случае в поле <quote>Class</quote> вашего PR должно быть
указано <literal>change-request</literal>. Будьте добры, в сообщении
отметьте все добавленные или удалённые файлы, так как они будут
непосредственно указаны &man.cvs.1; при выполнении операции коммитта.
непосредственно указаны &man.cvs.1; при выполнении операции коммита.
Если diff-файл имеет размер, превышающий 20КБ, сожмите его и обработайте
утилитой uuencode; в противном случае просто включите его как есть
в PR.</para>
@ -5638,7 +5689,7 @@ IGNORE=POINTYHAT is not supported
<para>Если ваше обновление вызвано соображениями информационной
безопасности или наличием серьёзных ошибок в имеющемся порте,
пожалуйста, оповестите &a.portmgr; о необходимости немедленного
перепостроения и повторного распространения пакаджа вашего порта.
перепостроения и повторного распространения пакета вашего порта.
В противном случае ничего не подозревающие пользователи &man.pkg.add.1;
будут продолжать устанавливать старую версию по команде
<command>pkg_add -r</command> в течение ещё нескольких недель.</para>
@ -6457,7 +6508,7 @@ IGNORE=POINTYHAT is not supported
<row>
<entry>4.5-STABLE после переключения на использование по
умолчанию при построении пакаджей XFree86 4.</entry>
умолчанию при построении пакетов XFree86 4.</entry>
<entry>450005</entry>
</row>
@ -6694,7 +6745,7 @@ IGNORE=POINTYHAT is not supported
</row>
<row>
<entry>5.0-CURRENT после первого коммитта SMPng.</entry>
<entry>5.0-CURRENT после первого коммита SMPng.</entry>
<entry>500013</entry>
</row>
@ -6786,7 +6837,7 @@ IGNORE=POINTYHAT is not supported
<row>
<entry>5.0-CURRENT после перехода на использование по умолчанию
XFree86 4 для построения пакаджей и после добавления в
XFree86 4 для построения пакетов и после добавления в
библиотеку libc новой функции strnstr().</entry>
<entry>500026</entry>
@ -6887,7 +6938,7 @@ IGNORE=POINTYHAT is not supported
<entry>5.0-CURRENT после того, как в файлах заголовков было
прекращено использование _BSD_FOO_T_ и начато использование
_FOO_T_DECLARED. Это значение может быть также использовано
как примерная точка начала поддержки пакаджей в формате
как примерная точка начала поддержки пакетов в формате
&man.bzip2.1;.</entry>
<entry>500039</entry>
@ -7453,26 +7504,35 @@ post-install:
${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${DOCSDIR}
.endif</programlisting>
<para>Вот несколько переменных и то, как они преобразуются при
использовании в <filename>Makefile</filename>:</para>
<para>Вот несколько полезных переменных и то, как они преобразуются по
умолчанию при использовании в <filename>Makefile</filename>:</para>
<itemizedlist>
<listitem>
<para><literal>${DATADIR}</literal> преобразуется в
<filename>${PREFIX}/share/${PORTNAME}</filename>.</para>
<para><makevar>DATADIR</makevar> преобразуется в
<filename><makevar>PREFIX</makevar>/share/<makevar>PORTNAME</makevar></filename>.</para>
</listitem>
<listitem>
<para><literal>${DOCSDIR}</literal> преобразуется в
<filename>${PREFIX}/share/doc/${PORTNAME}</filename>.</para>
<para><makevar>DOCSDIR</makevar> преобразуется в
<filename><makevar>PREFIX</makevar>/share/doc/<makevar>PORTNAME</makevar></filename>.</para>
</listitem>
<listitem>
<para><literal>${EXAMPLESDIR}</literal> преобразуется в
<filename>${PREFIX}/share/examples/${PORTNAME}</filename>.</para>
<para><makevar>EXAMPLESDIR</makevar> преобразуется в
<filename><makevar>PREFIX</makevar>/share/examples/<makevar>PORTNAME</makevar></filename>.</para>
</listitem>
</itemizedlist>
<para>Эти переменные экспортируются в <makevar>PLIST_SUB</makevar>.
Их значения появятся там в виде имён путей относительно
<filename><makevar>PREFIX</makevar></filename>, если это возможно.
То есть <filename>share/doc/<makevar>PORTNAME</makevar></filename>
в списке сборки по умолчанию будет заменен на
<literal>%%DOCSDIR%%</literal>, и так далее. (Дополнительную
информацию о подстановке в <filename>pkg-plist</filename> можно
найти <link linkend="porting-plist">здесь</link>.)</para>
<para>Все устанавливаемые файлы с документацией и каталоги должны быть
перечислены в файле <filename>pkg-plist</filename> с префиксом
<literal>%%PORTDOCS%%</literal>, например:</para>
@ -7491,6 +7551,27 @@ post-install:
<para>Файл <filename>pkg-message</filename> не нужно добавлять в
<filename>pkg-plist</filename>.</para>
</note>
<para>В качестве альтернативы перечислению файлов документации в файле
<filename>pkg-plist</filename>, порт может указать в переменной
<makevar>PORTDOCS</makevar> список имён файлов и глобальных шаблонов
командного процессора для добавления в окончательный список сборки.
Имена будут задаваться относительно <makevar>DOCSDIR</makevar>.
Таким образом, порт, использующий <makevar>PORTDOCS</makevar> и
нестандартное местоположение документации, должен задавать
соответствующим образом и <makevar>DOCSDIR</makevar>. Если каталог
указан в <makevar>PORTDOCS</makevar> или соответствует шаблону для
этой переменной, то полное поддерево с входящими в него файлами и
каталогами будет регистрироваться в окончательном списке сборки.
<makevar>PORTDOCS</makevar> не должна задаваться, если определена
переменная <makevar>NOPORTDOCS</makevar>. Установка документации в
<makevar>PORTDOCS</makevar>, как это показано выше, остаётся за
самим портом. Типичный пример использования
<makevar>PORTDOCS</makevar> выглядит следующим образом:</para>
<programlisting>.if !defined(NOPORTDOCS)
PORTDOCS= *
.endif</programlisting>
</sect1>
<sect1 id="dads-subdirs">
@ -7556,7 +7637,7 @@ lib/X11/oneko/sounds/cat.au
<sect1 id="dads-uid">
<title>Идентификаторы UID</title>
<para>Если вашему порты требуется наличие некоторого пользователя в
<para>Если вашему порту требуется наличие некоторого пользователя в
системе, на которую он устанавливается, пусть скрипт
<filename>pkg-install</filename> вызовет команду
<command>pw</command> для его автоматического создания. Посмотрите
@ -7564,7 +7645,7 @@ lib/X11/oneko/sounds/cat.au
</para>
<para>Если ваш порт должен использовать тот же самый идентификатор
пользователя или группы при установке двоичного пакаджа, который был
пользователя или группы при установке двоичного пакета, который был
при компиляции, то вы должны выбрать свободный UID в диапазоне от 50
до 999 и зарегистрировать его ниже. Взгляните для примера на
<filename role="package">japanese/Wnn6</filename>.</para>
@ -7942,7 +8023,7 @@ PORTVERSION
#
# &dollar;FreeBSD&dollar;
[ ^^^^^^^^^ Эта строка будет автоматически заменена со строчкой RCS ID
системой CVS при выполнении операции коммитта в наше хранилище. При
системой CVS при выполнении операции коммита в наше хранилище. При
обновлении порта не приводите эту строку обратно к виду
"&dollar;FreeBSD&dollar;". CVS сделает все автоматически.]
#
@ -7971,7 +8052,7 @@ PATCH_SITES= ftp://ftp.sra.co.jp/pub/X11/japanese/
PATCHFILES= xdvi-18.patch1.gz xdvi-18.patch2.gz
[сопровождающий; *обязательное поле*! Это человек (предпочтительно с
привилегиями на операцию коммитта), с которым может связаться пользователь
привилегиями на операцию коммита), с которым может связаться пользователь
для получения ответов на вопросы и посылки сообщений об ошибках - этот
человек должен быть создателем порта или кем-то, кто может передать
вопросы создателю порта. Если вы на самом деле не хотите указывать здесь
@ -8093,7 +8174,7 @@ pre-install:
<para>Самым простым способом отслеживать уже произошедшие обновления
является подписка на <ulink url="http://www.FreshPorts.org/">
FreshPorts</ulink>. Для мониторинга вы можете выбрать несколько
портов. Мэйнтэйнерам настоятельно рекомендуется подписаться здесь,
портов. Мейнтейнерам настоятельно рекомендуется подписаться здесь,
потому что они будут получать уведомления не только о собственных
изменениях, но и об изменениях, сделанных любым другим коммиттером
&os;. (Это часто необходимо для синхронизации с изменениями на более
@ -8152,7 +8233,7 @@ pre-install:
из основных релизов ОС для каждой архитектуры уровня поддержки
Tier-1 выделен целый кластер машин. Вы можете увидеть результаты
этих построений в <ulink url="http://pointyhat.FreeBSD.org/">протоколах
построения пакаджей и обнаруженных ошибок</ulink>.</para>
построения пакетов и обнаруженных ошибок</ulink>.</para>
</sect1>
<sect1>
@ -8166,7 +8247,7 @@ pre-install:
инспектирования дистрибутивных файлов FreeBSD</ulink> пытается
опросить каждый из сайтов, доступный для сгрузки каждого из портов
для определения того, доступны ли ещё дистрибутивные файлы.
Мэйнтэйнеры должны периодически просматривать этот протокол, и не
Мейнтейнеры должны периодически просматривать этот протокол, и не
только для ускорения процесса построения пользователем, но и для
избежания траты пропускной способности сайтов, на которых все эти
дистрибутивные файлы размещаются на добровольной основе.</para>