GARNOME-RPM — это система сборки RPM пакетов графического десктопа GNOME для тестеров и программистов, созданная с целью получения финального или тестового релиза в виде RPM пакетов для ОС ASPLinux 9, 9.2, 10 (возможно Fedora Core 3 и ASPLinux Server II). В рамках этого проекта, каждая группа пользователей может создавать spec файлы совместимые с разными версиями дистрибутивов LINUX основанных на RPM или создавать совсем разные spec файлы для этих ОС.

1. Что такое GARNOME-RPM?
2. Что вам надо для установки GARNOME-RPM?
3. Где взять GARNOME-RPM?
4. Как настроить GARNOME-RPM?
5. Дополнительные системные настройки
6. Как использовать GARNOME-RPM?
7. История создания проекта!
8. Для программистов желающих помочь в написании или исправлении текущего кода, в коррекции идеологии проекта и много другого.
9. Дополнения
10. Ошибки
11. Мысли вслух по поводу автоматизации создания LIBDEPS зависимостей

Что такое GARNOME-RPM?

Эта система, которая позволяет создавать rpm пакеты для проектов графического рабочего стола GNOME и дополнительного программного обеспечения. Система позволяет легко и удобно получать исходники проектов из интернет, и по ним и spec файлам с дополнительными патчами, собирать и устанавливать пакеты последних версий проектов GNOME с учетом их иерархической зависимости друг от друга.

Что вам надо для установки GARNOME-RPM?

Первое, что вы должны сделать, это загрузить GARNOME-RPM! Далее вам понадобятся GNU инструменты для сборки программного обеспечения. Это пакеты gcc, make, flex, bison, gettext, patch, gawk и другие, то есть, все то, что необходимо для сборки программ из исходных текстов. Также, понадобятся утилиты (де)компрессии gzip и bzip2, (раз)архивирования tar и утилита загрузки файлов по сети wget. А также, пакеты rpm, rpmbuild, sudo. Необходимо будет настроить rpmbuild и sudo.

Следующие пакеты также необходимы для сборки GNOME. Каждый дистрибутив как правило уже имеет в своем составе эти пакеты, все что вам надо, это установить их, надо будет установить как сами пакеты так и пакеты, которые содержат заголовочные файлы c/с++ и библиотеки, которые необходимы для сборки программ их использующих.

Для сборки цели meta/gnome-desktop необходимо установить в системе следующие пакеты, также будет указана версия которая на данный момент установлена у меня в ASPLinux 9:

(autoconf-2.57-3)		autoconf >= 2.54
(automake-1.6.3-5)		automake >= 1.6
(bash-2.05b-20.1)		bash
(bzip2-devel-1.0.2-8)		bzip2-devel >= 1.0.0
(coreutils-5.0-2.1asp)		coreutils
(docbook-dtds-1.0-17asp)	docbook-dtds
(docbook-style-xsl-1.58.1-2)	docbook-style-xsl
(docbook-utils-0.6.12-5)	docbook-utils
(e2fsprogs-devel-1.32-6)	e2fsprogs-devel
(expat-devel-1.95.5-2)		expat-devel
(fam-devel-2.6.8-9)		fam
(freetype-devel-2.1.3-6asp)	freetype-devel >= 2.0.5
(guile-devel-1.6.0-4)		guile-devel
(gzip-1.3.3-9asp)		gzip
(ImageMagick-5.4.7-10)		ImageMagick
(krb5-devel-1.2.7-28asp)	krb5-devel
(libjpeg-devel-6b-26)		libjpeg-devel
(libpng-devel-1.2.2-25)		libpng-devel
(libtiff-devel-3.5.7-11)	libtiff-devel
(libtool-1.4.3-5)		libtool

(openjade-1.3.1-12)		openjade	
(openssl-devel-0.9.7a-20.2asp)	openssl
(perl-5.8.0-88.3)		perl >= 5.6.0
(popt-1.8-0.69.2asp)		popt >= 1.6.3

(readline-devel-4.3-5)		readline-devel
(rpm-4.2-0.69.2asp)		rpm
(rpm-build-4.2-0.69.2asp)	rpm-build

(sed-4.0.5-1)			sed
(tcp_wrappers-7.6-34asp)	tcp_wrappers
(XFree86-devel-4.3.0-2.90.55)	XFree86-devel
(XFree86-libs-4.3.0-2.90.55)	XFree86-libs
(zlib-devel-1.1.4-8)		zlib-devel

Этот список был создан относительно давно и может быть не точным или не полным на данный момент. По возможности просмотрите файл Requirements.txt, именно там будут указаны необходимые пакеты. Синим цветом в этом списке отмечены пакеты собранные мной но не вошедшие в состав GARNOME-RPM, красным цветом созданные не мной, но необходимые для сборки. Если в описании в правом столбце указана версия, то нужен пакет с данной версией или версия пакета не важна.

Где взять GARNOME-RPM?

Скачать архив вы можете отсюда: garnome-rpm-0.1.0.6.

Как настроить GARNOME-RPM?

Разархивируйте архив. Все локальные установки хранятся в garnome-rpm.conf, install.sh, rpm.mk.

rpm.mk:

Здесь надо указать полный путь к каталогу куда распакован garnome-rpm-версия.

В этой переменной перечислены все пути, где могут находиться исходные тексты проектов, в рамках локальной файловой системы. Это значит, что вы можете заранее скачать все необходимые исходники, и положить их в каталог ${GARRPM}/src, тогда система уже не будет скачивать из интернет данные, а возьмет то что уже есть. В скором времени надеюсь сделать генерацию списка файлов которые надо скачать.

Когда это удобно? Например, вы Linux пользователь, но на работе у вас Windows, на который вы конечно же не сможете поставить garnome-rpm (точнее не сможете собирать пакеты), поэтому система проверит, что у вас уже установлено и выдаст список того, что необходимо скачать. Потом, скачайте все что указано в списке. Также этот способ подойдет, если сборку вы производите на компьютере не подключенном к интернету.

Данная запись говорит о том, что если не будет указан номер релиза пакета, то по умолчанию он будет 1.0asp.

Данная запись говорит о том, что если не будет указан номер эпохи пакета, то по умолчанию он будет 0.

Указывает как называется программа сборки, например в дистрибутивах RedHat до 8.0 это была программа rpm, а не rpmbuild.

Указание целевой платформы сборки.

Указание, параметра для RPMB программы, указав который осуществляется подпись собранного пакета электронным ключом.

Все остальные переменные это текстовые сообщения, которые вы видите на момент сборки пакетов, далее я постараюсь вынести все эти сообщения сюда, тогда здесь же можно будет реализовать локализацию сообщений.

В файле install.sh дублируются только некоторые опции, в скором времени этого не надо будет делать.

Настройка rpm-build заключается в том, что сборка всех пакетов производится исключительно из под обычного пользователя, а не из под пользователя root. Объясняется это тем, что многочисленные пакеты при своей сборке, зачастую, могут вносить изменения в систему на которой они собирались, и эти изменения не правильны так как пакет еще не только не установлен, но и не собран.

Дополнительные системные настройки

Как уже выше описано для процесса сборки необходимо настроить сборку rpm пакетов из под обычного пользователя лишенного суперпользовательских привилегий, а также настроить sudo таким образом, чтобы этот самый обычный пользователь мог с помощью системы GARNOME-RPM установить на своем компьютере собранные пакеты. Замечу, что установка необходима или можно сказать обязательна из-за того, что процесс сборки новых пакетов потребуют в свою очередь уже установленных новых версий библиотек, которые собираются в рамках данной системы, причем в виде пакетов. Желательно создать для этого совсем нового пользователя и когда вам понадобится что-то собрать, переключаться в контекст этого пользователя с помощью команды:

После чего ввести пароль пользователя и собрать все что вам необходимо.

С этим связанны некоторые удобные возможности, например, вы можете заставить систему контролировать трафик, создаваемый этим пользователем, потребляемые ресурсы: процессора, памяти, ограничения на дисковое пространство и т.д.

Как же все таки настроить сборку rpm из под обычного пользователя? Многие современные системы ОС Linux сейчас уже попросту не дадут собрать rpm пакет из под пользователя root, насколько мне известно из слухов доходивших до меня, Mandrake, кажется не разрешит собирать пакеты из под суперпользователя.

И это есть правильно! Когда я был молодым и зеленым, мне казалось, что можно собирать пакеты из под суперпользователя, но потом я резко изменил свою точку зрения поняв, что многие проекты еще на этапе сборки имея права суперпользователя могут нарушить работу вашей системы, при этом по существу не собравшись. Или может быть вы на своей системе просто собираете пакет для своего неопытного знакомого, а сам пакет в системе ставить не будете. Тем не менее проект сможет оставить свой нехороший след в системе, если будет иметь права суперпользователя, не специально конечно, но все же это так (а уж если специально, то это все, какой вы будете после этого админ?).

Например, многие GNOME проекты при своей установке делают определенные записи в конфигурационной системе GNOME под названием GConf(2). Но мне-то ненужны эти изменения в моей системе, учитывая что пакет может вообще совсем не собраться из-за ошибок на последующих этапах сборки. Такая же ситуация, если в состав проекта входят файлы *.omf, это файлы в которых содержится справка о программе, во время установки проекта эти файлы устанавливаются в /usr/share/omf/... путем вызова утилиты по реиндексированию этого каталога. Но ведь я пакет только собираю, а не устанавливаю его уже в систему. И таких случаев много, перечисленные случаи безобидны, но есть и более жестокие варианты, например выполнение команды make install в исходниках ядра или make uninstall для проекта который уже установлен в системе из пакета, а не из исходников. В этом случае такие неосторожные действия могут привести к дизфункциональности всей системы. Причем вы будете думать , ну как же так, ведь там сидят крутые программисты, они должны, нет, просто обязаны были подумать о таких случаях. Но у нас есть своя голова на плечах и именно поэтому, мы будем собирать пакеты из под обычного пользователя. И этот пользователь должен иметь ровно столько прав сколько понадобится только для сборки и установки проекта в указанное нами место.

Если пакет будет собираться бесправным пользователем, то вы сможете в таких случаях увидеть, а что же на самом деле проект делает при своей установке в систему. Рекомендую в момент сборки и установки находится в другой графической среде, во избежании путаницы, при установке новых версий, очень велика вероятность, что находясь в среде GNOME вы увидите, что при установке нового пакета, что-то стало не так функционировать. Все желательно поставить от начала и до конца, из-за несовместимости API новых версий библиотек и старых программ, рассчитанных на старое API.

Допустим ваша система не настроена для сборки проектов из под обычного пользователя. И в ее составе нет никакого пакета установив который это станет возможным. Тогда необходимо сделать следующее. Почти наверняка в redhat базовом дистрибутиве есть каталог /usr/src/asplinux|redhat|mandrake или еще как, содержимое этого каталога, а точнее набор директорий надо скопировать в домашнюю папку пользователя в какой либо подкаталог для этого, туда где достаточно свободного места и туда куда имеет права на запись пользователь из под которого мы будем собирать новые пакеты. Например у меня этот каталог такой ~/local/packages:

packages
packages/tmp
packages/LOGS
packages/RPMS
packages/RPMS/i386
packages/RPMS/i486
packages/RPMS/i586
packages/RPMS/i686
packages/RPMS/athlon
packages/RPMS/noarch
packages/html
packages/BUILD
packages/SPECS
packages/SRPMS
packages/SOURCES

В RPMS каталогах будут находится собранные пакеты. После сборки пакетов можно содержимое каталога SOURCES и BUILD удалить. Далее в домашнем каталоге этого пользователя создать файл ~/.rpmmacros. Вот его содержимое:

	
# ---- Required rpmrc macros.
#	Macros that used to be initialized as a side effect of rpmrc parsing.
#	These are the default values that can be overridden by other
#	(e.g. per-platform, per-system, per-packager, per-package) macros.
#
#	The directory where sources/patches will be unpacked and built.
%_topdir		/home/alex/local/src7/garnome-0.27.1/packages

%_builddir	%{_topdir}/BUILD

#	The directory where sources/patches from a source package will be
#	installed. This is also where sources/patches are found when building.
%_sourcedir		%{_topdir}/SOURCES

#	The directory where the spec file from a source package will be
#	installed.
%_specdir		%{_topdir}/SPECS

#	The directory where newly built source packages will be written.
%_srcrpmdir		%{_topdir}/SRPMS

%_tmppath		%{_topdir}/tmp

%_source_payload       w9.bzdio
%_binary_payload       w9.bzdio

%_missing_doc_files_terminate_build     0

%_distribution	ASPLinux

%packager	Alexander Alyabushev <alexhack@inbox.ru>
%vendor		Alexander Alyabushev <alexhack@inbox.ru>

Теперь вводя команду rpmbuild -ba ttx.spec система сборки будет знать где ей собирать пакеты, куда устанавливать их содержимое и многое другое.

Кроме того вы можете указать опции оптимизации, которые будут применимы при сборке любого пакета в файле ~/.rpmrc:

Значение этой строки описано в разделе Дополнения.

Теперь о настройке sudo. Для разрешения обычному пользователю устанавливать пакеты в системе без или с его аутентификацией необходимо в файле /etc/sudoers прописать следующее:

	
Cmnd_Alias RPM = /bin/rpm
alex    ALL=NOPASSWD : RPM

Этот файл может поправить только суперпользователь. Здесь я указал, что пользователь может запустить программу rpm с правами суперпользователя для установки пакета, конечно вы можете написать более жесткие правила, но мне они ни к чему, на персональном-то компьютере.

От sudo при установки пакетов есть одно удобство, при установки пакетов командой:

в файл /var/log/sequrity добавляется, обычно, запись о том, что такой-то пользователь такого числа в такое-то время запускал разрешенную для запуска команду rpm с такими-то правами для выполнения таких-то действий, аргументы команды так же сохраняются. И всегда можно узнать, что и когда вы или не вы установили и удачно ли прошла установка.

Как использовать GARNOME-RPM?

Разархивируйте архив, настройте. По умолчанию должно работать без проблем.

Далее выполните команды:

cd meta/gnome-desktop/ 
make clean-all
make installed

Это все, что надо сделать! GARNOME-RPM начнет скачивать, собирать и устанавливать RPM пакеты GNOME Desktop.

Если вы хотите собрать другие мета цели или индивидуальные пакеты, просто войдите в директорию соответствующей мета цели или пакета и выполните команду:

История создания проекта!

В свое время, мне было необходимо, как многим из вас, установить у себя новую версию GNOME, но ждать когда выпустят новый дистрибутив ASPLinux было для меня невыносимо долго, это аналогично так же и для других знаменитых дистрибутивов.

В результате поисков я наткнулся на один проект под названием GARNOME, данный проект позволял скачивать, собирать и устанавливать в систему по заданному пути GNOME и сопутствующие среде программы. Но так как, я пользователь RedHat базового дистрибутива, для меня было важно не просто собрать и установить программу из исходников, а собрать все это в виде rpm пакетов. Как бы не ругали систему rpm, все таки она полезна и в повседневной практике системного администрирования необходима. Конечно, есть полу-автоматные средства создания rpm пакетов из исходников, но это вариант применим только в рамках системы на которой и происходит полу-автоматная сборка, так как не создаются необходимые скрипты после установки пакета и многое другое. Считается, что эти скрипты выполнились при установке из исходников. Мне же хотелось создать систему сборки переносимых пакетов, т.е. которые можно будет установить на системе подобной той на которой осуществлялась их сборка.

Таким образом появилась идея создания аналога GARNOME, но со сборкой RPM пакетов. Я перенял все то, что сумел перенять из проекта GARNOME, и считал полезным. Считаю, что поступил правильно разделив реализацию на использование утилит make и bash, это как бы упростило логику, она стала более понятной. В результате появился один основной rpm.mk make-файл и основной install.sh. Скрипт install.sh вызывается всякий раз, когда необходимо реально собрать и установить в системе один из проектов среды GNOME, например пакет glib2. В свою очередь rpm.mk обеспечивал логику взаимозависимой и иерархически последовательной сборки всех проектов среды GNOME. Далее уже появился скрипт eq.sh, который нормально завершается, если пакет в системе старее, или вообще отсутствует, того который необходим среде GNOME.

Также, проект хотелось сделать так, чтобы легко прививался вновь выходящим новым версиям проекта GARNOME. Слияние происходит легко, но все таки из за того, что зачастую пакеты rpm не несут в себе того же названия, что и сам проект пришлось в makefile-ах таких проектов дополнительно указывать название rpm пакета, его релиз и эпоху, чтобы это все было можно потом установить в rpm базовый дистрибутив. В связи с чем, во многих Makefile появились дополнения, конечно даже в этом случае можно организовать автоматическую прививку системы GARNOME-RPM в GARNOME, например, добавлять недостающие части в makefile, своего рода патч.

Логика иерархической сборки: каждый проект имеет свой Makefile в котором указано оригинальное название проекта, его версия, эпоха rpm пакета, релиз сборки rpm пакета, название файла с исходником заданной версии проекта, путь откуда можно скачать заданный файл, если стандартный путь не походит, который указан в файле category.mk, такие файлы находятся в каждом подкаталоге за исключением подкаталогов самих проектов.

Содержимое файла category.mk в корневом каталоге проекта:

Запись include ../../../rpm.mk обеспечивает загрузку проектов с официального сайта GNOME, если же проект там не находится, то в Makefile самого проекта придется указать свою переменную $MASTER_SITES. Например, в проекте desktop-file-utils Makefile следующий:

GARNAME = desktop-file-utils
GARVERSION = 0.7
#GARRELEASE_RPM = 0lar9
#GAREPOCH_RPM = 0

#LIBDEPS = gnome/platform/glib

DISTFILES = $(GARNAME)-$(GARVERSION).tar.gz

MASTER_SITES=http://freedesktop.org/Software/$(GARNAME)/releases/

DESCRIPTION = desktop-file-utils

include ../category.mk

Обратите внимание на LIBDEPS именно здесь на данный момент в ручную указывается от каких проектов зависит данный проект. Когда вы попытаетесь собрать заданный проект, то будет сначала осуществлена проверка о выполнении указанных зависимостей, то есть RPM пакеты проектов переменной LIBDEPS должны уже быть установлены в системе прежде, чем сборка данного проекта будет начата. После окончания успешной сборки в подкаталоге проекта создается файл deps, который и сигнализирует системе сборки, что данный проект был успешно установлен или то, что в системе уже стоит все то, что удовлетворяет данному проекту. Есть meta пакеты-цели, это не проекты и не пакеты, это просто makefile, основная задача которого указать LIBDEPS, которые надо выполнить, чтобы данный meta пакет считать собранным. Например, цель meta/gnome-desktop является meta пакетом. Это значит, что в Makefile указана переменная TYPE=meta, достаточно объявить не нулевое значение переменной TYPE. Например, Makefile каталога gnome/platforn выглядит или выглядел так:

GARNAME = gnome-platform
GARVERSION = 2.9.4-MSIU

TYPE=meta

LIBDEPS = gnome/platform/atk gnome/platform/at-spi gnome/platform/gail gnome/platform/GConf \
	gnome/platform/glib gnome/platform/gnome-vfs gnome/platform/gtk+ gnome/platform/intltool \
	gnome/platform/libgnome gnome/platform/libgnomeprint gnome/platform/libgnomeprintui \
	gnome/platform/libgnomeui gnome/platform/libIDL gnome/platform/libxml2 gnome/platform/libxslt \
	gnome/platform/ORBit2 gnome/platform/pango

include ../../rpm.mk

Если вдруг при сборке вы решили, что данный проект вы не хотите или не может собрать на данный момент, но в целом сборку необходимо продолжить, вы можете имитировать успешность сборки проекта, создав в каталоге проекта файл deps.

Команда make clean обеспечивает безоговорочное удаление файлов deps у проектов от которых зависит проект в каталоге которого вы выполните эту команду. Причем только у проектов, которые до этого были успешно собраны и установлены. Например, glade зависит от gtk+, который зависит от glib, если gtk+ не имеет файла deps, то make clean для проекта glib выполнен не будет. Для того, чтобы удалить все deps выполните команду
find . -name 'deps' -exec rm -f {} \;
в корне каталога GARNOME-RPM или
make clean-all
из каталога любого пакета.

Для программистов желающих помочь в написании или исправлении текущего кода, в коррекции идеологии проекта и много другого.

Что хотелось бы сделать.

1. Система должна по команде make mincheck выяснить какие пакеты надо собрать и установить для правильного функционирования выбранной цели или пакета. После чего, выдать список в формате понятном утилите wget или другим утилитам сетевой загрузки, например dx4.
2. Нет проверки md5sum, если файл находится в каталоге src, а не в download.
3. Не смотря на то, что закачка ведется в независимости от неправильности указания суффикса в имени файла bz2 или gz, но вот в spec файл подставляется bz2, когда был скачен gz! Возможно стоит отказаться от идеи автоматной замены gz на bzip2, так как это вносит путаницу, увеличивает размер кода и все только ради того, чтобы обойти ошибку создания Makefile-а.
4. Проверить наличие новых билдов, увеличив версию на 1, и так до тех пор пока не найдем последнюю версию, возможна она даже будет в другом major-версия каталоге.
5. Реализовать зависимости в makefil-ах на основе стандартного механизма включения *.d файлов в Makefile. При построении этих файлов обрабатывать spec файл на наличие дополнительных опций, запускать диалог выбора опций. После чего записывается *.d файл с соответствующими зависимостями, правда прежде надо через файл хэша узнать по имени rpm пакета оригинальное название самого проекта, так как rpm пакет может называться по другому.

Дополнения

Опции сборки могут позволить собрать программы, которые будут работать и запускаться, возможно быстрее, чем будучи собранными без них. Например, в файле ~/.rpmrc я указываю следующие опции:
optflags: i686 -g -O2 -march=i686 -pipe -fomit-frame-pointer -mmmx -msse -fpmath=sse
данная строка указывает на то, что сборка программ будет производится с включением отладочной информации, со вторым уровнем оптимизации, под архитектуру i686. При этом будут использованы расширения mmx и (sse при операциях с плавающей запятой), так как, если sse не указать, то операции с плавающей запятой на новых процессорах типа Pentium 3,4 скорее всего будут выполняться медленнее, чем если бы применялись sse инструкции.

Ошибки

Возникает конфликт, если есть evolution-web-calendar, но например еще нет самого evolution, тогда программа говорит, что уже есть evolution и его можно поставить хотя реально его нет. Данный конфликт требует чтобы список устанавливаемых пакетов после сборки проекта был точным и задавался перечислением конечного числа названий rpm пакетов, а не задавался как это делается сейчас шаблоном name-*version.

Можно указать дополнительную опцию для сборщика программы ld, то есть для линковщика. Прежде, чем собирать проекты, установите следующую переменную среды:
export LDFLAGS=-Wl,-O1

По непонятной для меня причине, при включении этой опции, скорее всего не соберется нормально проект evolution, точнее соберется, но нужная для запуска общая динамическая разделяемая библиотека не будет то ли собрана, то ли установлена.

Мысли вслух по поводу автоматизации создания LIBDEPS зависимостей

Следующая команда
rpm --specfile 2.5.2.spec -qR

вернет названия всех пакетов пакетов и сущностей, которые необходимы данному проекту при заданных опциях по spec файлу не собирая сам пакет. Остается только в spec файле указывать опции и корректно указывать зависимости сборки пакета от этих опций.

Порядок действий. Пропарсим файл спека до секции %build командой
make build_deps

1. Это значит, что в spec файл подставляются: название пакета, версия, номер сборки, эпоха. Вместо макросов __пакет, подставляются реальные названия пакетов в конкретном дистрибутиве. Для ускорения неплохо бы создать кэш, в котором лежат пары
   alias настоящее_название_пакета_в_дистрибутиве.
   Замена макроса происходит путем поиска его первой части до знака -, в списке и замены первой части макроса до - на найденное значение.
   Если отличия в дистрибутиве слишком явные (а не только по названию пакета), то spec файл должен быть свой для этого дистрибутива, например, разный набор пакетов для одного проекта. Или когда проект vim можно собрать, как один пакет, а можно как несколько пакетов в конкретном дистрибутиве.
2. Сохраняет список зависимостей при настройках по умолчанию.
3. Обработка spec файла, чтобы выявить опции сборки.
4. Обратный поиск в списке макросов по названию пакета, название проекта и построение списка целей (в виде *.d файлов), которые будут автоматом под-гружены в Makefile при выдаче команды make installed.
5. Отобразить список опций сборки и список проектов от которых зависит конкретная сборка. При каждом изменении значений опций сборки динамично изменять список зависимостей, выделив изменения каким-либо цветом. То есть, периодически повторять пункты 3,4.
6. После подтверждения, сохраняется файл зависимостей.