Пятница, 29.03.2024, 14:32
Приветствую Вас Гость | RSS
Мой сайт
Главная
Регистрация
Вход
Форма входа

Меню сайта

Категории раздела
Об ОС Windows [137]
В категории размещаются статьи, касающщиеся операционных систем от Microsoft.
Об ОС *Nix [198]
В данной категории собраны статьи об ОС семейства Unix/Linux/FreeBSD/...
Справочные материалы [351]
Справка по всему разделу.
Виртуализация и Облака [46]
Networks & Routing [86]
DataBases [22]

Наш опрос
Оцените мой сайт
Всего ответов: 209

Статистика

Онлайн всего: 1
Гостей: 1
Пользователей: 0

Главная » Статьи » Системное администрирование » Об ОС *Nix

Сборка RPM и DEB пакетов, Федора и Дебиан (на русском языке) DEB

Сборка пакетов. Глава 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
Категория: Об ОС *Nix | Добавил: admin (08.12.2010)
Просмотров: 9340 | Рейтинг: 0.0/0
Всего комментариев: 0
Имя *:
Email *:
Код *:
Поиск

Друзья сайта
  • Официальный блог
  • Сообщество uCoz
  • FAQ по системе
  • Инструкции для uCoz


  • Copyright MyCorp © 2024