Сборка deb пакетов и git (философская ситуевина - яйцы vs курицы)

[dimbor]

Сначала хотел написать в раздел Debian. Потом вспомнил, ситуация недетски напрягала и под другими пакетными менеджерами - rpm, portage. Это только теми, с чем работал.

Итак. Имеется проект xxx, офигенной сложности и глючности. Посему на всем жизненном пути проекта он патчится неоднократно. Естественно, у проекта есть конкретное имя. Но т.к. много их - таких проектов, не акцентирую. Далее сидят человеки, занимающиеся пилением проекта. Берут человеки гит, сливают туда исходники (upstream), комитят патчи, мержатся тэгятся и занимаются прочими программерскими непотребствами. Удобно. Появляется результат, который надо донести до потребителя. Потребители живут под разными системами и архитектурами.
Надо им предоставить соответствующие бинарные пакеты. Как? - Да собрать!

Пытаются собрать человеки пакет под конкретную систему, и тут их ждет облом. Сами не могут. Вернее могут, но только под свою. Надо идти на поклон к специальным другим человекам, специализирующимся на сборке пакетов под конкретную систему - мантейнерам или ментейнерам (по вкусу). Тьма их, они по большей части ленивы, нелюдимы и мизантропы. И вообще абонент вне зоны доступа. Но это мелочи. Главное, что они при сборке пакета тоже берут апстримовские исходники кучкой и накладывают на них патчи по очереди. В кучу фукциональные из "разработческого" гита и свои - мантейнерские. Накладывают средствами своего менеджера пакетов. И у них как правило тоже есть свой гит, хранящий историю _сборок_ - требуху конфигов пакетного менеджера, самих патчей и тарболов исходников. Т.е. без пузыря и досконального знания конкретного менеджера нифига не разобраться. Снос башки, кароч.

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

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

Хорошо бы еще в том же гите, хранить и мантейнерскую требуху для разных систем по разным каталогам. Да еще и автоматизировать процесс сборки. Из похожего в сети нашел git-deb-conf. Есть также штуковина под названием git-buildpackage. Но вот именно она и ориентирована на мантейнеров, причем сугубо дебиановских.

Просьба прокомментировать данный поток сознания. Не может же быть, чтобы я один озадачился подобным.

[Bizdelnick]

патчи, необходимые данной системе, и только ей

А можно пример таких патчей? Ни разу не приходилось сталкиваться. В самых запущенных случаях проблема решается #ifdef-ами, но обычно намного проще. Если, конечно, ЯП не совсем экзотический, и код без приставки "быдло-".

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

В случае Debian всё просто - требуха аккуратно складывается в каталог debian. В случае rpm всё намного сложнее, но они, как я понимаю, пока не особо интересуют?

[Hephaestus]

Просьба прокомментировать данный поток сознания. Не может же быть, чтобы я один озадачился подобным.

Собственно, я не понял, в чем проблема.
Абстрактная софтина в вакууме собирается стандартными командами
configure && make && make install
и всё.
Создание пакета под конкретный дистр - это проблема дистра. Ибо дистры все разные, форматы пакетов разные, политики разные. Отсюда и мантейнерские патчи.
С какой стати вся эта дистростроительная кухня должна волновать разработчиков - совершенно непонятно.
Тем более непонятно, на кой ляд нужно в апстримовский гит пихать дерево патчей, да ещё под разные системы, то бишь дистры.
Другое дело - мантейнеры нашли крутую багу, пропатчили, отправили автору. Автор прикинул, либо принял, либо нет.
А содержать для каждого проекта кучу всякой всячины, да ещё под разные дистры - никаких интернетов не хватит.
Сборка пакета с учётом политики дистра - это проблема дистра, а не разработчика. Разработчик про конкретные дистры знать ничего не знает и не должен, ибо их 100500 штук.

[Bizdelnick]

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

Майнтейнерские патчи как правило не отсюда. Они чаще всего либо от желания пофиксить баг, не поднимая версию пакета (в таких случаях патч берётся из VCS апстрима), либо из-за не собирающегося быдлокода (в таких случаях патч отправляется в апстрим), либо от желания добавить совсем специфическую фичу, либо для выпиливания чего-то, не устраивающего по лицензионным соображениям. Если сборку пакетов берёт на себя непосредственно апстрим, как в данном случае, все перечисленные мной категории патчей не нужны.

Сборка пакета с учётом политики дистра - это проблема дистра, а не разработчика. Разработчик про конкретные дистры знать ничего не знает и не должен, ибо их 100500 штук.

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

[Hephaestus]

А можно пример таких патчей? Ни разу не приходилось сталкиваться.

Ну как же? В том же дебе есть.
Для приведения пакета в соответствие с политикой дистра. Какие-то там файлы, каталоги создаются.
Или файлы перераспределяются по структуре каталогов.
Если где-то есть соотвествующие команды (например, в Makefile или в скриптах), то для исправления потребуется патч.

Я с таким сталкивался в дебе, только деталей уже не вспомню.

[Hephaestus]

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

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

[Bizdelnick]

Для приведения пакета в соответствие с политикой дистра. Какие-то там файлы, каталоги создаются.
Или файлы перераспределяются по структуре каталогов.

Это делается сборочными скриптами, а не патчами.

Если где-то есть соотвествующие команды (например, в Makefile или в скриптах), то для исправления потребуется патч.

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

[Hephaestus]

Это делается сборочными скриптами, а не патчами.

Ну вот, например.
Это ведь патч? Патч.
Дистроспецифичный? Вроде, да. И имеется он, кажись, у каждого пакета.
Другое дело, что патчится там, может быть, не авторский исходник (хотя не исключено), а что-то иное.
Но тем не менее, это вполне себе патч и нужен он только для деба.
И ежели складывать в гит апстрима дистроспецифичную требуху, как предложил ТС, то данный патч должен будет там находиться, насколько я понимаю.

[Bizdelnick]

Это ведь патч? Патч.

Это немножко не тот патч. :-)
Всё, что он делает, - добавляет каталог debian с той самой требухой. В состав которой входит и подкаталог patches с теми патчами, которые накладываются непосредственно на код. От такого странного способа хранения майнтейнерского хозяйства, кстати, сейчас отходят.

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

Он там будет в уже наложенном виде, то есть в виде каталога debian с файлами в нём, а не как патч.

[dimbor]

патчи, необходимые данной системе, и только ей

А можно пример таких патчей? Ни разу не приходилось сталкиваться. В самых запущенных случаях проблема решается #ifdef-ами, но обычно намного проще. Если, конечно, ЯП не совсем экзотический, и код без приставки "быдло-".

Например тут где-то два комита из трех не имеют отношения к самому продукту. Голимое пакетостроительство - патчится не код, а обвес. Конкретно же необходимость патча кода под дистрибутив - вот. Другое дело, что по правильному оно решается sed "тру-ля-ля" host.def перед сборкой. Но можно и патчем.
А вот это вообще за гранью. Настолько упорото-мантейнерский гит, что сами изменения кода добавляются в гит как .patch и патчи этих патчей.

И да, ноги вопроса растут из этой темы. Там ты согласился мне помочь, но я за отсутствием общественного интереса не счел нужным тебя напрягать. Решил сам разобраться - сделать собственный гит без мантейнерского мусора и, от него танцуя, собрать. Потом оказалось, что следуя текущим канонам, я при сборке должен все патчи из гита вытянуть по одному и положить в debian/patches. А потом уж собирать пакет. Причем каталог debian, как тут правильно было тобой замечено, планируется хранить в самом этом гите. Ай-я-яй! Некрасиво может выйти.
Вспомнил, что похожая байда была, когда собирал и ебилды, и rpm-ки.

А теперь еще там и апстрим умер. Так что кто в лес, кто - по дрова. Приходится становиться апстримом самому себе. Со схемой сборки git clone mybranch -> dh... Вот, а каталог то debian тоже будет в гите. И захотелось что-то вроде упомянутого git deb-pkg. С возможностью дальейшего git any-pkg.

С какой стати вся эта дистростроительная кухня должна волновать разработчиков - совершенно непонятно.

С одной стороны да, шериф и проблемы негров - объекты слабокоррелирующие.
А по длительному опыту - до работоспособного состояния продукта годы прошли не потому, что продукт лениво патчился. Патчился он шустро. Собирали потом медленно под распространенные системы. Т. е. тестеры "разработчиком" пинговались почти никак. В тематическом форуме бегамайты адовых страданий за это. Из-за этого и rpm могу собрать, и ебилд, и deb скоро научусь. Хотя интереса к процессу не имею.
(Ну скажем, конкретно деб мне понадобился сейчас, т.к. make install на одном компе, это одно, а на десятке - именно то самое нехорошее.)

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

Выясняется, что на манер исторического персонажа буду теперь всем говорить "Апстрим - это я!"
И апстримовские патчи - какие надо патчи - дистронезависимые! А остальные да, нафик с пляжа, в каталог
debian/patches.

Собственно, я не понял, в чем проблема.

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

[Bizdelnick]

Конкретно же необходимость патча кода под дистрибутив - вот. Другое дело, что по правильному оно решается sed "тру-ля-ля" host.def перед сборкой. Но можно и патчем.

Если по-умному, то не тем и не другим. Я правильно понял, что там сборка голым make'ом делается? Тогда он должен запускать компилятор с опцией -DDefaultFontPath=$(FONTPATH), а переменную FONTPATH можно переписать при запуске make. То есть правим исходник (прячем определение в #ifndef) и мейкфайл, прописываем что надо в rules, и ни патчей, ни седа не надо. Всё дистрибутивоспецифичное оказывается в rules.

Upd. Или другой вариант: имя константы DefaultFontPath намекает, что она устанавливает значение по умолчанию. Если так, то значение не по умолчанию, вероятно, можно прописать в каком-то конфиге. В таком случае вместо накладывания дистрибутивоспецифичных патчей можно класть в пакет дистрибутивоспецифичный конфиг, - это весьма распространённая и оправданная практика.

[Hephaestus]

А по длительному опыту - до работоспособного состояния продукта годы прошли не потому, что продукт лениво патчился. Патчился он шустро. Собирали потом медленно под распространенные системы. Т. е. тестеры "разработчиком" пинговались почти никак. В тематическом форуме бегамайты адовых страданий за это.

И Вы предлагаете облегчить людям жизнь, обязав разработчиков принимать патчи, а заодно держать в гите апстрима куски дистростроительной кухни? Не получится.
Во-первых, ничего, кроме замусоривания гита из этого не выйдет. И эти дистроспецифичные файлы будут лежать одинаковые во многих местах, раскиданные по всему sourceforge.net. Зачем?
И для чего тогда существует команда дистростроителей, если заботы по поддержке пакета по сути перекладываются на разработчика?
Во-вторых, даже если мы допустим на одну минуту, что где-то такое сделали.
Как минимум, возникнет вопрос: Для каких дистров размещать "куски кухни" в гите? Для всех? Так их 100500 штук. Для избранных? Тогда это не имеет смысла, потому что "неизбранные" останутся в том же положении, что и сейчас.
А то, что не было обратной связи с разработчиком и он не принимал патчи - так это опенсурс. Никто ничего никому не должен.

Кстати, Ваш зачин темы

Имеется проект xxx, офигенной сложности и глючности.

Хочу спросить: Если его годами пилят до хоть сколько-нибудь рабочего состояния, тогда кому он нужен?
Может там изначально неверный подход к задаче? Тогда, имхо, его проще форкнуть и пойти други путём, чем полжизни пилить эту никчемность.
На ум приходит два примера: ReactOS и Lightspark. ИЧХ, оба примера пытаются догнать проприетарные продукты/технологии. Путь тупиковый, как следствие, ни ReactOS, ни Lightspark не нужны почти никому.

и rpm могу собрать, и ебилд, и deb скоро научусь.

В сборке deb-пакета, в общем-то ничего сверъестественного нет. Хотя руководство обширное, да.
Нужно использовать dh_make.
Я сталкивался с тремя серьёзными проблемами (это было ещё в squeeze):
1. Отсутствие в дистре сборочных зависимостей нужной версии - это проблема не только деба, а любого дистра - вариантов два: либо ставить зависимости, либо собирать другую версию. Бывает так, что ни то, ни другое, сделать не выходит, этим всё и заканчивается.
2. Прописать зависимости для пакета. Официально рекомендовано было собирать пакет на чистой системе, тогда зависимости видны более явно. Шаблоны, созданные dh_make почему-то не работали. В wheezy это пофиксили вроде бы, а может и нет, не помню. Поскольку я собирал пакеты для себя, то просто забил на эту деталь.
3. dh_make создавал файлы для сборки, но в итоге получался пустой пакет. Я долго разбирался, в чём дело.
Шаблон, созданный dh_make, судя по описанию, должен быть обработать всё, что нужно, но этого почему-то не происходило. Опять-таки в wheezy такой проблемы уже не было.

Да, в дебе мне было сложней собирать пакеты, чем в слаке, например. Но всё-таки собирал, когда надо было.
Хотя я не брезговал и checkinstall использовать, когда уж совсем лень было со сборкой возиться.

[Bizdelnick]

Официально рекомендовано было собирать пакет на чистой системе

Для этого есть pbuilder, кстати.

[dimbor]

Если по-умному, то не тем и не другим. Я правильно понял, что там сборка голым make'ом делается?

Нет, там сначала imake с цельным каталогом конфигов для всего в куче плюс Imakefile у каждого компонента.
Поскольку древность жуткая, не все возможно поправить добавлением дополнительного конфига host.def
Приходится Imakefiles патчить. Отсюда отчасти дистрибозависимость.

Всё дистрибутивоспецифичное оказывается в rules.
Upd. Или другой вариант: имя константы DefaultFontPath намекает, что она устанавливает значение по умолчанию. Если так, то значение не по умолчанию, вероятно, можно прописать в каком-то конфиге. В таком случае вместо накладывания дистрибутивоспецифичных патчей можно класть в пакет дистрибутивоспецифичный конфиг, - это весьма распространённая и оправданная практика.

Принято. Так и буду действовать, насколько позволит действительность..

Кстати, Ваш зачин темы

Имеется проект xxx, офигенной сложности и глючности.

Хочу спросить: Если его годами пилят до хоть сколько-нибудь рабочего состояния, тогда кому он нужен?
Может там изначально неверный подход к задаче? Тогда, имхо, его проще форкнуть и пойти други путём, чем полжизни пилить эту никчемность.

Скажем так, непересчитанная узкая группа отщепенцев его активно использует, по модному говоря - "в продакшене". Лично у меня так финансовое благополучие от него некоторым образом зависит.
Подход там какой надо. Настолько, что апстрим задавила жаба, и последующие версии уже не OSS.
Выше давал ссылки на два фактически форка. Оба не устраивают. Значит еще и мой будет, правда под оригинальным названием.

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

Ага, об том и речь, что у этих двух не сильно получается, и там одна эта самая кухня. А то, что у себя буду делать подобное в одельных ветках (не master), будет наверное правильнее. Речь то о курицах и яйцах, как написано в сабже. И все системы мне не нужны, только мои и корефанов. В натуре. Зачем мне 100500 систем? Правильно, незачем. Если у меня будут печеньки, сами придут. А нет, - так ой.

Во-вторых, даже если мы допустим на одну минуту, что где-то такое сделали.

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

Благодарю за инфу по сборке именно deb. Вопросов еще будет. Прервусь на изготовление православного гита. И будет конкретика.

[dimbor]

И вот что еще вычитал:

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

Минуточку! А можно с этого момента подробнее? Это куда это они все постоянно отходят? Так прям, что никого на месте нет. Если они отходят к тем двум гитам, что я упоминал, то пусть бы они уже и возвращались насовсем!

Серьезно, что за такой новый способ?

[Bizdelnick]

Способ простой - вместо патча хранить каталог debian в отдельном архиве. К обсуждаемой ситуации это никакого отношения не имеет.

[dimbor]

Продолжаю попытки сделать правильно и удобно. Может и вы мне чего умного еще подскажете. Пока занимаюсь сугубо структурой гита. Кстати вот он. Была мысля переехать на github, даже были сделаны попытки. Но там уже есть какой-то dimbor. Это ладно, но вебморда его мне не понравилась активно (гитхаба, не димбора). Как-то привычней видеть на главной не дерево файлов, а список веток и тэгов. Т.ч. пока господа филантропы из Этерсофта меня со своего гита не поперли, буду столоваться у них.

По структуре применительно к теме: Продукт, увы, дюже хитрый. Если только десятая его часть отвечает классике autoconf && configure && make. По поводу данного свыше определения быдлокода. Если старичок Xorg - быдлокод, придется с этим как-то мириться. Преимущественно - imake && makedep && make. Т.е. от исправления кучи конфигов, шаблонов и файлов Imakefile не деться никуда. И эти исправления не будут иметь ничего общего с функционалом, а будут преследовать две цели - собраться и запуститься.

Ничего не придумал лучше, чем заменить квадратно-гнездовую манеру ведения гита маргинально-кустовой.
Это означает, что в ветке master будет жить сферический конь код в вакууме. Мастер никогда не будет объединен (merge) с какой-либо другой веткой, не соберется и не запустится. Его будут посещать сугубо cherry-pick от соседей, касающиеся функционала и только его. Вся прикладная возня будет идти в кусте, растущем из ветки build_main. Под каждую ситуацию/дистрибутив (???) можно будет создать отдельную свою и не одну.

Вызывает интерес и еще такой процесс. Может, да и обязательно обнаружится какой-нить глобальный ляп, который должен был отловиться в самом начале, но не смог. И cherry-pick в пределах куста будет загромождать. Раньше просто делал на этот комит rebase. Но вот только не помню, смогу ли я опустить комит ниже точки ветвления. Предположим, смог. Но уж точно помню, что только локально. На remote push работать перестает. Приходилось переинициализировать remote с нуля. Но это прокатывает, только если я один такой красивый в этом гите сижу. А вдруг нет? Подскажите знатоки, проворачивается ли в гите обратно фарш?

ЗЫ: Одно плохо, что до сборки, собственно, пакетов пока добраться не могу. Повторяю пройденное. - И его можно пройти более лучше. Так много думаю, что головка бо-бо с непривычки.

[Bizdelnick]

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

Ну у push есть куча опций --force-blabla (и просто --force их все отнюдь не включает). Но вообще, конечно, это большая подлянка по отношению к остальным, работающим с тем же remote. rebase в нём вообще лучше не делать.
А в чём смысл использовать cherry-pick, а не merge, если в мастере будет только

сферический код в вакууме

?

[dimbor]

Но вообще, конечно, это большая подлянка по отношению к остальным, работающим с тем же remote. rebase в нём вообще лучше не делать.

Угу. Буду стараться. Раз такое дело.

А в чём смысл использовать cherry-pick, а не merge, если в мастере будет только

сферический код в вакууме

?

Так вместе с merge придут толпы "мантейнерских" комитов, и линейки-ветки только по функционалу опять не получится. Пусть будет особенностью гита неродного, но сопровождаемого продукта. Когда ловятся в нем баги, возникает вопрос, а что с кодом то делалось. И очень много времени уходит на продраться через каждый чих и пук, не относящийся к. А тут все будет на блюдечке лежать. По другому не знаю, как объяснить. Вся тема об этом. Может и правда хочу странного.

ЗЫ: А, походу наконец понял, что имелось в виду. В мастер merge нельзя, с мастером - конечно можно. Только незачем. Он вторичен. Комиты изначально делаются в рабочую ветку, а потом уж в мастер. Для наглядности.