Собственно, для чего этот сайт

Что это такое
Это сайт, посвященый пользовательской (то есть выполняемой отдельным пользователем, а именно мной) сборке офисного пакета OpenOffice под ОС FreeBSD 7.x. Сборка выполняется с помощью собственного порта openoffice.org-3.1.1-citycat, который представляет из себя сильно модифицированный стандартный порт editors/openoffice.org-3. Последняя сборка выполнялась компилятором GCC 4.2.1, который является стандартным системным компилятором (в версии 6.x компилятор приходилось устанавливать отдельно)
Текущая версия пакета 3.1.1
Изменения от "Инфра-Ресурс" за 17 сентября 2009 года
Всерьез обдумываю вопрос отправки порта в дерево портов или хотя бы в качестве патчей к существующему порту

Зачем это нужно
Несмотря на то, что существует достаточно большое количество сборок, выполняемых как непосредственно Sun, так и "Инфра-Ресурс", в определенных случаях лучше сделать свою собственную сборку. Например, когда хочется использовать уже установленные библиотеки. Или данная версия операционной системы не поддерживается. Или еще что-нибудь. Или просто хочется попробовать свои силы в самостоятельной сборке. Поскольку FreeBSD - система, изначально ориентированная на сборку всего на свет из исходных текстов, вполне естественно было попробовать собрать самому и OpenOffice.:-))

Отличия от других сборок
На самом деле большого количества пользовательских сборок мне неизвестно. Существует, разумеется, ванильная сборка, то есть сборка, выполняемая собственно Sun, на основе оригинального исходного кода. Существует естественно для нее порт - editors/openoffice.org-3. Эта сборка делается под все платформы, в том числе и под FreeBSD. Существует сборка от Инфра-Ресурс, выполняемая на основе оригинального исходного кода с внесением собственных дополнений - суффикс "Про" добавляется к ней вовсе не зря. Для нее существует "неофициальный" порт, отсутсвующий в дереве портов, который тем не менее можно скачать , распаковать и собрать на его основе OpenOffice Pro.

Существует автономный пакет в формате PBI для PC-BSD, ссылку на который можно найти на странице Информации

Так чего же такого особенного в моей сборке?
Говоря одним словом - гибкость. Говоря многоим словами - возможность достаточно гибкого и разнообразного задания настроек сборки - можно задать использование той или иной библиотеки, включить или выключить использование того или иного компонента. Поскольку сами компоненты, если они размещены вне OpenOffice.org, обновляются сами по себе, собственными разработчиками, это дает исключение ошибок, связанных с ними, в то время как интегрированные во время сборки компоненты так и "зависают" до обновления версии. Все это делатеся с применением стандартного для FreeBSD механизма опций. Кроме того, в порту существуют некоторые мелкие улучшения, например при выборе опции KDE корректно создаются каталоги для значков.
Правда, эта гибкость имеет и обратную сторону - при мажорном изменении API пакет может перестать работать, поэтому всегда перед крупным изменениеем в библиотеках сохраняйте пакеты со старой версией!
Порт регулярно обновляется - при выходе каждого следующего ванильного порта создается новая версия, отличия от предвдущих сборок и прочие изменения будут описываться в разделе новостей

Как все начиналось
Всё началось с того, что мне не понравилось название каталога установки вышедшего только что OpenOffice.org 1.1. Поскольку предыдущая версия, OpenOffice.org 1.0.1, была заказана мной в ЛинуксЦентре, новую заказывать и ждать еще две недели не хотелось. Хотелось установить в тот каталог, в который считал нужным. Поскольку не нашел другого пути, кроме как собирать из исходников, глубоко вздохнул и начал... Произошло это в ноябре 2003 года.
Моя первая сборка, OpenOffice.org 1.1 была выполнена под FreeBSD 4.9 и выкладывалась еще на ftp.iqchoice.com. Никаких "хроник сборки" в те времена я не вел, полагая, что это работа разовая, что в следующей версии будет все, что устроит меня. Наивный... Эта же сборка распространялась ЛинуксЦентром. Я ужасТно горжусь этим :-)))
Потом была версия 1.1.1, потом 1.1.2, потом 1.1.3, которую я не собирал, а взял готовую. Это настолько мне не понравилось, что следующую версию (1.1.4) я уже собирал, излагая "хроники сборки" на манер эпистолярного жанра. Происходило это 22 марта 2005 года. На странице загрузки можно найти ссылку на сообщение, отправленное тогда в список рассылки oo-discuss@openoffice.ru (который существует и поныне).
Потом была версия 1.1.5 - последняя из ветки 1.x. Потом - 2.0.1, правда в свзяи с недостатком времени собирал не "Про" версию, а ванильную, а про нее что интересного рассказывать - запустил make в каталоге порта и пошел домой... Да и время в моей жизни тогда было беспокойное - дважды за год сменил работу, купил квартиру по ипотеке, заочно закончил институт...
Но все в жизни кончается и этот период "колбасы" кончился тоже. С марта этого года, начиная с версии 2.0.3, я веду постояный топик на форуме поддержки OpenOffice.org, который называется FreeBSD/x86: хроники сборки, (ранее называлась "FreeBSD 6.x: хроники сборки", но была переименована после миграции на 7.x и названа так для отличия от подобного же топика про amd64, который ведет Azatoth) где я излагаю всё, что происходит со мной при сборке очередной версии OpenOffice.org. Здесь же публикуются все патчи, которые делаю, новые версии порта, описаний, любых лругих файлов... Хотя последнее время большая часть информации публикуется на странице Скачать

Как все происходит
Здесь надо отметить, что делаю это все я исключительно в свободное время. Раньше, пока у меня не было возможности выйти в Интернет из дома, я все это делал на работе, но, получив такую возможность, перенес сборку домой - у меня домашняя машина мощнее рабочей раза в два, как минимум. Поэтому мой порт может выйти с задержкой на неделю, на две недели а то и на месяц после выхода ванильного порта, а может и вообще не выйти - например, 3.1.1 я собрал с задержкой более чем в полгода. Кроме ванильного порта, я обычно дожидаюсь появления пакета с патчами, картинками и файлами локализации от Инфра-Ресурс и порта, которым собирается сборка "Про" версии, распространяемой Инфра-Ресурсом. Хотя вот нынешний порт знаменателен, кроме всего прочего еще и тем, что картинки в нем взяты не из порта "Инфра-Ресурса", а из ванильного.
Сгребя в кучу все это, начинаю править порт, взяв за основу предыдущую версию. Просматриваю параллельно ванильный порт, порт "Инфра-Ресурса" и свой старый и вношу коррективы, внесенные в ванильный или инфровский порты, которые считаю полезными для себя. Обязательно сверяю каталог патчей - старые удаляю, новые переписываю из ванильного - пополнение этого каталога может происходить и помимо OpenOffice.org IssueZilla.
После распаковки обязательно скопирую рабочий каталог на тот случай, если придется откатывать. Причем копирую не один раз, а зачастую раза 3-4, из-за чего бывает даже не хватает места.
Как правило, наиболее сложным шагом является наложение патчей. Поэтому в последней версии моего порта (1.11) был применен механизм full automation. Работает он следующим образом - первая сборка (мной) все равно выполняется руками. При этом собираются все шишки, все баги и глюки при приложении патчей от Инфра-Ресурс к исходникам. Здесь надо заметить, что с версии 3.1.1 я тоже стал использовать резаные на бандлы исходники, потому что один большой файл сейчас не выкладывается. После сбора всех шишек и исправления всех багов, точнее говоря по мере исправления всех ошибок, вносятся изменения в файл apply, а также в файлы патчей если это необходимо. После применения всех патчей от Инфра-Ресурс исправленный файл apply и все доработанные пачти запаковываются каждый bzip2 и помещаются в архив файлов поддержки, в каталог infra. Перед началом сборки, на шаге pre-patch выполняется замена файлов в каталоге Инфра-Ресурса доработанными версиями. Вот такое вот "патченье патчей" :-). Опять же надо заметить, что при сборке 3.1.1 необходимость в этом возникла только ордин раз.
В мишени do-patch происходит применение ванильных патчей
В мишени infrapatch происходит применение патчей от "Инфра-Ресурс". В отличие от мишени do-patch, мишень infrapatch можно выполнять неоднократно без проблем - все патчи тестируются перед применением, уже примененные просто игнорируются. Здесь надо заметить, что мишень infrapatch выполняется как зависимость на шаге pre-configure. Это сделано совершенно намеренно, чтобы зафиксировать шаг patch, посколькку примененные ванильные патчи не откатываются и при попытке заново запустить шаг сборка ломается
В мишени catspatch поисходит наложение патчей имени меня. Сейчас файлов с патчами три:
  1. Файл configure_patch.diff - набор патчей для файла configure.in. Файл этот вносит следующие изменения:
    • Аргумент --with-gstreamer для configure
    • Использование параметра X_LDFLAGS (/usr/X11R6/lib) при тестировании наличия компонентов
    • Обработка параметра --with-gstreamer
  2. Файл set_soenv.diff - набор патчей для файла set_soenv.in. Файл этот вносит следующие изменения:
    • Добавление -L/usr/local/lib в параметр SOLAREXTRALIB
    • То же самое, но в параметр SOLARLIB (а иначе не работает)
    • Добавление пути -I$SRC_ROOT/scripting/$INPATH/inc в параметр SOLARINC
    • Добавление пути -I/usr/local/inclide в параметр SOLARINC
  3. Файл settings_mk.diff - патч для файла settings.mk. Содержит один патч, добавляющий к параметру CFLAGS пути, задаваемые параметрами $(X11BASE) и $(LOCALBASE)
Если эти патчи не применять, то сборка выпадет при первом же обращении к внешней библиотеке. Как правило это происходит в модуле sax. Почему в них не возникает необходимости при сборке ванили? Потому что ваниль устанавливается в /usr/local и поэтому каталог /usr/local и его подкаталоги учитываются автоматически, а X.org опять же в стандартной установке давно перенесен тоже в /usr/local (то есть в /usr/local теперь сложено все, что не в базовой системе). Наложение патчей делается той же программой, что накладывает патчи от "Инфра-Ресурс", подпатченой только на предмет создания другого каталога для примененных патчей. Необходимость такого вот изменения привела к тому, что я стал распространять эти патчи, плюс картинки для сборки плюс правленый ru-vendor.sdf (содержит надпись "Этот продукт создан...") в отдельном архиве
После того, как отработает configure, опять копирую рабочий каталог
Запускаю сборку с параллельной записью в лог -
# make.port all > make.log & 
# tail -f make.log
и занимаюсь чеи-нибудь другим, параллельно поглядывая на экран сборки. Собирать дома не очень удобно - когда наступает глубокая ночь, пора спать, а обрывать идущую сборку ой как не хоооооочется....
Если сборка ломается, то смотрю протокол, устраняю ошибки и заново. И так до победного.
Когда сборка все-таки завершается, сношу старую версию OpenOffice.org, устанавливаю новую и тут же собираю пакет, чтобы не дай Бог, ничего не пропало. Собранный пакет будет выкладываться здесь

Порядок сборки и установки

Увы, порт пока все все еще нуждается в специальном руководстве по применению, хотя я очень надеюсь, что недалек тот день, когда можно будет просто сказать make.port all install, выключить монитор и лечь спать, а утром получить готовый пакет :-) В теории так уже и должно быть - ведь недаром я назвал этот порт "full automation" :-) Но на практике все может оказаться иначе...

После загрузки архива с портом его следует распаковать куда-нибудь, например в /usr/ports/editors, зайти в него и запустить make.port extract. Если Вы ни разу еще не пользовались портом Cat's Paw, то система автоматически перейдет к заданию набора опций сборки. По умолчанию опции рассчитаны на минимальное использование системных библиотек и максимальное использование собственных. Если же Вы уже пользовались портом Cat's Paw, но хотели бы изменить набор опции, запустите make.port config. Этот шаг распакует все исходники и все наборы файлов поддержки

После этого запустить make.port configure - этот шаг заменит файлы Инфра-Ресурс (если это необходимо) для устранения ошибок сборки, применит ванильные патчи, применит патчи Инфра-Ресурс, применит мои патчи и запустит configure. Если все успешно завершено - можно запускать make.port без параметров (аналогично параметру all) и ждать...

Ориентировочное время сборки на компьютере с CPU E4500, 2GB RAM, 250 Gb SATAII HDD составляет порядка 6 часов (и то при условии максимального использования системных библиотек).

Еще увидимся...
Искренне Ваш,
Master UNIX administrator