дебиан дебиану люпус эст

можно попробовать в билдсервисе собрать... там, судя по http://software.opensuse.org/search для 4.0 и для 5.0 есть возможность собирать пакеты.

Не, это вряд ли пригодится. Один дистр у меня убунта, второй маемо;)

Сергей, нужен pbuilder!

>Не, это вряд ли пригодится. Один дистр у меня убунта, второй маемо;)

А вот это я не дочитал. Я-то думал, что надо собрать пакет для двух именно дебианов (которые lenny, sid, etch и т. д.).

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

А втупую - сделать каталоги debian-native и debian-maemo, и перед сборкой создавать симлинк на нужный?

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

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

Файл рулесов задавать можно, а в нем в принципе все остальное.

-Rrules-file
              Building  a Debian package usually involves invoking debian/rules as a command with several standard parameters. With this option it’s possible to use another program invocation to
              build the package (it can include space separated parameters).  Alternatively it can be used to execute the standard rules file with another make  program  (for  example  by  using
              /usr/local/bin/make -f debian/rules as rules-file).

А в рулесах можно указывать разные postinst?

Хотя тут больше к билду относится...

Там гдето вы вызываете dh_installdeb А ему можно передать -p SomeNameHere И тогда будут инсталится файлы типа SomeNameHere.postinst

Вроде так. Непробовал )

> Там гдето вы вызываете dh_installdeb
Гхм. Примерно понятно. Но жестко, да...

>Там гдето вы вызываете dh_installdeb А ему можно передать -p SomeNameHere И тогда будут инсталится файлы типа SomeNameHere.postinst

Тогда можно и dh_gencontrol (он враппер для dpkg-gencontrol) также. Там тоже можно указать альтернативный debian/control, debian/changelog и debian/files и что-тотам еще. Соответсвенно, в rules сделать условный выбор того или иного файла.

Насколько я понимаю, идеология такая: каталог debian должен быть всегда один, а вариации уже должны решаться внутри него через rules.

Хотя надо бы еще поискать.

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

Вообще-то, там debhelper.mk. А он параметризуем. Поиграемся!

Фигвам. changelog рулезами не параметризуется. Так что, видимо, только симлинки.

Вот из debhelper.mk

# DEB_DH_GENCONTROL_ARGS_ALL
#   Arguments passed directly to dh_gencontrol, for all packages
# DEB_DH_GENCONTROL_ARGS_<package>
#   Arguments passed directly to dh_gencontrol, for a particular package <package>
# DEB_DH_GENCONTROL_ARGS
#   Completely override argument passing to dh_gencontrol.

То есть, если передать dh_gencontrol:

 -lchangelogfile
              Specifies the change log file to read information from. The default is debian/changelog.

Этот параметр должен передаться в dpkg-gencontrol

Подмахнуть переменную можно в зависимости от архитектуры в rules, например.

ifneq (,$(filter armel ,$(DEB_BUILD_ARCH)))
        # Одно
else
        # Другое
endif

Возможно, еще как-то еще можно. Это я все в порядке предположения. Сам, разумеется, не проверял.

Именно так я и сделал.

DEB_DH_GENCONTROL_ARGS_ALL=-ldebian/changelog.ubuntu -cdebian/control.ubuntu


Но оно ломается раньше, еще не доходя до генконтроля. Ибо сам билдпакадж лезет парсить (непараметризуемый) чейнджлог - и обламывается при его отсутствии.

Точно, dpkg-buildpackage раньше лезет в changelog. Он же оттуда версию берет и сопровождающего. То есть, если мы хотим их одних и тех же исходников разные версии сделать для разных систем, то какой-то облом получается.

Именно. Придется грязно возиться с перекидыванием симлинков. Увы.

А я вот чего вдруг подумал. А разве gencontrol не перекрывает Вот debhelper.mk вызывает dh_builddeb. dh_builddep вызывает dpkg-deb. dpkg-deb берет информацию из DEBIAN/control (из man), который gencontrol подготовил. Нельзя ли на первом этапе использовать один из changelog'ов для обоих случаев, а потом поменять в одном варианте на changelog.maemo перед сборкой в deb через gencontrol? Насколько я понимаю, dpkg-gencontrol устанавливает поле Version в DEBIAN/control из changelog, который ему подсунули, а не который лежит в самом начале. Или не так? Не канает такой вариант?

Кстати, сейчас проверил. Взял маленький пакетик. В debin положил обычный changelog (с версией 0.1-1) и changelog.test (с версией 0.1-2), а в rules тупо вбил:

dh_gencontrol -u-ldebian/changelog.test

В результате собрался пакет с версией 0.1-2_i386.deb, как и предполагалось.

В результирующем DEBIAN/control:

Version: 0.1-2

Мысль я понял. Но что-то в этом есть кривовато-хакерское, не находите?

>Мысль я понял. Но что-то в этом есть кривовато-хакерское, не находите?

Я думаю, что метод при данном раскладе в системе сборки достаточно прямой, ИМХО. Раз идет сборка под разные ахрхитектуры да еще и с разным окружением (postinst и др. скрипты) для разных дистрибутивов, с разными версиями, то все-равно должен где-то сработать механизм "для этого варианта сборки мы берем эти файлы, а для другого -- другие". Поскольку сборкой пакета занимается множество разных скриптов, то и файлы "подмахивать" придется в разных местах по условию. А вот условие для maemo надо придумать. Как вариант -- целевая архитектура, но в общем случае на целевую архитектуру arm может захотется собрать и под ubuntu, поэтому неплохо бы было заиметь выбор по имени дистрибутива, что-ли, а не только по архитектуре.

Можно рассматривать нормальный changelog как умолчательный, а changelog.maemo, как дополнительный.

> то все-равно должен где-то сработать механизм "для этого варианта сборки мы берем эти файлы, а для другого -- другие".
Это безусловно. И можно обсуждать, как именно выполнять переключение. По имени дистрибутива - вполне осмысленный вариант.

> Можно рассматривать нормальный changelog как умолчательный, а changelog.maemo, как дополнительный.
Вот это как раз вызывает внутренний протест. Понятие "умолчательного чейнджлога" (точнее даже "загрузочного") - это оченб странно. Поверх этого решения написано большими буквами (72, болд) "архитектура не позволяет параметризовать в этом месте, поэтому мы ставим аккуратненький костыльчег".

Да, гораздо более простым способом была бы возможность выбрать каталог debain со всей сборкой в dpkg-buildpackage, но там только rules можно выбрать. Я вот все искал, нет ли какой переменной среды, может быть. Но пока не нашел. Даже в исходники залез dpkg-buildpackage и в /usr/share/perl5/Dpkg, но там, похоже, гвоздями debian/changelog прибит.

> но там только rules можно выбрать
Это была б не такая большая беда, если б в рулезах можно было бы переопределять все, что нужно. Создал debian.maemo, в нем rules - и там определил все переменные... Но ведь фигвам!

> но там, похоже, гвоздями debian/changelog прибит
Именно. Поэтому я и говорю, что решение с дефолтным чейнджлогом явственно отдает запахом свежесоструганного костыля;)

ЗЫ Я уже тоже добрался до Dpkg;)

Хотя билдсервера на Debian наверняка тоже не вызывают сборку в скрипте, где подставляют целевую архитектуру из своего списка, под что надо собирать. Так что такой нестандартный случай, как сборка для разных дистрибутивов тоже может и из скрипта запускаться, который симлинк debian меняет или, например, симлинки отдельно для файлов в debian/*. Мне не совсем понятно, как сказать rules, какой сейчас дистрибутив имеется в виду. Откуда брать такую переменную? А она вообще есть? Для целевой архитектуры есть, а для дистрибутива...

"не вызывают сборку в скрипте" -> "вызывают сборку в скрипте"

> может и из скрипта запускаться, который симлинк debian меняет
Ну да, так тоже можно. Все в этом мире можно исправить должным кол-вом оберток;)

> Мне не совсем понятно, как сказать rules, какой сейчас дистрибутив имеется в виду.
Есть же опции -D -T -V у dpkg-buildpackage. Что-нибудь из них. В явном виде переменная мне неизвестна...

>Есть же опции -D -T -V у dpkg-buildpackage. Что-нибудь из них. В явном виде переменная мне неизвестна...

dpkg-architecture их и покажет.

>Есть же опции -D -T -V у dpkg-buildpackage. Что-нибудь из них.

И, кстати, эти опции не дадут знания rules о том, какой дистрибутив. У двух дистрибутивов разных (скажем, Knoppix и Debian) эти переменные могут совпадать. Тут для rules именно какая-то дополнительная переменная нужна, чтобы автономно сборка прошла. По-моему, такой переменной документированной нет (?). Есть места, где название дистрибутива может лежать с достаточной вероятностью, и его можно прочесть (например, /etc/debian_version), но это ненадежно в общем случае. Сказанное имеет смысл, если решать именно задачу, чтобы rules сам разбирался, как собирать пакет для разных дистрибутивов без внешнего скрипта. А если с внешним скриптом, то тогда любой вариант подойдет. Тот же симлинк на debian менять, например.

> Сказанное имеет смысл, если решать именно задачу, чтобы rules сам разбирался
Да, тогда согласен. Тогда надо понапихать рулезов по проверке разных дебиановских дистров "не убунта ли, не маемо ли, не дебиан ли, ..."

>Да, тогда согласен. Тогда надо понапихать рулезов по проверке разных дебиановских дистров "не убунта ли, не маемо ли, не дебиан ли, ..."

Я вот сейчас сразу не соображу, но, наверное, скрипт, который подменяет файлы в /debian можно же прямо в /debian и положить. Далее попробовать написать такой rules, чтобы он сначала до сборки поменял линки, собрал пакет, а потом опять поменял линки и опять собрал пакет. Тогда, в принципе, можно одним вызовом dpkg-buildpackage получать две версии пакетов. Ну и сделать так, чтобы можно было это отключить, если вдруг это предполагается в какой-то репозиторий потом отдавать -- там-то это поведение не нужно.

А можно написать две версии rules: rules и rules-maemo. Каждая будет симлинки менять на нужные файлы в /debian (скажем, лежат postinst.maemo, postinst.ubuntu и линк postinst). Эти rules уж точно можно выбрать через параметры dpkg-buildpackage (опция -R).

Хотя все это кажется слишком заумным решением по сравнению с простой подменой линка на каталог debian.

Все, пора спать. Сегодняшний день прошел под знаком системы сборки Debian. :)

> Эти rules уж точно можно выбрать через параметры dpkg-buildpackage (опция -R).
Дык об этом я уже выше сказал - если мы не ставим условие полного автоматизма, то опции -R было б достаточно. Если бы не было идиотского обычая лезть в чейнджлог до обращения к рулезам.