Сборка PostgreSQL для 1C на Gentoo

Сборка PostgreSQL для 1C на Gentoo

Возникла необходимость поднять на Gentoo PostgreSQL-сервер для 1С-ки. Как всем известно одинэсовцы являются знаменитыми костылестроителями и в данном случае СУБД PostgreSQL не обошли стороной.

Почему Gentoo? Потому что данный дистр можно заточить именно для решения узко определенной задачи, со всеми преимуществами оптимизации USE-флагов, в отличие от бинарных дистров, где много вшито лишнего, а сборка собственных пакетов означает отказ от пакетных менеджеров (может и не так, не знаток этого вопроса), что сильно ухудшает поддержание инсталляции в актуальном состоянии. Ну и к тому же, на то он и гентушник раз любит сам готовить, а не использовать готовое.

Блуждания в интернете не принесли желаемого результата, а именно не нашлось ebuild-а, для такой задачи, хотя упоминания имеются, на неком ростовском сервере, то некто выкладывал на форуме (может плохо искал), то изобретали костыли с использованием rpm2cpio - над пропатченными сырцами, а то и вовсе редхатовскими бинарниками, но сим не есть gentoo-way, а хочется именно чтобы собрать из сырцов, без левых зависимостей, установить в каталоги стандартные для этой системы, а не какие-то /opt, и чтобы пакетный менеджер знал о нашей инсталляции и считал ее родной, с учетом make.conf и USE-флагов.

Имеется хороший ресурс ftp://ftp.etersoft.ru/pub/, оттуда берем патчи 1С-ки для PostgreSQL 8.4.4 - ftp://ftp.etersoft.ru/pub/Etersoft/Postgre@Etersoft/8.4.4/sources/postgresql-8.4eter-8.4.4-alt1.1.src.rpm, т.к. у самих 1С-цев на сайте патчи только для версии 8.4.1 (опять-таки может плохо искал, а может они и подходят для нашей версии). Кроме того, етерсофтцы опять таки патчат некоторые наработки одинэсевцев, исправляя их баги.

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

Итак, наш рецепт приготовления будет состоять в следующем:

• скачиваем сырцы и патчи на etersoft.ru
• готовим локальный оверлей
• наложение гентушных патчей на оригинальные исходники
• наложение етерсофтных патчей поверх гентушных
• снятие diff-а с гентушных сырцов PostgreSQL и патченного етерсофтом, в целях получения своего патча
• оформляем патч для кормления epatch'а
• оформляем наш ebuild
• ловля блох (багов) сборки
• тюнинг системы
• напутствия жаждущим

Где мы находимся

В качестве версии СУБД будем использовать версию 8.4.4, хотя сейчас уже 1с-цы выложили патчи для 9-й версии, думаю не будет сложно и их адаптировать по аналогии.

Ранее установленная ОС Gentoo x86_64 на домашней машине [4G 1333, 1Tb] (самопальное ядро Linux localhost 2.6.36-gentoo-r5 #1 SMP Sun Dec 26 21:57:53 YEKT 2010 x86_64 Intel(R) Core(TM) i3 CPU 530 @ 2.93GHz GenuineIntel GNU/Linux и все что на нем крутится также собрано gentoo-способом), которая содержит очень много лишнего для боевого сервера узко-направленного значения, но это нам не помешает, а скорее будет проще не отвлекаться на шлифовку ядра, если таковое требуется, о чем мне не ведомо.

Что мы имеем

Для начала обновим порты, это уж кто как предпочитает, я делаю так:

# eix-sync

Посмотрим что нам предлагают в портежах:

eix postgresql-server
[D] dev-db/postgresql-server
    Available versions:  
       (8.1)	8.1.21-r1 ~8.1.22
       (8.2)	8.2.17-r1 ~8.2.18
       (8.3)	8.3.11-r1 ~8.3.12
       (8.4)	8.4.4-r1!t ~8.4.5!t
       (9.0)	~9.0.0!t ~9.0.1!t

Как видно последняя размаскированная (а значит стабильная версия postgresql-а) - 8.4.4-r1, то что нам нужно.

Качаем патчи

Как было сказано качаем исходники PostgreSQL вместе с патчами отсюда ftp://ftp.etersoft.ru/pub/Etersoft/Postgre@Etersoft/8.4.4/sources/postgresql-8.4eter-8.4.4-alt1.1.src.rpm. Открываем архив кому как угодно, я пользуюсь Gnome - у него имеется менеджер архивов и вытаскиваем оттуда следующие файлы:

• 1c_FULL_84-0.19.2.patch - оригинальный 1с-ский патч, добавляет три новых модуля fulleq, fasttrun, mchar и еще массу телодвижений
• 1cfix_etersoft.patch - данный патч фиксит 1с-ский патч
• applock-1c-8.4.1.patch - добавляет необходимоые типы блокировок
• eter-rename-libpq.patch - переименовывает библиотеку (единственное, что мне пришло в голову зачем это сделано, так это чтобы как то отметиться в системе, - вместо стандартного названия libpq, делает название libpq-8.4eter, мне это показалось саморекламой (есть ли нарушения GPL? или BSD, или какая лицензия у PostgreSQL и патчей?), поэтому данный патч не был использован, к тому же при сборке PostgreSQL все же хочет файл libpq, так что ребята недостарались)
• postgres_datalen.patch - что-то меняет для успешной инициализации кластера PostgreSQL (initdb)
• postgresql-1c-8.4.patch - рихтует Makefile для сборки модулей написанных 1с-цами - fulleq, fasttrun, mchar, плюс рихтует конфиг для PostgreSQL
• postgresql.conf.sample.patch - как видно из названия, также рихтует конфиг (честно говоря не понимаю для чего это сделано, ребята полагают, что PostgreSQL будут ставить полные нули которые не осилят чтения документации а-ля MSSQL)
• postgresql-no_transaction_blocks.patch - этот и следующие два патча, по мелочам вносят правки
• postgresql-perl-rpath.patch
• postgresql-tmp_table_cleanup.patch
• rpm-pgsql.patch - опять самопиар для сборки RPM-пакета, также не понял зачем менять стандартную директорию размещения БД-х PostgreSQL с /var/lib/postgresql, на /var/lib/pgsql
• timestamp.c.diff - корректировки насчет пустого поля времени - по аналогии с MSSQL, устанавливает в качестве даты значение 1900-01-01 по умолчанию для полей даты таблицы - могу ошибаться, но где-то встречал такое описание (как ни странно, но это отражено в самом патче).

Сохраним патчи сюда

mkdir -p /tmp/postgresql/patches

Локальный оверлей

Для интеграции в существующее дерево портежей плодов наших манипуляций сделаем локальный оверлей (почитать можно здесь http://ru.gentoo-wiki.com/wiki/Portage_Overlay):

echo 'PORTDIR_OVERLAY="/usr/local/portage"' >> /etc/make.conf
install -d /usr/local/portage

У кого будут ругания на оверлей, почитать man make.conf и гугл - у меня не было косяков, но может быть конфликт с другими параметрами в нем, на предмет очередности их объявления.

По аналогии с родной структурой дерева портежей создаем структуру директорий для локального:

mkdir -p /usr/local/portage/dev-db/postgresql-server

Копируем исходный ebuild, который будем патчить:

cp /usr/portage/dev-db/postgresql-server/postgresql-server-8.4.4-r1.ebuild \
/usr/local/portage/dev-db/postgresql-server/postgresql-server-8.4.4-r3.ebuild

Стоит обратить внимание что исходный ebuild имеет версию обновления r1, нам нужно чтобы не совпадало с ней, поэтому свой ebuild называем r3 (r2 появился у меня после очередного eix-sync), - надо выбирать именование так чтобы не пересекалось с имеющимися ebuild'ами, возможно можно как-то еще, но по правилам именования нужно соблюдать определенные требования.

Также при сборке PostgreSQL понадобятся патчи подготовленные командой Gentoo, вероятно как-то можно использовать их из системного дерева портежей, но пока не знаю как, так что делаем:

cp -R /usr/portage/dev-db/postgresql-server/files \
/usr/local/portage/dev-db/postgresql-server

Хотя реально оттуда требуется всего лишь два файла:

* /usr/portage/dev-db/postgresql-server/files/postgresql-8.4-common.patch
* /usr/portage/dev-db/postgresql-server/files/postgresql-8.4-server.patch

Приготовление исходников

Использовать исходники PostgreSQL не будем от команды etersoft'а (как-то в душу запали только их патчи, не дай .. они еще и сырцы трогали, про сравнение хэш-сумм знаю - не заморачивался), а возьмем те что тянет emerge из интернета для оригинального PostgreSQL.

Загружаем исходники:

emerge -fv dev-db/postgresql-server

Сделаем рабочую директорию и распакуем туда сырцы:

mkdir -p /tmp/postgresql/orig && cd /tmp/postgresql/orig && \
tar xjf /usr/portage/distfiles/postgresql-8.4.4-tar.bz2 

Идем туда и накладываем гентушные патчи:

cd /tmp/postgresql/orig/postgresql-8.4.4
patch -p0 -g0 -E < /usr/local/portage/dev-db/postgresql-server/files/postgresql-8.4-common.patch
patch -p1 -g0 -E < /usr/local/portage/dev-db/postgresql-server/files/postgresql-8.4-server.patch

С ключами у них для одного патча применяем -p0 для другого -p1, по-крайней мере у меня так получилось. Хотя можно применять просто команду: patch -pX < <patch-name>, но анализ лог-файлов показал, что epatch использует такую хитрую комбинацию ключей. Теперь считаем что у нас получились эталонные исходники, на которые будет ebuild накладывать патчи для 1с-ки.

Подготовим площадку для дальнейших экзекуций:

mkdir -p /tmp/postgresql/patch
cp -R /tmp/postgresql/orig/postgresql-8.4.4 /tmp/postgresql/patch

Теперь нужно внимательно изучить файл postgresql-8.4eter.spec, поставляемый в postgresql-8.4eter-8.4.4-alt1.1.src.rpm, чтобы определить в каком порядке накладываются патчи, вообщем имеется такая секция описывающая порядок и уровень -pX, с которым они применяются:

# Patch1: rpm-pgsql.patch
%patch1 -p2
# Patch4: postgresql-test.patch
# now test is by C program.
# %patch4 -p1
# Patch6: postgresql-perl-rpath.patch
%patch6 -p2
# Patch7: 1c_FULL_83-0.19.patch
%patch7 -p2
# Patch8: postgresql-1c-8.4.patch
%patch8 -p2
# Patch9: applock-1c-8.3.1.patch
%patch9 -p0
# Patch10: timestamp.c.diff
%patch10 -p2
# Patch11: postgresql.conf.sample.patch
%patch11 -p2
# Patch12: pg_hba.conf.sample.patch
# already included in postgresql-1c-8.3.patch
# %patch12 -p1
# Patch13: postgres_datalen.patch
%patch13 -p2
# Etersoft's fix for 1c patches
# Patch15: 1cfix_etersoft.patch
%patch15 -p2
# Etersoft rename libpq
%patch50 -p2
#Patch51: postgresql-tmp_table_cleanup.patch
%patch51 -p1
#Patch52: postgres-no_transaction_blocks.patch
%patch52 -p2

А как же в Gentoo?

Последив как работает команда ebuild при сборке пакетов (немного есть здесь http://www.gentoo.org/doc/ru/handbook/handbook-x86.xml?part=3&chap=6), выяснил что выполняются по шагам следующие действия:

• ebuild /path/to/ebuild unpack
• ebuild /path/to/ebuild prepare
• ebuild /path/to/ebuild compile
• ebuild /path/to/ebuild install
• ebuild /path/to/ebuild clean

Распаковка исходников производится в каталог: /var/tmp/portage/dev-db/postgresql-server/work/postgresql-8.4.4 и он делается текущим, затем при выполнении команды prepare, накладываются патчи и выполняется ./configure, т.е. команда patch вызывается с уровнем -p0 (хотя и это меняется редактированием ebuild-файла), вот это и нужно поправить в патчах. Вообщем как удалось расковырять патчи ложатся в следующем порядке, хотя для некоторых файлов он не важен (не спешим патчевать, а читаем дальше):

cd /tmp/patch/postgresql
# сделаем симлинк
ln -s postgresql-8.4.4 postgresql
patch -p2 < postgreslq-perl-rpath.patch
patch -p2 < 1c_FULL_83-0.19.patch
patch -p0 < applock-1c-8.3.1.patch
patch -p2 < timestamp.c.diff
patch -p2 < postgresql.conf.sample.patch
patch -p2 < postgres_datalen.patch
patch -p2 < 1cfix_etersoft.patch
patch -p1 < postgresql-tmp_table_cleanup.patch
patch -p2 < postgres-no_transaction_blocks.patch

Как видно, были пропущены файлы prm-pgsql.patch и eter-rename-libpq.patch по причине описанной ранее. Также patch споткнется на файле postgresql-1c-8.4.patch, - он выполняет редактирование файла postgresql/contrib/Makefile, на предмет добавления в собираемые модули fulleq, mchar и fasttrun - т.к. гентушные патчи тоже наводят там небольшой порядок, то возникает конфликт. Поэтому данный патч можно не применять, а дописать модули вручную (тру-гении смогут и патч отрихтовать). Также этот патч по мелочи шлифует pg_hba.conf.sample и postgresql.conf.sample, т.е. конфигурационные файлы, на попсовые настройки - никто же не собирается использовать дефолтные поэтому можно смело забить. И чтобы было все как с остальными, то содержимое файла postgresql-1c-8.4.patch можно заменить на:

--- ../contrib/Makefile	2011-01-06 15:30:50.670856014 +0500
+++ ../contrib/Makefile	2011-01-06 16:00:39.664856014 +0500
@@ -36,7 +36,10 @@
 		spi		\
 		tablefunc	\
 		tsearch2	\
-		test_parser
+		test_parser	\
+		fasttrun	\
+		fulleq		\
+		mchar

ifeq ($(with_openssl),yes)
WANTED_DIRS += sslinfo

Также файл applock-1c-8.4.1.patch в голом виде так и не смогла переварить команда patch. Исследование содержимого файла показало, что пути к файлам, предназначенные для изменений начинаются следующим образом, например первая строка того же файла содержит:

diff -c -r -N ..\postgresql-8.4.0/doc/src/sgml/ref/lock.sgml ./doc/src/sgml/ref/lock.sgml 

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

cd /tmp/postgresql/patches
cat applock-1c-8.4.1.patch | sed 's!\.\.\/postgresql\-8\.4\.0!\.\./postgresql\-8\.4\.0!' > \
applock-1c-8.4.1.patch-fix && mv applock-1c-8.4.1.patch-fix applock-1c-8.4.1.patch

И делаем симлинки:

cd /tmp/postgresql/patch
ln -s postgresql-8.4.4 postgresql-8.4.0

После манипуляций с патчами можно еще раз прогнать "патчевание" (а лучше все сначала, предварительно сделав rm -rf /tmp/postgresql/patch/postgresql-8.4.4 && cp -R /tmp/postgresql/orig/postgresql-8.4.4 /tmp/postgresql/patch/), т.к у меня все патчи наложились далеко не с первого раза, то процедуру патчевания лучше записать в bash-скриптик.

В итоге в директории /tmp/postgresql/ имеем следующую структуру:

/tmp/postgresql/
|
+- orig (оригинальный PostgreSQL + Gentoo-патчи)
|  |
|  +- postgresql-8.4.4
|
+- patch (копия orig/postgresql-8.4.4 + патчи 1С/etersoft)
|  |
|  +- postgresql
|  +- postgresql-8.4.0
|  +- postgresql-8.4.4
|
+- patches
   |
   +- список файлов-патчей

Наложение патчей от 1c/etersoft

Собственно процедура наложения выглядит таким образом (после всех манипуляций, исправлений и рихтований):

cd /tmp/postgresql/patch/postgres
patch -p2 ../../patches/postgreslq-perl-rpath.patch
patch -p2 ../../patches/1c_FULL_83-0.19.patch
patch -p2 ../../applock-1c-8.3.1.patch
patch -p2 ../../timestamp.c.diff
patch -p0 ../../postgresql-1c-8.4.patch
# Данный патч немного глюкавит, но как очевидно, 
# он делает то что будет переделано - тюнинг конфиг-файла
# patch -p2 ../../postgresql.conf.sample.patch
patch -p2 ../../postgres_datalen.patch
patch -p2 ../../1cfix_etersoft.patch
patch -p1 ../../postgresql-tmp_table_cleanup.patch
patch -p2 ../../postgres-no_transaction_blocks.patch

Получение итогового патча

Возня с исходниками практически закончена, осталось только сделать свой патч и прописать все это дело в ebuild-файле:

cd /tmp/postgresql/patch/
ln -s /tmp/postgresql/orig/postgresql-8.4.4 postgresql-8.4.4.orig
# Это наш патч, который можно отослать другу-гентушнику
diff -urdN ../postgresql-8.4.4.orig ../postgresql-8.4.4 > ../postgresql-8.4-1c8all.patch
# Копируем в папку к остальным патчам
cp /tmp/portage/patch/postgresql-8.4-1c8all.patch /usr/local/dev-db/postgresql-server/files

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

Шлифуем ebuild-файл

Открываем в любимом редакторе ранее сделанную копию ebuild-файла:

mcedit /usr/local/portage/dev-db/postgresql-server/postgresql-server-8.4.4-r3.ebuild

и вносим правки.

В строке 3 можно поменять (не уверен, что не нужно, хотя и работает без правки):

# $Header: /var/cvsroot/gentoo-x86/dev-db/postgresql-server/postgresql-server-8.4.4-r3.ebuild,v 1.6 2010/08/11 19:27:10 josejx Exp $

- ревизию ebuld-файла

Далее в строке можно поменять

DESCRIPTION="PostgreSQL server with patchset from 1C company. I'm was hack the Internet"

Менять обязательно:

IUSE="1c8 pg_legacytimestamp doc perl python selinux tcl uuid xml nls kernel_linux ${IUSE_LINGUAS}"

- добавили ключик "1c8"

Ищем функцию src_prepare() и после слов epatch ...-common.patch ...-server.patch пишем свое:

if use 1c8; then
        epatch "${FILESDIR}/postgresql-${SLOT}-1c8all.patch"
fi

Создание цифровой подписи для ebuild-файла

cd /usr/local/portage/dev-db/postgresql-server
ebuild postgresql-server-8.4.4-r3.ebuild digest
# Если все в порядке, то получим, если нет - то читаем вывод и в маны и гугл
>>> Creating Manifest for /usr/local/portage/dev-db/postgresql-server

Подготовка системы к установке

Предварительно сделаем небольшой тюнинг системы:

# Архитектура нашего ПК (в данный момент уже является стабильным для x86 и amd64) поэтому можно и не делать
echo '=dev-db/postgresql-server-8.4.4-r3 amd64' >> /etc/portage/package.keywords
# Маскируем версии старше нашей, чтобы по-умолчанию ставилась наша 
echo '>dev-db/postgresql-server-8.4.4-r3' >> /etc/portage/package.mask
# Указываем USE-флаг ради которого все затевалось
echo '=dev-db/postgresql-server-8.4.4-r3 1c8' >> /etc/portage/package.use

Установка PostgreSQL с патчами от 1C - gentoo-way

Посмотрим, что нам скажет emerge:

emerge -pv postgresql-server
[ebuild   R   ] dev-db/postgresql-server-8.4.4-r3  USE="1c8 nls perl python -doc -pg_legacytimestamp \
(-selinux) -tcl -uuid -xml" LINGUAS="ru -af -cs -de -es -fa -fr -hr -hu -it -ko -nb -pl -pt_BR -ro -sk -sl \ 
-sv -tr -zh_CN -zh_TW" 0 kB [?=>1]

Total: 1 package (1 reinstall), Size of downloads: 0 kB
Portage tree and overlays:
[0] /usr/portage
[1] /usr/local/portage
[?] indicates that the source repository could not be determined

Как видим система по-умолчанию выбирает нашу сборку (когда 9 версия будет размаскированной, что-то придется поменять в /etc/portage). Emerge увидел два дерева портежей - системный и наш локальный, среди флагов USE появился флаг 1c8.

Для 1с-сборки PostgreSQL, помимо самого флага 1с8, флаги tcl, perl, python, selinux не являются обязательными, т.к. вроде бы являются биндингами к соответсвующим ЯП, насчет остальных не уверен.

А теперь ставим:

emerge -av postgresql-server

Если внимательно посмотреть, то заметим, что после распаковки исходников, происходит наложение патчей по порядку:

postgresql-8.4-common.patch
postgresql-8.4-server.patch
postgresql-8.4-1c8all.patch

А после того как СУБД будет установлена в директорию (можно увидеть при работе процедуры копирования файлов при установке) /usr/lib64/postgresql-8.4/lib64 помимо идущих в комплекте файлов модулей, будут лежать 1с-ские модули: fasttrun.so, fulleq.so и mchar.so.

Почистим /tmp, больше не пригодится

rm -rf /tmp/postgresql

и небольшой лоск (т.к. делал от рута)

chown portage:portage -R /usr/local/dev-db

Послеустановочный тюнинг

В интернете много сообщений на тему руганья 1с-ки: ERROR: Invalid value for parameter "lc_messages":"en_US". Для Gentoo смотрим:

cat /etc/locale.gen | grep -v "#"
en_US.UTF-8 UTF-8
ru_RU.UTF-8 UTF-8

По рекомендации из того же файла проверяем файл /usr/share/i18n/SUPPORTED | grep "en_US"

en_US.UTF-8 UTF-8
en_US ISO-8859-1

и добавляем локаль:

echo 'en_US.ISO-8859-1' >> /etc/locale.gen

и обновляем систему:

locale-gen 
env-update && source /etc/profile

Скорее всего это не совсем поможет, - читаем дальше.

Файл /etc/conf.d/postgresql-8.4

Смотрим файл на предмет переменных, кластер баз данных по-умолчанию находится по адресу PGDATA, можно поменять как угодно, у меня было так:

PGDATA=/var/lib/postgresql/8.4

поменял на

PGDATA=/var/lib/postgresql

Установим:

PG_INITDB_OPTS="--local=ru_RU.UTF-8"
# Это чтобы PostgreSQL начал слушать на всех адресах, можно указать конкретный
PGOPTS="-h 0.0.0.0"
PG_EXTRA_ENV="LC_ALL=\"ru_RU.UTF-8\""

Но и в таком случае тема "lc_messages" может себя не исчерпать, то делаем вмешательство в скрипт запуска/останова - где-нибудь в начале файла, перед описанием функций, добавляем:

export LC_ALL=ru_RU.UTF-8

На старт...

Если внимательно смотреть лог установка СУБД, то там при окончании процедуры установки говорится, что прежде чем запускать кластер нужно его инициализировать:

emerge --config =dev-db/postgresql-8.4.4-r3

А затем запускаем:

/etc/init.d/postgresql-8.4 start

Для разрешения авторизации на сервере с других компьютеров сети, покорректируем файл /var/lib/postgresql/data/pg_hba.conf, добавив строку

host all all <сетка>/<маска> trust
host all all <сетка>/<маска> md5
# хотя можно просто 0.0.0.0/0

не забыв после этого выполнить перезапуск: /etc/init.d/postgresql-8.4 restart

Отладка и запуск

Ну и напоследок классика жанра - проверить, что PostgreSQL действительно запускается и работает:

netstat -na | grep 5432
ps ax | grep postgres
tail /var/log/messages
tail /var/lib/postgresql/data/postmaster.log

Авторизация на сервере

От рута

su postgres
psql template1
psql# ALTER USER postgres WITH PASSWORD 'newpassword';

Теперь можно из 1с-ки цепляться к серверу указав имя пользователя postgres и пароль newpassword, а также почитать на тему разграничения прав доступа.

Размышления

• Насчет прав доступа к файлам прошу не обращать внимания, полагаю что Linux-пользователи понимают разницу в уровне доступа для /tmp и /usr, так что где нужно, естественно производится переключение на root (su, sudo, etc).
• Сами 1с-цы обязуют к использования библиотеку ICU (http://icu.sourceforge.net), хотя она у меня была установлена ранее (eix dev-libs/icu), но беглый просмотр исходников показал, что данная библиотека используется для Windows-сборки PostgreSQL, но вроде бы в модуле mchar (sources/contrib/mchar) в описании Makefile также встречается ее упоминание. Раскопал:

ldd /usr/lib64/postgresql-8.4/lib64/mchar.so 
       linux-vdso.so.1 =>  (0x00007fff105ff000)
       libicuuc.so.44 => /usr/lib/libicuuc.so.44 (0x00007f452ea67000)
       libicui18n.so.44 => /usr/lib/libicui18n.so.44 (0x00007f452e693000)
       libc.so.6 => /lib/libc.so.6 (0x00007f452e337000)
       libicudata.so.44 => /usr/lib/libicudata.so.44 (0x00007f452d2f7000)
       libpthread.so.0 => /lib/libpthread.so.0 (0x00007f452d0da000)
       libdl.so.2 => /lib/libdl.so.2 (0x00007f452ced6000)
       libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/libstdc++.so.6 (0x00007f452cbcb000)
       libm.so.6 => /lib/libm.so.6 (0x00007f452c947000)
       libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f452c730000)
       /lib64/ld-linux-x86-64.so.2 (0x00007f452efed000

Так что будут у кого руганья при сборке, то сначала поступить так: emerge -av dev-libs/libicu, хотя может по зависимостям и вытащит (но в ebuilde ничего такого не нашел и, скорее всего надо будет руками добавлять).

• В статье автор описывает ручную установку функции datediff в кластере, а также еще чего из SQL-диалекта, однако при загрузке ранее сделанного дампа БД из ранее установленной PostgreSQL (установка на Debian из готовых deb-пакетов), функции уже имелись в наличии, правда они были только для конкретной базы, а не всего кластера (опять же могу ошибаться, хотя в Makefile модулей contrib есть упоминания про sql-файлы, которые возможно заливаются в кластер при его инсталляции, даже если и так, то думаю не составить труда выдернуть SQL-дампы этих функций и записать их в шаблон).

postgres@localhost echo "\df" | psql testbase1
выдает кучу функций среди них и datediff и еще пара десятков, судя по названию которых и есть необходимый набор.

• Данная статья не означает что рассмотренный способ еть Gentoo-way, однако приближение все-таки ощущается.
• Для других версий СУБД и дистрибутивов работа с патчами будет выглядеть аналогичным образом.
• Не являюсь гуру Gentoo в частности и *nix-ов в целом, поэтому не исключено что уже имеются где-то оверлеи в которых уже все отлажено и готово к употреблению, а также существуют более красивые решения.
• В данном случае поставленная цель достигнута, сервер БД установлен и инсталляция отражена в пакетном менеджере, так что какие-либо инструменты устанавливаемые в дальнейшем будут "знать" и работать с данной версией.
• Если использовать USE="-1c8", то будет устанавливаться оригинальная версия с гентушными наработками без патчей от 1с.
• Сам ни в коем случае не являюсь 1с-ником, то мои познания в этой области заканчиваются инсталляцией и демонстрацией запуска 1с-ки. Так что если есть какие баги, то я о них пока не знаю.
• Моя первая статья, надеюсь кому поможет.

Ресурсы

• man ebuild
• man make.conf
• man patch
• man diff
• СУБД PostgreSQL
• Патчи компании 1С для СУБД PostgreSQL
• FTP-сервер компании Etersoft

Другие рецепты инсталляций

• Ubuntu
• RPM дистрибутивы
• Статья на хабре
• И еще масса вариаций рассказывающих "как я с другом ставил..." - вносящие корректировки в уже обкатанные рецепты.

Файлы

В архиве прилагается готовый ebuild и результирующий патч Медиа:Gentoo-postgresql-1c8.zip.