Сборка пакетов. Глава 2. DEB. Часть 1. Общие понятия.
Deb
пакеты используются в таких популярных дистрибутивах, как Debian и
Ubuntu. В отличии от различных RPM-base дистрибутивов структура этих
пакетов нисколько не отличается друг от друга. По этому будет совсем не
сложно пересобрать пакет из одного дистрибутива под другой.
Deb-пакет представляет собой gzip-архив, а также скрипты и дополнительные файлы. Вот типичный пример названия пакета:
liferea_1.2.18-0ubuntu1_amd64.deb
Как
мы видим имя пакета отделяется от версии символом подчёркивания, также
как и архитектура пакета. Через символ ”-” указывается некоторое
подобие release, хотя точного понятия, как в RPM для него не существует.
Архитектуры
бывают i386 (как в rpm), amd64 (64-х битный пакет, названный в честь
первых процессоров AMD), all (тоже что noarch в RPM, независимый от
архитектуры), powerpc, а также различные экзотические архитектуры,
которые я приводить не буду.
Думаю будет полезно провести
некоторое поверхностное сравнение RPM и DEB. Отличий много, однако со
стороны конечного пользователя они будут не так заметны. Вообще когда
за нас кто-то всё делает (причём качественно), всё хорошо. Как только
мы начинаем пытаться делать что-то сами — все плохо.
Итак, самой
известной отличительной чертой Deb является наличие мягких зависимостей
(Recomends и Suggest). Многие пользователи видят в этом
сверхестественную силу и мощь DEB, хотя что с этими зависимостями
делать дальше, вероятно, они не знают. Apt-get не умеет обрабатывать
их, Aptitude умеет при помощи двух опций в настройках apt:
Код Aptitude::Recommends-Important "true"; Aptitude::Suggests-Important "true";
В
любом случае в мягкие зависимости прописываются пакеты, без которых наш
пакет работать будет в любом случае. И на мой взгляд абсолютно все
равно жёсткая зависимость или мягкая, так как мы либо ставим все пакеты
из Recomends или Suggest, либо не ставим ничего, либо система будет
чистенькая с урезанными функциями некоторых пакетов, либо грязненькая с
кучей всевозможных пакетов.
Вторым полезным отличием является возможность указания в зависимостях логического или.
Код Depends: debootstrap | cdebootstrap
В
RPM подобная проблема исправлялась добавлением Provides в пакет, от
которого зависит собираемый пакет. Однако гораздо проще сделать так,
как это делается в DEB.
Ещё в качестве полезности можно выделить
вот что. Все скрипты и служебные файлы лежат в каталоге
/var/lib/dpkg/info/. Так что мы можем быстро на них взглянуть, а не
мучится с различными командами.
Собственно на этом все. По Deb
пакету нельзя определить на какой машине он был собран, у пакета нет
различных макросов, как в RPM.
В общем как видно, преимущества и
недостатки одного и другого довольно сомнительны. Но это только по
отношению к конечному пользователю. Как только мы начинаем собирать
свой собственный пакет (почти с нуля), недостатки Deb становятся более
очевидными.
К ним можно отнести:
1. Множество файлов конфигурации (против 1-го spec у rpm); 2. Множество служебных dh_* команд, которые не совсем понятно что делают; 3. Исходник идёт не одним файлом, а 2-я, 3-я; 4. Сложность в накладывании патчей; 5. Возможность делать одно и тоже несколькими разными способами.
Внутренний язык dh_make тоже не делает сборку особо привлекательной.
Отдельно
хочется сказать о цифровой подписи к пакету. Сам Deb пакет, в отличии
от RPM, не подписывается, а подписываются различные текстовые файлы,
содержащие контрольные суммы. В конечном счёте все доходит до подписи
Release.gpg в репозитории. Так что если вы каким-либо образом подсунете
в главный репозиторий левый пакет, то идентифицировать его подлинность
будет невозможно. Более того, обычно для подписи самого репозитория
используется ключ с пустым паролем.
Хотя пакеты для
Debian и Ubuntu и лежат все в одном месте, но из-за различных
репозиториев и системы pool найти что-либо бывает сложно. Я рекомендую
воспользоваться соответственно сайтами http://packages.debian.org/ и
http://packages.ubuntu.com/. На них вы сможете легко понять, к какому
дистрибутиву, какой пакет относится.
В следующей части мы поговорим о сборке Deb-пакетов.
Автор: Juliette Oct 15 2008, в 15:09
Сборка пакетов. Глава 2. DEB. Часть 2. Сборка пакетов
В этой статье мы научимся собирать .deb пакеты, а также подписывать их.
Для сборки пакета нам понадобятся debhelper, dh-make, devscripts, fakeroot,
а также необходимые компиляторы и интерпретаторы. Кроме того нам нужна
программа, которую будем компилировать. Сам тарбол нам как бы и не
нужен, нам нужно только дерево исходников, которое необходимо
распаковать. Главный каталог должен называться следующим образом: имяпакета-версияпакета, в противном случае возникнут проблемы.
В
итоге у нас должны получиться бинарные файлы, исходник *orig*tar.gz,
*diff*gz* и файлы .dsc и .changes. Возможно обойтись без файлов
*orig*tar.gz и *diff*gz* заменив их одним тарболом, в котором находятся
все служебные файлы, однако начиная с версии Debian 4.0 подобные
ухищрения не приветствуются.
Итак, я для удобства рекомендую
создать в вашем домашнем каталоге папку, допустим, BUILD, в ней для
каждого пакета создавать каталог по его имени, и уже внутри последнего
каталога размещать дерево исходников. Для чего так сложно? Потому, что
собранные пакеты будут помещаться на уровень выше дерева и у вас скоро
весь каталог BUILD забьётся кучей файлов.
Если вы хотите использовать Цифровую подпись, то необходимо добавить в ваш файл .bashrc следующие строки:
Код export EMAIL=your@gpg.email export DEBFULLNAME="YOUR GPG NAME" export DEBEMAIL=your@gpg.email Имя
и почтовый адрес должны быть такими же, какими вы их задали при
создании GPG ключа. Если вы создали ещё и описание, то его тоже
необходимо указать в переменной DEBFULLNAME. Итак, для начала
необходимо создать служебные файлы. Для этого нужно зайти в каталог
исходников и отдать команду dh_make --createorig. Вам необходимо
выбрать нужный тип пакета. Если у вас будет только один бинарный пакет,
то нажимаем s, если несколько — то l. Для модулей ядра нужно выбрать k. О cdbs ( b) мы поговорим как-нибудь потом. Можете также вызывать команду dh_make вместе с ключом -c чтобы указать лицензию пакета. Мы
сперва рассмотрим пакет, содержащий несколько бинарников (то, что
обычно ни в каких документациях не рассматривается). А потом скажем
несколько слов относительно single binary. После запуска
dh_make создастся каталог debian, в котором будет лежать довольно
большое количество файлов. Все файлы *.ex и *.EX можно в принципе
удалить сразу и создавать только по мере надобности. В файле control
указываются все необходимые параметры. Он делится на секции Source и
Package. Секций Package может быть несколько в зависимости от того
сколько бинарных пакетов получится при сборке. Ниже приведён пример
файла control для пакета liferea: CODE Source: liferea Section: gnome Priority: optional Maintainer: Franz Pletz <fpletz@franz-pletz.org> Uploaders: Luis Rodrigo Gallardo Cruz <rodrigo@nul-unu.com> Build-Depends: autotools-dev, debhelper (>> 4.0.0), libgtkhtml2-dev Standards-Version: 3.7.2.0
Package: liferea Architecture: any Depends: ${shlibs:Depends}, ${misc:Depends}, liferea-xulrunner (=${Source-Version}), dbus-1-utils Description: feed aggregator for GNOME Liferea is a simple FeedReader clone for GNOME. It is a reader for RSS/RDF feeds which also supports CDF channels, Atom/Echo/PIE feeds and OCS directories. . Liferea is an abbreviation for Linux Feed Reader. . Homepage: http://liferea.sourceforge.net/
Package: liferea-xulrunner Architecture: any Depends: ${shlibs:Depends}, ${misc:Depends} Provides: liferea-mozilla, liferea-gtkhtml Conflicts: liferea-mozilla (<< 1.0.17-1), liferea-gtkhtml (<< 1.0.27-2) Replaces: liferea-mozilla (<< 1.0.17-1) Description: xulrunner-based rendering library for Liferea Liferea is a simple FeedReader clone for GNOME2. It is a reader for RSS/RDF feeds which also supports CDF channels, Atom/Echo/PIE feeds and OCS directories. . Liferea is an abbreviation for Linux Feed Reader. . Homepage: http://liferea.sourceforge.net/
Package: liferea-mozilla Architecture: all Depends: liferea-xulrunner Description: transitional dummy package Previous versions of liferea had several rendering engines to choose from. This is a dummy package to ease transition from those versions. . It can be safely removed from your system after updating.
Package: liferea-gtkhtml Architecture: all Depends: liferea-xulrunner Description: transitional dummy package Previous versions of liferea had several rendering engines to choose from. This is a dummy package to ease transition from those versions. . It can be safely removed from your system after updating. Разберём
его поподробней. Итак, в секции Source указывается имя исходника,
секция (Section), к которой пакет будет отнесён в репозитории, Priority
— приоритет, подробнее смотреть
http://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities.
Maintainer и Uploaders — думаю без вопросов, Build-Depends — пакеты
необходимые при сборке пакета, Standards-Version — версия документа
Debian-Policy (не нужно трогать). Далее идёт описание для
бинарного пакета, Packages — его имя, Architecture: архитектура пакета,
может быть any (сама превратится в нужную платформозависимую
архитектуру) и all (платформонезависимую), Depends — зависимости
которые обязательно требуются для установки пакета (благодаря двум
переменным в этом поле зависимости появятся автоматически, однако
иногда следует добавлять их вручную), Description — описание пакета,
причём в первой строке используется краткое описание, а в остальных
строках, начиная с пробела, длинное. Новые абзацы отделены строкой с
точкой. По поводу зависимостей. Существуют ещё два типа
зависимостей Suggests и Recommeds. Первый тип зависимостей нацелен на
расширение возможностей нашего пакета, второй настоятельно рекомендует
установить данные пакеты. Aptitude ставит зависимости Recommeds по
умолчанию, apt-get не обрабатывает ни те, ни другие. Существуют также
Pre-Depends, но их использовать не рекомендуется. В зависимостях
могут применяться указания версий, как видно из примера. Допустимыми
символами сравнения являются: <<, <=, =, >=, и >> для
"строго раньше чем”, "раньше или равно”, "в точности равно”, "равно или
позже” и "строго позже чем” соответственно. Также в control
файле могут применяться следующие теги: Provides — дополнительное имя
для нашего пакета (эдакое виртуальное), Replaces — список пакетов,
которые будут удалены после установки нашего пакета, Conflicts — пакеты
с которыми наш пакет заведомо конфликтует. Вторым по важности файлом является файл rules.
Именно в нем находится все необходимое для компиляции пакета и упаковки
его в бинарные пакеты. Этот файл есть ничто иное, как скрипт make, с
использованием команд dh_*. В нем действительно много секций, и
много строк, но нам нужно будет изменять секции config.status, build и
install. В этих секциях, соответственно, необходимо прописать команды
для конфигурации пакета (если они нужны), для его сборки и для
установки. Если мысленно выкинуть всевозможные dh-команды, то скрипт
становится не таким уж страшным. Правда dh-команды разумеется нужны.
Ниже приведен файл rules: CODE #!/usr/bin/make -f # Sample debian/rules that uses debhelper. # GNU copyright 1997 to 1999 by Joey Hess.
CFLAGS = -g -O2
ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) INSTALL_PROGRAM += -s endif
config.status: configure dh_testdir cp -f /usr/share/misc/config.sub config.sub cp -f /usr/share/misc/config.guess config.guess CFLAGS="$(CFLAGS)" ./configure --prefix=/usr \ --mandir=\$${prefix}/share/man \ --sysconfdir=/etc --disable-gecko \ --disable-gtkhtml2 --enable-sm ln -s $(CURDIR)/liferea.1 $(CURDIR)/debian/liferea-bin.1 ln -s $(CURDIR)/liferea.1 $(CURDIR)/debian/liferea-add-feed.1
build: build-stamp
build-stamp: config.status dh_testdir $(MAKE) touch build-stamp
clean: dh_testdir dh_testroot rm -f build-stamp config.log debian/liferea-bin.1 \ debian/liferea-add-feed.1 -$(MAKE) distclean
dh_clean
install: build dh_testdir dh_testroot dh_clean -k dh_installdirs GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1 $(MAKE) install \ DESTDIR=$(CURDIR)/debian/liferea # add the debian menu icon cp debian/liferea.xpm debian/liferea/usr/share/liferea/pixmaps/ # Link documentation mkdir -p debian/liferea/usr/share/doc/liferea ln -s ../../liferea/doc/html debian/liferea/usr/share/doc/liferea/html dh_movefiles --sourcedir=debian/liferea
# Build architecture-independent files here. binary-indep: build install # We have nothing to do by default.
# Build architecture-dependent files here. binary-arch: build install dh_testdir dh_testroot dh_installchangelogs ChangeLog dh_installdocs dh_installman debian/liferea-bin.1 debian/liferea-add-feed.1 dh_installmenu dh_gconf dh_link dh_strip dh_compress dh_fixperms dh_installdeb dh_shlibdeps dh_gencontrol dh_md5sums dh_builddeb
binary: binary-indep binary-arch .PHONY: build clean binary-indep binary-arch binary install Вообще
при сборке deb-пакета следует привыкать к тому, что одно и тоже можно
делать разными способами, что разумеется не упрощает задачу. Рассмотрим
основные строки из файла rules. В секции config.status идет
обычный запрос на конфигурацию пакета. Обратите внимание, что вам
необходимо правильно задавать каталоги, так как по умолчанию configure
выбирает /usr/local. Секция build вызывает секцию build-stamp, в
которой происходит обычный make ($(MAKE) = make). Затем
выполняется install. Там идет обычный make install и дополнительные
команды для правильной установки данного пакета. Заметьте, что
инсталляция происходит в каталог $(CURDIR)/debian/liferea, где
$(CURDIR) каталог дерева исходников. Теперь одна из важных вещей. Нам
необходимо разобрать файлы из общего каталога liferea по нашим бинарным
пакетам. Именно для этих целей и служит команда dh_movefiles. В
качестве параметра указывается каталог в который была произведена
инсталляция. Если вы инсталлировали пакет в каталог
$(CURDIR)/debian/tmp, то никаких параметров dh_movefiles передавать не
нужно. Все данные о том какие файлы в какие пакеты положить dh_movefiles берёт из файлов (в каталоге debian) название-бинарного-пакеты.install.
Создайте их столько же, сколько будет бинарных пакетов и пропишите в
них названия файлов с полным путём относительно каталога в который была
установлена программа, но без первого слеша. Можно использовать маски. После
разбора файлов выполняется секция binary-arch, которая создаёт
deb-пакет. В ней, например, видно, как устанавливаются man файлы. В
deb-пакете также могут присутствовать скрипты postinst, preinst, postrm
и prerm, которые выполняются соответственно, после инсталляции, перед
инсталляцией, после удаления и перед удалением. Для каждого из пакетов
необходимо создать файл имя-бинарного-пакета.postinst и т. п. в них можно разместить любые команды. Теперь рассмотрим changelog.
Именно в нем мы будем указывать версию нашего пакета. Версией в Debian
называется все, что идёт после имени пакета. В deb нет тегов release и
epoch как в rpm, однако вы можете запросто задать что-то наподобие
3:1.0.4-15.feisty.0. До ":" идёт эпоха, после "-" идёт релиз. Файл
changelog следует редактировать при помощи команды dch. Если её вызвать
без параметра, то будет изменена последняя запись в changelog, а если
dch -i, то будет добавлена новая: Код liferea (1.0.27-2) unstable; urgency=low
* Remove the GtkHTML rendering plugin. This plugin is basically unusable on 64bit architectures. liferea-gtkhtml is now just a dummy package for upgrades (Closes: #379900, #407152, #361376, #368866). * Remove upstream's NEWS file, it contains only version release dates.
-- Luis Rodrigo Gallardo Cruz <rodrigo@nul-unu.com> Sun, 11 Feb 2007 21:18:16 -0600 Также
в changelog вы можете менять принадлежность пакета к дистрибутиву
(сразу после версии). В данно примере идёт unstable, в Ubuntu там
должно быть что-то типа feisty, edgy и т. п. Что касается single binary
то там все намного проще. После команды dh_make, вам нужно подправить
control и changelog. Возможно немного rules. И далее пакет соберётся
сам собой. Для сборки пакета нам понадобится команда debuild
которую следует отдавать всё в том же каталоге исходников. После того,
как пакеты соберутся, вы должны будете подписать пакет (если настроили
GPG), вернее не пакет, а два текстовых файла, которые появятся в
процессе сборки. Это файлы .dsc и .changes. Первый из них несёт
информацию об исходнике, второй нужен только для помещения пакета в
репозиторий. У debuild есть параметр clean, который позволяет очистить дерево исходников и папку debian от ненужных файлов. В
этой статье я попытался передать основные принципы сборки deb пакетов,
однако прекрасно понимаю, что нюансов здесь очень много, но описать их
все я конечно же не смогу. Вам возможно следует почитать
http://www.debian.org/doc/maint-guide/, в котором некоторые аспекты
изложены поподробней, а также http://www.debian.org/doc/debian-policy/.
В следующей статье мы поговорим о том, как создавать репозитории для
rpm и deb пакетов.
Автор: Juliette Oct 15 2008, в 16:06
Сборка пакетов. Глава 2. DEB. Часть 3. Накладывание патчей
Как
и в RPM, в deb-пакетах можно накладывать патчи, однако это довольно
трудоёмкий и неочевидный процесс. И как всегда это можно делать разными
способами. Рассмотрим один из них, dpatch (нам понадобится одноимённый
пакет), на примере пакета liferea.
Первым делом нам нужно будет
создать сам патч. Для этого, как и в случае с RPM, необходимо иметь два
каталога исходников. Первый оригинальный, например,
liferea-1.4.3b.orig, второй с изменениями liferea-1.4.3b. Патч
накладывается командой
Код diff -urN liferea-1.4.3b.orig liferea-1.4.3b > mypatch.patch Далее необходимо превратить этот патч в формат dpatch. Для этого нужно отдать следующую команду: Код dpatch patch-template -p "01_mypatch" \ "mypatch.patch описание" < mypatch.patch \ > 01_mypatch.dpatch Вторые
кавычки в принципе можно опустить. Далее нужно создать в каталоге
debian подкаталог patches, в который необходимо скопировать наш .dpatch
(или несколько .dpatch’ей). Также нужно создать в этом подкаталоге файл
00list с именами наших .dpatch’ей (каждое имя на новой строке). В нашем случае он будет выглядеть так: Код 01_mypatch Теперь самое главное. В файл rules сразу после шапки нужно вставить строку Код include /usr/share/dpatch/dpatch.make Далее
в секции, которая выполняется перед конфигурацией пакета (обычно это
config.status или если её нет, то build) нужно вставить вызов patch-stampКод config.status: patch-stamp configure К секции clean нужно добавить вызов unpatch, думаю понятно для чего: Код clean: unpatch Также в файл control необходимо добавить зависимость dpatch в поле Build-Depends. После этого можно собирать пакет.
Автор: Juliette Oct 15 2008, в 16:31
Сборка пакетов. Глава 3. Chroot. Mock. Pbuilder
Chroot
— это операция изменения корневого каталога. Собирая пакеты в рабочей
операционной системе, мы можем дойти до такого момента, когда в системе
будет много не нужных библиотек, на которые собираемые пакеты будут
линковаться. Также может возникнуть желание собрать пакет под другой
дистрибутив, например, под Fedora Core 5, а работаем мы в Fedora 7. В
этих случаях целесообразно создать «девственно чистый» образ
дистрибутива и собирать пакеты в нем.
Но как создать такой
образ? Это делается при помощи утилит mock в Fedora и pbuilder в
Debian/Ubuntu. Принцип работы этих утилит следующий. При первом запуске
они создают базовый образ операционной системы с минимальным
количеством пакетов, необходимых для работы. Это делается либо
автоматически (так делает mock) или при помощи определённой команды
(pbuilder). Далее образ запаковывается в архив (mock делает это начиная
с версии 0.7) и при каждой сборке распаковывается. Далее из
репозиториев доставляются необходимые для сборки пакеты и
осуществляется сборка. Собранные пакеты складываются в определённый
каталог.
Как это делается в Fedora В Fedora сборкой в
chroot занимается mock. В каталоге /etc/mock хранятся файлы
конфигураций под разные Fedora и Red Hat. Содержимое этих файлов
немного напоминает конфигурацию репозиториев для YUM. Вы можете
заменить стандартные репозитории на локальные, тогда процесс будет
проходить намного быстрее. Однако если у вас нет выхода в интернет, то
вам придётся каким-либо способом сделать копии репозиториев, указанных
в секциях [group] и [local]. Эти секции нужны для формирования базового
образа.
Вы можете добавить свои репозитории, создав новые
секции. Уж точно вам придётся добавить какой-либо свой репозиторий,
если собираемый пакет зависит от пакетов, отсутствующих в других
репозиториях. Для его создания сложите файлы в какой либо каталог,
например, /var/ftp/pub/fedora/myrepo и натравите на него команду:
Код createrepo /var/ftp/pub/fedora/myrepo после чего добавьте в нужный файл конфигурации следующую секцию: Код [myrepo] name=myrepo baseurl=file:///var/ftp/pub/fedora/myrepo По умолчанию используется конфиг default.cfg, который является символической ссылкой на нужный файл. Сборка
пакета осуществляется из-под пользователя. Поэтому необходимо добавить
себя в группу mock. Для этого добавьте к строке с именем mock в файле
/etc/group после ":" свой логин, например: Код mock:x:495:ashejn Для сборки пакета следует воспользоваться командой: Код mock [-r дистрибутив] пакет.src.rpm В
качестве дистрибутива используется имя файлов из /etc/mock без
расширения .cfg. Если параметр не указан, то используется файл
конфигурации default.cfg. Под архитектурой x86_64 вы также можете собирать приложения для i386. Для этого следует воспользоваться следующей командой: Код setarch i386 mock [-r дистрибутив] пакет.src.rpm У
mock есть по крайней мере один очень полезный параметр. --no-clean
позволяет не очищать (не пересоздавать) chroot перед сборкой, чтобы
сэкономить время. Удобно, если пакет по какой-либо причине не собрался.
Все логи и собранные пакеты будут лежать в каталоге
/var/lib/mock/дистрибутив/result. Mock пока не умеет подписывать
пакеты, что в принципе совсем не критично, так как подпись легко
добавить при помощи rpm --addsign *.rpm. Как это делается в Debian/UbuntuВ
Debian/Ubuntu за сборку пакетов в chroot отвечает pbuilder. В принципе
им можно пользоваться не только в Debian/Ubuntu, так как это всего лишь
набор bash-скриптов. Я собрал этот пакет в Fedora 7 и положил в свой
http://ftp.msiu.ru/pub/fedora/tigro/7/i386/pbuilder-0.169-3.fc7.noarch.rpm.
Теперь под Fedora можно собирать пакеты для всевозможных Debian и
Ubuntu (ставить этот пакет следует при помощи YUM, так как он потянет
за собой другие пакеты). Pbuilder кажется более навороченным, с
кучей параметров, но качество довольно низкое. Первым делом нам
необходимо определится под какой дистрибутив мы хотим собирать пакеты.
В файле /etc/pbuilderrc следует указать путь к базовому образу,
переменная BASETGZ, а также дистрибутив DISTRIBUTION и репозиторий
MIRRORSITE в зависимости от системы Debian или Ubuntu. В принципе все
эти параметры можно передать pbuilder'у через командную строчу. После этого следует создать базовый образ командой: Код /usr/sbin/pbuilder create Для создания базового образа для архитектуры i386 под x86_64 эта команда сильно усложняется: Код /usr/sbin/pbuilder create --debootstrapopts --arch --debootstrapopts i386 Для
пересборки пакета нам необходимо иметь исходные тексты .deb-пакета. В
них входит файл с расширением .dsc. Необходимо отдать команду: Код /usr/sbin/pbuilder build .dsc-файл или для архитекты i386 из-под x86_64: Код linux32 /usr/sbin/pbuilder build .dsc-файл Ф
Fedora вместо linux32 следует использовать setarch i386. Собранный
пакет будет лежать в каталоге /var/cache/pbuilder/result/. Однако
подобная сборка имеет по крайней мере три недостатка: сборка только
из-под root, возможна только пересобрка (а что делать если у нас только
дерево исходников?) и пакет не будет подписан, что в случае с .deb не
так тривиально исправить. Эта проблема решается при помощи команды pdebuild.
Но это опять не сахар. Она не понимает кучи параметров, такие как
--basetgz, --distribution, так что вам под каждый дистрибутив и
архитектуру придётся исправлять конфигурационный файл, однако его можно
создать в домашнем каталоге под именем .pbuilderrc и указать свои
каталоги для сборки (в моей сборке на каталог result стоят права 1777,
так что собирать можно и в стандартные каталоги). Однако
предпочтительнее для каждого дистрибутива создать собственный
конфигурационный файл (как в mock) и передавать pdebuild конфиги через
параметр --configfile файл. Эта команда делает тоже, что и
стандартная для Debin/Ubuntu — debuild. Для подписи пакета необходимо,
чтобы цифровая подпись существовала и вам был известен идентификатор
ключа (gpg --list-key в строке pub после "/"). Для сборки пакета необходимо отдать команду: Код pdebuild [--configfile файл_конфигурации] --auto-debsign --debsign-k keyid при этом необходимо находиться в дереве исходников, в котором находится папка debian с правилами для сборки пакета. После сборки у вас два раза спросят секретную фразу (для подписи двух файлов) и сборка будет завершена. В
Debian/Ubuntu есть пакет mock. Под этими дистрибутивами вы также
сможете собирать пакеты под Fedora. А по чему собственно только под
Fedora? Под любой rpm-дистрибутив, который поддерживает подключение к
репозиториям через YUM. Вам будет необходимо только создать пакеты с
зависимостями для генерации базового образа, что скорее всего не станет
тривиальной задачей. В прочем они могут в том или ином виде уже
существовать.
Автор: Juliette Oct 15 2008, в 16:49
Сборка пакетов. Глава 4. Создание репозитория (основные понятия)
Я
не буду вдаваться в подробности, и уж точно не буду давать пошаговый
howto. В основном расскажу об основных приёмах и правилах.
Для RPM никакого выбора нет. Вам понадобится только пакет createrepo.
Под репозиторий вам необходимо отвести каталог, который будет виден
через http или ftp (если вы хотите использовать репозиторий только
локально, то подойдёт любой каталог). Необходимо создать структуру
репозитория. Например, такую:
Код /var/ftp/myrepo/fedora-7/ /var/ftp/myrepo/fedora-7/i386 /var/ftp/myrepo/fedora-7/SRPMS /var/ftp/myrepo/fedora-7/x86_64 Все
srpm-пакеты нужно складывать в каталог SRPMS, все пакеты noarch
необходимо подкладывать в каждый из каталогов (кроме SRPMS). Пакеты
i686, i586 также кладутся в каталог i386. По правилам Fedora в каталоге
x86_64 могут лежать пакеты i?86 (некоторые системные библиотеки,
используемые для совместимости). Далее необходимо переиндексировать наши репозитории, например, таким элементарным скриптом: Код for i in `ls -Rd /var/ftp/myrepo/fedora-7/*`; do createrepo $i; done После этого нужно подключить эти репозитории к менеджеру пакетов YUM (или APT-RPM, или Smart). Если
у вас возникает необходимость в удалении старых пакетов из репозитория,
то необходимо воспользоваться программой repomanage из пакета
yum-utils. Нам понадобится единственная её возможность, отображать
список устаревших пакетов. Скрипт переиндексации примет такой вид: Код for i in `ls -Rd /var/ftp/myrepo/fedora-7/*`; do rm -f $(repomanage -o $i) createrepo $i; done На вход команде rm подаётся список устаревших файлов, который генерируется командой repomanage с ключом -o. А
вот в Debian (и Ubuntu) уже существуют различные
http://wiki.debian.org/HowToSetupADebianRepository. Это DAK (Debian
Archive Kit), reprepro, mini-dinstall, а также apt-ftparchive (просто
для переиндексации списка пакетов). DAK – это главная
система для репозитория Debian. Самый большой её недостаток это то, что
по ней нет никакой документации кроме маленького howto в самом пакете.
Также не понятно, а что именно она умеет. Согласитесь фраза "умеет всё”
немного расплывчата. Настройка её очень сложна, она использует
posgresql и разумеется умеет работать с pool. Что такое pool можно
почитать в документации Debian или просто посмотреть, допустим,
http://mirror.yandex.ru/debian. Reprepro – превосходная
замена DAK. Простенькая, быстро настраиваемая, с немного занудным
синтаксисом. Работает с pool, умеет перемещать пакеты из unstable в,
например, testing. Однако просто убийственным её недостатком является
невозможность хранить в одном и том же месте пакеты с разными версиями.
Для вашего репозитория вероятно всё равно, а вот там где сидит куча
программистов и за день делают 10 версий одного и того же пакета
(причём не понятно какой из них стабильный) просто неприемлема. Увы,
если вам нужно хранить много версий одного и того же пакета, то
остаётся только mini-dinstall. Он медленный (так как всякий раз заново,
при помощи apt-ftparchive переиндексирует репозиторий), не очень
надежный и мёртвый (то есть не развивается). Также он не работает с
pool’ом, что немного изменяет синтаксис для APT. С другой стороны если
написать некоторые скрипты, которые отслеживают его ошибки, если
написать скрипты для переноса файлов из unstable в stable, то он не так
уж и плох. Единственное, что вы не сможете увеличить, так это скорость
переиндексации. Все зависит только от количества пакетов. Все
эти системы обладают incoming механизмом, который позволяет закидывать
пакеты в определённый каталог (при помощи dupload или dput), после чего
происходит его проверка и запихивание в нужную часть репозитория. Последние
две программы легко настроить просто читая файл конфигурации. Ещё
существует debarchiver, который развивается, но что он умеет я сказать
не могу, так как практически не пользовался им.
Источник: http://unixforum.org/index.php?showtopic=76757 |