Maintainer's wiki

Repost:

Вот ищу вот сабж. Хотелось бы иметь много инфы в одном месте. Что порекоммендуете?

Проще всего работать с пакетами GNU Autotools
./configure --prefix=/opt/nonexistent блаблабла && make && DESTDIR="..." make install

Автотулз у меня на ура пошли. трабли были разве что с пакетом jpegsrc. Он давно не обновлялся, года так с 96го. И автотулз там тоже не новые были использованы. DESTDIR не понимается, make install не делится на make install-data и make install-exec, а ведь мне выгоднее сначала задестдирить экзеки от разных архитектур, чтобы склеить в универсальный бинарник, а уже потом добавить данные от одной архитектуры. Данные ведь всё равно склеивать не надо. Ладно, лишние подробности.

Особенно не понравились пакеты на языках perl и python. У них отсутствует ./configure и этапы make как таковые. Вместо этого там исполняемые файлы setup.py и makefile.pl. Неприятность работать с ними заключается в том, что там всё по–своему. Те пакеты, которые меня интересуют, содержат "вкрапления" на C, и мне не нравится, что, если я чего-то упустил, то система сборки начинает своевольничать. Чтобы этого не было, я сначала собираю ppc архитектуру (а у меня intel). Если система сборки вдруг решает, что она умнее, чем я, то она во многих случаях обссыкается, и я вижу, где это произошло. Если компилеру или линкеру не передать -arch ppc, то они пытаются собрать в родной i386 архитектуре, при этом зависимости собраны по-прежнему в ppc. Если я собираю pygtk, то во время компиляции я настраиваю среду окружения на ppc версию gtk+, а не на универсальную, хотя она уже к этому моменту готова. У меня складывается впечатление, что в сами python и perl вшиты какие-то ключи компиляции, которые, если недосмотреть, могут заменять те, которые хочу использовать я.

В общем, охота, чтоб в одном месте было много инфы о том, как производить сборку разнотипных пакетов. Меня интересует создание unattended инсталляций. И как настраивать среду окружения при этом. Что делать, если нужно использовать python, который стоит в системе и что делать, если нужно использовать тот, который идёт в слепке. Сами по себе слепки не является перемещаемыми, просто ни одна программа из слепка не вызывается снаружи напрямую. Снаружи вызывается обёртка, которая настраивает среду так, что все программы внутри могут нормально работать. На Mac OS X это стандартный способ портировать программы, сделанные на autotools и пр. Вообще, я видел подобные "слепки" и под linux, вспомнить хотя бы GNAT GPL. gps настраивает среду и вызывает gps_exe.

Собственно задача -- прокачать скиллы мейнтейнера, а создание слепков -- это приятное с полезным.

Может я чего не понял (ночь+температура+многобуковок), но нужен ресурс о создании пакетов программ? Тогда нужно читать о создании rpm, deb, tgz и ebuild на страницах соответствующих дистрибутивов. Пользоваться checkinstall`ом (решение для ленивых и не всегда работает) либо мозгом смотреть внутрь установщика (труЪ, но всегда есть вероятность что-либо упустить).

Чтобы сделать deb, нужно уметь сделать слепок, и все эти deb, rpm -- это уже дальнейшая обработка этого слепка.

> на страницах соответствующих дистрибутивов

Это-то и плохо, что разрозненно.