diff options
Diffstat (limited to 'ru_RU.KOI8-R/books/porters-handbook/upgrading/chapter.xml')
| -rw-r--r-- | ru_RU.KOI8-R/books/porters-handbook/upgrading/chapter.xml | 300 |
1 files changed, 300 insertions, 0 deletions
diff --git a/ru_RU.KOI8-R/books/porters-handbook/upgrading/chapter.xml b/ru_RU.KOI8-R/books/porters-handbook/upgrading/chapter.xml new file mode 100644 index 0000000000..7372064ce5 --- /dev/null +++ b/ru_RU.KOI8-R/books/porters-handbook/upgrading/chapter.xml @@ -0,0 +1,300 @@ +<?xml version="1.0" encoding="koi8-r"?> +<!-- + The FreeBSD Russian Documentation Project + + $FreeBSD$ + + Original revision: r43840 +--> + +<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="port-upgrading"> + + <title>Обновление отдельного порта</title> + + <para>Если вы заметите, что ваш порт устарел по сравнению с последней + авторской версией, первым делом вы должны получить самую + последнюю версия порта. Вы можете найти их в каталоге + <filename>ports/ports-current</filename> на зеркальных FTP-серверах &os;. + Однако если вы работаете с достаточно большим количеством портов, + наверное, будет проще использовать + <application>Subversion</application> или &man.portsnap.8; для + поддержания всей коллекции портов в актуальном состоянии, как это + описано в <link xlink:href="&url.books.handbook;/ports-using.html"> + Руководстве</link>. К тому же это даст возможность отслеживать все + зависимости портов.</para> + + <para>На следующем шаге необходимо выяснить, нет ожидает ли уже это + обновление своей очереди. Для этого у вас есть две возможности. + Существует интерфейс к <link xlink:href="http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query">базе + данных сообщений о проблемах FreeBSD (PR)</link> (известной также как + <literal>GNATS</literal>) с поисковыми возможностями. Выберите из + выпадающего списка <literal>ports</literal> и введите название + порта.</para> + + <para>Однако иногда люди забывают поместить название порта в поле + Synopsis в точном виде. В таком случае вы можете воспользоваться + <link linkend="portsmon">Системой мониторинга портов &os;</link> + (которая известна также как + <literal>portsmon</literal>). В рамках этой системы делается попытка + классифицировать PR, касающиеся портов, по имени порта. Для поиска + PR, относящихся к определённому порту, используйте механизм <link xlink:href="http://portsmon.FreeBSD.org/portoverview.py">Просмотра + по одному порту</link>.</para> + + <para>Если таких отложенных PR не существует, то на следующем этапе + следует послать сообщение электронной почты человеку, поддерживающему + порт, который выдаётся по команде <command>make maintainer</command>. + Этот человек может уже работать над обновлением, или иметь + причину не обновлять порт прямо сейчас (например, из-за проблем со + стабильностью функционирования новой версии); + вам нет нужды дублировать их работу. Заметьте, что неподдерживаемые + порты перечисляются с адресом сопровождающего + <literal>ports@FreeBSD.org</literal>, который является всего лишь + адресом общего списка рассылки, так что отправка туда сообщений, + скорее всего, в данном случае не поможет.</para> + + <para>Если сопровождающий просит вас выполнить обновление, либо + сопровождающий отсутствует, то у вас появляется шанс помочь &os;, + приготовив обновление самим! Пожалуйста, делайте это с использованием + команды &man.diff.1; в основной системе.</para> + + <para>Чтобы создать подходящий <command>diff</command> для одного патча, + скопируйте файл, который нужно пропатчить, в + <replaceable>something.orig</replaceable>, сохраните ваши изменения в + <replaceable>something</replaceable>, а затем создайте ваше патч:</para> + + <informalexample> + <screen>&prompt.user; <userinput>diff -u something.orig something > something.diff</userinput></screen> + </informalexample> + + <para>В противном случае, вам следует воспользоваться методом + <command>svn diff</command> (<xref linkend="svn-diff"/>), либо + скопировать содержимое порта в + отдельный каталог и применить результат рекурсивной команды &man.diff.1; + между новым и старым каталогами порта (например, если каталог с + модифицированным портом называется <filename>superedit</filename>, + а оригинальный, совпадающий с находящимся в нашем дереве портов, + <filename>superedit.bak</filename>, то сохраните результат выполнения + команды <command>diff -ruN superedit.bak superedit</command>). + Подойдёт как унифицированный, так и контекстный дифф, однако коммиттеры + портов обычно предпочитают унифицированный формат. Отметьте + использование опции <literal>-N</literal>—это одобряемый способ + заставить diff корректно работать в случае добавления новых файлов или + удаления старых. Перед тем, как посылать нам diff-файл, пожалуйста, + проверьте его, чтобы убедиться в значимости всех внесённых + изменений. (В частности, убедитесь, что вы очистили рабочие каталоги + командой <command>make clean</command>).</para> + + <para>Для упрощения повторяющихся операций с файлами заплаток + вы можете воспользоваться скриптом + <filename>/usr/ports/Tools/scripts/patchtool.py</filename>. Перед тем, + как его запускать, пожалуйста, прочтите + <filename>/usr/ports/Tools/scripts/README.patchtool</filename>.</para> + + <para>Если порт никем не поддерживается, а вы активно его используете, + пожалуйста, подумайте над тем, чтобы добровольно стать его + сопровождающим. Во &os; имеется более 4000 портов без поддержки, и это + как раз та область, где всегда нужны добровольцы. (Детальное описание + обязанностей сопровождающего можно найти в разделе в <link xlink:href="&url.books.developers-handbook;/policies.html#POLICIES-MAINTAINER"> + Руководстве Разработчика</link>.)</para> + + <para>Лучше всего послать нам diff-файл, включив его в посылку по команде + &man.send-pr.1; (категория <literal>ports</literal>). Если вы + сопровождаете порт, + обязательно поместите текст <literal>[maintainer update]</literal> в + начале строки описания и задайте в поле <quote>Class</quote> + вашего PR строчку <literal>maintainer-update</literal>. + В противном случае в поле <quote>Class</quote> вашего PR должно быть + указано <literal>change-request</literal>. Будьте добры, в сообщении + отметьте все добавленные или удалённые файлы, так как они будут + непосредственно указаны &man.svn.1; при выполнении операции коммита. + Если diff-файл имеет размер, превышающий 20КБ, сожмите его и обработайте + утилитой uuencode; в противном случае просто включите его как есть + в PR.</para> + + <para>Прежде чем пользоваться &man.send-pr.1; просмотрите раздел + о <link xlink:href="&url.articles.problem-reports;/pr-writing.html">Написании + сообщений о проблемах</link> в статье о Сообщениях об ошибках. Он + содержит гораздо больше информации о том, как писать полезные сообщения + о проблемах.</para> + + <important> + <para>Если обновление вызвано соображениями информационной + безопасности или наличием серьёзных ошибок в имеющемся порте, + пожалуйста, оповестите &a.portmgr; о необходимости немедленного + перепостроения и повторного распространения пакета данного порта. + В противном случае ничего не подозревающие пользователи + <command>pkg</command> будут продолжать устанавливать старую + версию по команде <command>pkg install</command> в течение + ещё нескольких недель.</para> + </important> + + <note> + <para>Повторяем еще раз - для посылки обновлений существующих портов + используйте утилиту &man.diff.1;, а не &man.shar.1;! Это поможет + понять коммиттерам портов, что именно было изменено.</para> + </note> + + <para>Теперь, когда вы проделали всё это, прочитайте о том, как + поддерживать актуальное состояние, в <xref linkend="keeping-up"/>.</para> + + <sect1 xml:id="svn-diff"> + <title>Использование <application>Subversion</application> для + создания патчей</title> + + <para>По возможности присылайте исправления в формате &man.svn.1; diff. + В таком виде их проще использовать по сравнению с разницей между + <quote>старым и новым</quote> каталогами. Так проще + увидеть изменения и обновить их в случае, если что-нибудь + изменилось в Коллекции Портов с тех пор, как вы начали работу, + либо если коммиттер просит что-то исправить.</para> + + <screen>&prompt.user; <userinput>cd ~/my_wrkdir</userinput> <co xml:id="my-wrkdir"/> +&prompt.user; <userinput>svn co https://svn0.us-west.FreeBSD.org/ports/head/dns/pdnsd</userinput> <co xml:id="svn-FreeBSD-org"/> +&prompt.user; <userinput>cd ~/my_wrkdir/pdnsd</userinput></screen> + + <calloutlist> + <callout arearefs="my-wrkdir"> + <para>Это может быть где угодно; место, в котором производится + построение портов, не привязано к + <filename>/usr/ports/</filename>.</para> + </callout> + + <callout arearefs="svn-FreeBSD-org"> + <para><link xlink:href="https://svn0.us-west.FreeBSD.org/">svn0.us-west.FreeBSD.org</link> + — это общедоступный сервер + <application>Subversion</application>. + Выберите ближайшее зеркало и проверьте сертификат + зеркалирующего сервера на наличие в перечне <link xlink:href="&url.books.handbook;/svn-mirrors.html">зеркалирующих + сайтов Subversion</link>.</para> + </callout> + </calloutlist> + + <para>Находясь в рабочем каталоге, вносите любые изменения, которые + обычно делают для порта. При добавлении или удалении файла + используйте <command>svn</command> для отслеживания этих + изменений:</para> + + <screen>&prompt.user; <userinput>svn add new_file</userinput> +&prompt.user; <userinput>svn remove deleted_file</userinput></screen> + + <para>Убедитесь, что вы проверяете порт в соответствии с рекомендуемым + порядком проверки, описанным в <xref linkend="porting-testing"/> и + <xref linkend="porting-portlint"/>.</para> + + <screen>&prompt.user; <userinput>svn status</userinput> +&prompt.user; <userinput>svn update</userinput> <co xml:id="svn-update"/></screen> + + <calloutlist> + <callout arearefs="svn-update"> + <para>Эта команда попытается выполнить слияние различий между + вашим патчем и текущей версией репозитория; внимательно проверьте + полученный вывод. Буква перед названием каждого файла означает + тип изменения, сделанного с этим файлом. Для получения полного + списка смотрите <xref linkend="table-svn-up"/>.</para> + </callout> + </calloutlist> + + <table pgwide="1" frame="none" xml:id="table-svn-up"> + <title>Префиксы файлов для <application>Subversion</application> + update</title> + + <tgroup cols="2"> + <tbody> + <row> + <entry>U</entry> + + <entry>Файл обновлен без проблем.</entry> + </row> + + <row> + <entry>G</entry> + + <entry>Файл обновлен без проблем (вы увидите это только + при работе с удаленным репозиторием).</entry> + </row> + + <row> + <entry>M</entry> + + <entry>Файл с локальными изменениями, слияние выполнено + без конфликтов.</entry> + </row> + + <row> + <entry>C</entry> + + <entry>Файл с локальными изменениями, слияние выполнено + с конфликтами.</entry> + </row> + </tbody> + </tgroup> + </table> + + <para>Если в результате выполнения <literal>svn update</literal> + отображается <literal>C</literal>, то это означает, что что-то + изменилось в репозитории <application>Subversion</application> + и &man.svn.1; не смогла выполнить + слияние локальных изменений с полученными из репозитория. + В любом случае никогда не помешает просмотреть изменения, + поскольку &man.svn.1; ничего не знает о том, каким должен быть + порт, поэтому эта команда может (и, вероятно, будет) делать + слияние тех изменений, которые не имеют смысла.</para> + + <para>Последним шагом является создание унифицированного &man.diff.1; + для полученных изменений:</para> + + <screen>&prompt.user; <userinput>svn diff > ../`basename ${PWD}`.diff</userinput></screen> + + <note> + <para>Информация о любых удаляемых файлов должна быть явным + образом указана в PR, поскольку необходимость в удалении + файла для коммиттера может быть неочевидна.</para> + </note> + + <para>Присылайте свои патчи в соответствии с руководством, описанном в + <xref linkend="port-upgrading"/>.</para> + </sect1> + + <sect1 xml:id="moved-and-updating-files"> + <title>Файлы <filename>UPDATING</filename> и + <filename>MOVED</filename></title> + + <para>Если при обновлении порта требуются специальные шаги, такие как + изменение файлов конфигурации или запуск специальной программы, + то вам следует это задокументировать в файле + <filename>/usr/ports/UPDATING</filename>. Формат записи в этом + файле приводится ниже:</para> + + <programlisting>YYYYMMDD: + AFFECTS: users of portcategory/portname + AUTHOR: Your name <Your email address> + + Special instructions</programlisting> + + <para>Если вы включаете точные инструкции portmaster или portupgrading, + пожалуйста, убедитесь в правильном экранировании символов внутри + командной оболочки.</para> + + <para>Файл <filename>/usr/ports/MOVED</filename> содержит записи + об удалённых или перемещённых портах. Каждая строка в этом + файле состоит из полей: название порта, место, куда он был + перемещён, дата и причина перемещения. Если порт был удалён, + то поле, указывающее новое место, может оставаться незаполненным. + Поля должны разделяться символом <literal>|</literal> (pipe), + как это показано ниже:</para> + + <programlisting>old name|new name (blank for deleted)|date of move|reason</programlisting> + + <para>Дату следует вводить в формате <literal>YYYY-MM-DD</literal>. + Новые записи следует добавлять в конец файла в хронологическом + порядке.</para> + + <para>Если порт был перемещён, но в дальнейшем восстановлен на + прежнем месте, удалите в этом файле строку, содержащую + информацию о перемещении.</para> + + <para>Полученные изменения можно проверить командой + <command>Tools/scripts/MOVEDlint.awk</command>.</para> + </sect1> + </chapter> + |