 |
|
|
|
Создаем порт для FreeBSD своими руками. Часть I: основные возможности
Создаем порт для FreeBSD своими руками Часть I: основные возможности Автоматизированная система сборки стороннего программного обеспечения из исходных текстов (система портов) – это то, чем по праву гордится FreeBSD. Система содержит ссылки на десятки тысяч программ, и этот список постоянно пополняется. Кто их создает – эти пополнения – некие выдающиеся специалисты? Да вовсе нет. Вы тоже сможете стать одним из них. Споры о том, что правильнее – собирать программы руками или использовать для этого порты, в эхоконференции FidoNet RU.UNIX.BSD не утихают никогда. Они могут стихнуть на время, но затем кто-нибудь снова задаст такой вопрос, и они разгораются с новой силой. И рано или поздно каждый приходит к мнению, что использовать порты удобнее, потому что:
Основные моменты того, как устроена система портов и как с ней эффективно работать, изложены в [1], здесь я приведу только ее краткое описание, необходимое для понимания статьи. Система портов или «коллекция портов» представляет из себя древовидную структуру каталогов, которая обычно размещается в /usr/ports. Имена каталогов первого уровня (находящиеся непосредственно в /usr/ports) образуют наименования «категорий», то есть тематических групп. Например, есть категория mail, в которую входят все программы, связанные с обработкой электронной почты, есть категория dns и т. д. Решение о создании новой категории принимает FreeBSD Team, которая создает на первичных зеркалах новый каталог, переносит в него нужные порты, откуда изменения расходятся по вторичным зеркалам и обычным серверам. Перед тем как приступить к созданию порта, необходимо решить, к какой категории относится программа, которую предстоит внести в дерево портов. Имена категорий и их краткое описание приведено в [2]. Внутри каталога категории размещаются непосредственно порты – по одному в каждом отдельном каталоге. Такая структура несколько замедляет навигацию, когда в каталоге находится много файлов, и именно поэтому постоянно появляются новые и новые категории. Из чего, собственно, состоит порт для FreeBSD? Порт для FreeBSD состоит из нескольких файлов, которые сами по себе ничего не делают. Даже несмотря на то, что один из них называется Makefile, все они представляют из себя файлы данных – описания и определения некоторых переменных, используемых системой портов в качестве исходных данных. Механизм работы системы давным-давно отлажен, в простейшем случае необходимо только задать исходные данные. Ниже приводится список файлов, которые необходимы для порта (на самом деле порт может использовать и другие файлы, но они не являются необходимыми):
WWW: http://this.insert.link/~homepage Author: John J. Smith <jsmit@someserver.tld>
Итак, что понадобится для того, чтобы приступить к созданию своего собственного порта?
Первый порт – несложная программа для KDE Мы не будем заниматься искуственными примерами. В качестве примера первого порта возьмем несложную программу для KDE, взятую с сайта http://www.kde-apps.org. Почему именно для KDE? Сообщество разработчиков KDE огромно, программы появляются, развиваются, а потом перестают поддерживаться и развиваться постоянно, причем большинство их авторов из Европы, работающие в той или иной версии Linux и даже и не подозревающие, что их программа может работать и в другой операционной системе, и ситуация, когда на KDE applications находится интересная и нужная программа, – это совершенно обычная ситуация. Итак, в качестве примера возьмем программу, которая позволяет встроить в панель KDE выпадающее меню с содержимым адресной книги. Программа так и называется – «Contacts menu for Kicker». Подробное ее описание приведено в [3]. Факт успешной сборки программы уже проверен, программа установлена, и протокол установки сохранен в файле, то есть была выполнена команда: # make install >& install.log В данном примере для перенаправления в файл и обьединения выводов stdout и stderr используется синтаксис tcsh, в sh необходимо выполнить: # make install > install.log 2>> install.log Начинаем. Сразу же необходимо иметь в виду, что существует довольно жесткий порядок, в котором в файле Makefile должны появляться определения переменных. В нижеследующем примере приводится правильный порядок и нарушать его не рекомендуется. Файл Makefile В соответствии с рекомендациями [4] Makefile должен иметь следующий заголовок: # New ports collection makefile for: contactsmenu # Date created: 01 Mar 2006 # Whom: Rashid N. Achilov <shelton@granch.ru> # # $FreeBSD$ На этом заголовок кончается. Внимание! Для впервые отправляемого порта строка $FreeBSD$ должна выглядеть именно так, как показана! Первыми строками, идущими за заголовком, должны быть следующие: PORTNAME= contactsmenu PORTVERSION= 0.3.4b CATEGORIES= mail kde Эти три переменные должны идти первыми и именно в том порядке, в котором они приведены. Первая из них задает имя порта. Она должна совпадать с именем каталога с файлами порта. Вторая задает номер текущей версии программы. Именно по ней будет проводится сравнение существующей и установленной версий. Третья перечисляет список категорий, к которым относится данный порт. Выбор категории, а также требования к составлению данного списка приведены в [2]. MASTER_SITES= http://www.kde-apps.org/content/files/ Эта переменная должна идти сразу после CATEGORIES. Она задает список сайтов, с которых будет скачиваться дистрибутив программы. Имя дистрибутивного файла по умолчанию формируется как ${PORTNAME}-${PORTVERSION}${EXTRACT_SUFX}. EXTRACT_SUFX же по умолчанию равен «.tar.gz», если не указано явно, каким архиватором упакован дистрибутив. Явно задать архиватор можно с помощью переменных «USE_BZIP2=YES» для архиватора Bzip2 и «USE_ZIP=YES» для архиватора Zip. Эти переменные должны быть заданы ниже, в секции, где группируются все переменные USE_*. Откуда взять имя дистрибутива и адрес домашнего сайта проекта? Как правило, первоначальная закачка файла производится вручную, следовательно, имя файла и URL исходного сайта всегда можно найти в логах программ, которыми он закачивался. Можно использовать для этого и другие методы, которые я не буду здесь описывать ввиду их чрезвычайно большого разнообразия. Таким образом, если бы имя дистрибутивного файла нашей программы было contactsmenu-0.3.4b.tar.gz, нам бы больше ничего не потребовалось указывать – вся информация для загрузки уже предоставлена. Но не все так просто, потому что имя нашего файла – 34479-contactsmenu-0.3.4b.tar.bz2. Что делать? Для таких случаев предусмотрено принудительное задание имени дистрибутивного файла, которое должно быть полным, то есть DISTNAME= 34479-${PORTNAME}-${PORTVERSION} Включив в нижеследующие секции «USE_BZIP2=YES» мы сформировали полное имя дистрибутивного файла. Для многих популярных URL типа www.apahe.org, sourceforge.net, www.kde.org и пр. определены специальные макросы, в которых перечислены все URL, на которых можно найти данную программу. Например, если бы данная программа располагалась на сайте sourceforge.net, то строка MASTER_SITES была бы заменена следующей комбинацией: MASTER_SITES= ${MASTER_SITE_SOURCEFORGE} MASTER_SITE_SUBDIR= contactsmenu что означало бы загрузку файла с сайтов, входящих в заранее определенный список из подкаталога contactsmenu. MAINTAINER= shelton@granch.ru COMMENT= KDE 3.x addressbook Kicker applet Эти строки должны идти в том порядке, в котором приведены. MAINTAINER задает адрес электронной почты лица, которое создало и управляет данным портом. COMMENT содержит краткое (одну строчку) описание данного порта. Внимание! При использовании нескольких адресов электронной почты в поле MAINTAINER должен быть проставлен тот адрес, который будет указан в поле From: во время отправки подготовленных файлов порта командой send-pr. Если в поле MAINTAINER будет указан один адрес, а обновления порта пойдут с другого адреса, придется дополнительно подтверждать, что данное письмо отправлено именно майнтайнером порта, а не является подделкой. USE_KDEBASE_VER= 3 USE_GMAKE= yes USE_BZIP2= yes Начинается секция переменных USE_*. Здесь, как правило, перечисляются неявные зависимости, заранее определенные в системе. USE_KDEBASE задает зависимость порта от пакета kdebase3, USE_GMAKE – от пакета gmake, USE_BZIP2 – от пакета bzip2 (и заодно устанавливает EXTRACT_SUFX в «.tar.bz2»). Что означает «порт Х зависит от порта Y»? Это означает, что в соответствии с тем, к какому типу будет отнесена данная зависимость (EXTRACT_DEPENDS, RUN_DEPENDS и т. д., см. bsd.port.mk для полного списка), то на данном этапе построения порта (extract, install и т. д.) система проверит наличие установленного пакета, который указан как зависимость, и если он не установлен, система автоматически перейдет к его установке. В этом проявляется еще одно преимущество системы портов – имея скоростной канал в Интернете и дешевый трафик, можно не думать, например, о том, какие файлы нужны для установки KDE – достаточно перейти в каталог x11/kde и набрать make. Построение правильного списка зависимостей – одна из задач автора порта. Если указать ненужные программы – порт будет пытаться их поставить, что будет забивать систему мусором, если же забыть нужные – порт в лучшем случае не соберется, в худшем – соберется и не будет работать. GNU_CONFIGURE= yes CONFIGURE_ARGS += --with-qt-dir=${QT_PREFIX} \ --with-extra-includes=${LOCALBASE}/include \ --with-extra-libs=${LOCALBASE}/lib Эти строки должны присутствовать (если они есть) после всех переменных USE_*. Они определяют, что для создания Makefile, управляющего сборкой программы, будет использоваться configure, и задают дополнительные аргументы, передаваемые при вызове configure. При сборке программы configure получает неявные параметры, задаваемые, например, с помощью PREFIX, но может получать и явные параметры, перечисляемые выше. Ну и последней строкой нашего Makefile обязательно должна быть: .include <bsd.port.mk> которая, собственно, и загрузит основной файл. Вот и все, файл, управляющий сборкой программы создан. Файл pkg-plist Файл составляется как раз на основе протокола инсталляции install.log, который был сохранен во время установки программы. Следует также учесть, что программы для KDE часто используют локальные скрипты libtool, которые устанавливают динамические библиотеки, используя свои собственные конфигурационные файлы с расширением .la. Поэтому, если в протоколе установки упоминается, например, kickermenu_contactsmenu.la, нужно открыть его (это текстовый файл) и посмотреть, какая же библиотека там используется. Как правило, ее имя совпадает с именем .la файла (в нашем случае kickermenu_contactsmenu.so), но могут быть отличия, в частности, файлов может быть несколько. В файл pkg-plist компоненты программы вписываются по одному в строке, с указанием пути относительно корня установки (по умолчанию /usr/local). То есть в нашем случае: lib/kde3/kickermenu_contactsmenu.so lib/kde3/kickermenu_contactsmenu.la share/apps/kicker/menuext/contactsmenu.desktop share/locale/bg/LC_MESSAGES/libkickermenu_contactsmenu.mo share/locale/br/LC_MESSAGES/libkickermenu_contactsmenu.mo share/locale/da/LC_MESSAGES/libkickermenu_contactsmenu.mo share/locale/de/LC_MESSAGES/libkickermenu_contactsmenu.mo share/locale/ga/LC_MESSAGES/libkickermenu_contactsmenu.mo share/locale/fr/LC_MESSAGES/libkickermenu_contactsmenu.mo share/locale/pt/LC_MESSAGES/libkickermenu_contactsmenu.mo share/locale/sv/LC_MESSAGES/libkickermenu_contactsmenu.mo то есть одна динамическая библиотека, один файл .desktop и восемь файлов локализации. Тут надо заметить, что, как правило, с файлами локализации в KDE сплошная морока – их бывает по 20-30 шт. Но пропустить, случайно или намеренно, какой-либо файл нельзя – порт будет впоследствии отослан на тестирование во FreeBSD Team, где проверят все этапы его установки и удаления, и если после удаления в каталоге будут обнаружены оставшиеся файлы, то майнтайнер порта получит сообщение об ошибке, не устранив которую, он никогда не увидит своего порта принятым. Во второй части файла pkg-plist перечисляются команды, которые необходимо выполнить системе при деинсталляции программы. Как правило, это команды удаления каталогов, которые могли быть созданы в процессе инсталляции. Если в команде упоминается каталог, который к моменту выполнения деинсталляции непустой – он не будет удален. @dirrm share/locale/bg/LC_MESSAGES @dirrm share/locale/bg @dirrm share/locale/br/LC_MESSAGES @dirrm share/locale/br @dirrm share/locale/da/LC_MESSAGES @dirrm share/locale/da @dirrm share/locale/de/LC_MESSAGES @dirrm share/locale/de @dirrm share/locale/ga/LC_MESSAGES @dirrm share/locale/ga @dirrm share/locale/fr/LC_MESSAGES @dirrm share/locale/fr @dirrm share/locale/pt/LC_MESSAGES @dirrm share/locale/pt @dirrm share/locale/sv/LC_MESSAGES @dirrm share/locale/sv Опять упоминаются в основном каталоги для сообщений, потому что их могло и не быть. Здесь опять же нельзя пропустить ни одного каталога, который создается исключительно данной программой и больше никем не используется. Файл pkg-descr Как уже говорилось выше, это просто текстовый файл с небольшим описанием того, что делает данная программа. Чтобы не сочинять самому описание, в нашем случае мы просто берем описание, приведенное автором на странице kde-apps и заносим его в этот файл, сопровождая ссылкой на собственно страницу программы (файл см. на сайте журнала в разделе «Исходный код»). На этом этап первоначального формирования файлов можно считать законченным. Мы еще не сформировали distinfo, но он формируется автоматически после того, как порт будет проверен. Переходим к проверке порта. Для проверки правильности написания файлов порта существует специальная программа portlint, которую необходимо установить каждому, кто собирается заниматься разработкой собственных портов. Это небольшой скрипт, написанный на языке Perl, устанавливается он из devel/portlint: # cd /usr/ports/devel/portlint # make all install После установки запускаем portlint в текущем каталоге с ключами, которые включают все возможные проверки: # portlint –abvtAN
Здесь приведена часть вывода portlint, в которой выводится замечание. В последней строке приводится итог – сколько ошибок и сколько замечаний было обнаружено. Отмечу сразу, что необходимо добиться устранения всех ошибок и желательно всех замечаний. В данном случае portlint предупреждает о том, что устанавливаются файлы сообщений gettext, но в порт не включено неявной зависимости от devel/gettext (это может привести к невозможности работы с данными файлами). Для исправления данной ситуации добавляем в секцию USE_* строку «USE_GETTEXT=YES» и повторно запускаем portlint. # portlint –abvtAN
Что нам советуют сейчас? Добавить поддержку параметра WITHOUT_NLS для тех, кто не хочет устанавливать файлы языковых сообщений и увеличить количество зеркал, на которых размещен данный файл. Здесь надо заметить, что любой дистрибутив порта после его принятия в систему дополнительно зеркалится на сайте проекта FreeBSD, так что замечание о дополнительных зеркалах мы игнорируем, а вот замечание о WITHOUT_NLS исправим. Для этого добавим в Makefile следующий код: .if defined(WITHOUT_NLS) PLIST_SUB+= NLS="@comment " .else USE_GETTEXT= yes PLIST_SUB+= NLS="" .endif а в файле pkg-plist изменим строки, описывающие файлы языковой поддержки таким образом: %%NLS%%share/locale/bg/LC_MESSAGES/libkickermenu_contactsmenu.mo %%NLS%%share/locale/br/LC_MESSAGES/libkickermenu_contactsmenu.mo %%NLS%%share/locale/da/LC_MESSAGES/libkickermenu_contactsmenu.mo %%NLS%%share/locale/de/LC_MESSAGES/libkickermenu_contactsmenu.mo %%NLS%%share/locale/ga/LC_MESSAGES/libkickermenu_contactsmenu.mo %%NLS%%share/locale/fr/LC_MESSAGES/libkickermenu_contactsmenu.mo %%NLS%%share/locale/pt/LC_MESSAGES/libkickermenu_contactsmenu.mo %%NLS%%share/locale/sv/LC_MESSAGES/libkickermenu_contactsmenu.mo Как это будет работать? Параметр PLIST_SUB содержит список подстановок, которые выполняются, когда система обрабатывает файл pkg-plist. Если при сборке порта будет задан параметр «WITHOUT_NLS=yes», то в pkg-plist будет подставлено значение, превращающее строки с «%%NLS%%» в строки комментария. Обратите внимание, что в этом случае зависимость от devel/gettext не вставляется. В противном случае NLS принимает значение пустой строки, и зависимость от devel/gettext вставляется. Этот прием (модификация pkg-plist в зависимости от параметров сборки порта) является очень широко распространенным. Запускаем portlint еще раз, получаем одно замечание про MASTER_SITES, которое игнорируем. Осталось создать файл distinfo. Это просто. Система сама его создаст, если ее об этом попросить: # make makesum Созданный файл имеет следующий вид:
Теперь пробуем собрать программу, используя порт. Для проверки правильности составления файла pkg-plist в качестве корневого каталога сборки назначим /tmp/1 (после деинсталляции программы не должно оставаться файлов или каталогов, которые она создает). # make PREFIX=/tmp/1
Вот мы и получили первую ошибку. Она связана с некоторой бестолковостью имен дистрибутивных файлов на http://www.kde-apps.org, когда сам файл имеет имя с числом впереди, а каталог, упакованный внутри него, – без этого числа. Для решения этой проблемы следует указать системе, что имя каталога, в которую будет распакован дистрибутив, будет задано вручную. После (!!) переменной MAINTAINER впишем следующую строчку: WRKSRC= ${WRKDIR}/${PORTNAME}-${PORTVERSION} указывая таким образом, что дистрибутив будет распакован в каталог с именем, состоящим из имени и номера версии пакета. Повторяем сборку. Сборка проходит нормально. Запускаем установку. Видим, что в каталоге /tmp/1 появились все нужные файлы. Создаем пакет с помощью pkg_create (хотя можно то же самое проделать через make package): # cd /var/db/pkg # pkg_create -b contactsmenu-0.3.4b Проверяем файл +CONTENTS внутри архива – под каждой строчкой, описывающей файл программы, должна располагаться строчка комментария с контрольной суммой:
Если такой строчки нет – значит, в файле pkg-plist ошибка – при установке файл не был найден. Это может быть тривиальная опечатка или же ошибка в Makefile, при которой в pkg-plist был вставлен файл, отсутствующий в данной конфигурации. Проверяем удаление пакета через plg_delete (или make deinstall в каталоге порта). При удалении не должно выдаваться сообщений о том, что файл не найден. Если такие сообщения выдаются, значит файл pkg-plist содержит ссылки на файлы, которые на самом деле не были установлены. Ну вот, все проверки проделаны. Что дальше? Последним этапом нашей работы будет отправка порта во FreeBSD Team и получение оттуда ответа об успешном помещении его в дерево портов или сообщение об ошибке. Порядок действий при этом такой:
В этом сообщении всегда указывается причина ошибки и диагностика. Все общение с FreeBSD Team происходит, естественно, на английском языке, несмотря на то, что есть и русскоязычные коммиттеры (например, письмо, приведенное выше, получено от Кирилла Пономарева (mailto:krion@freebsd.org). Сообщение об успешном помещении в дерево портов может выглядеть так:
После чего останется только обновить дерево портов и убедиться, что да, на самом деле порт в нем присутствует. С этого момента майнтайнер порта отвечает за его актуальное состояние – своевременное обновление в соответствии с новыми версиями программы, внесение нужных патчей и удаление устаревших. Как скоро ожидать ответа от FreeBSD Team? На этот вопрос трудно дать определенный ответ. Иногда они реагируют буквально в течение недели, а иногда приходится ждать несколько месяцев. Внесения в дерево своего первого порта, kavmilter, я ждал больше года, а например, spassgen прошел за неделю. Кроме того, FreeBSD Team временами самостоятельно вносит некоторые изменения в файлы портов, когда проводится какая-либо глобальная модификация системы в целом. Если вдруг по каким-либо причинам порт перестанет собираться, майнтайнеру будет отправлено соответствующее извещение. Если майнтайнер не устранит ошибку и не пришлет соответствующий патч, исправляющий ситуацию, порт может быть помечен как BROKEN. Как правило, порты, помеченные как BROKEN, удаляются из дерева если они находятся в таком состоянии более 3 месяцев. Заключение Вот и готов наш первый порт. Он вышел чрезвычайно простым, мы не затронули и пятой части возможностей системы сборки портов. Но мы сделали одну чрезвычайно важную работу – убедились в том, что круг программного обеспечения, который может работать под FreeBSD вовсе не ограничивается тем, что присутствует в каталоге портов (несмотря на то, что на текущий момент там присутствует более 14000 программ), и в том, что создать порт под FreeBSD своими руками – это не такая уж и сложная задача. В следующей статье мы задействуем более сложные возможности системы – многофайловые дистрибутивы, экран опций, перехват управления при сборке, использование внешних патчей... Ссылки и литература:
|
РАШИД АЧИЛОВКомментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
