Сборка дебиановский source пакетов

Так я о том и пишу. Система сборки дебиана такова, что она не гарантирует сборку на измененном состоянии системы.

Если напрячься то можно свести эту проблему к минимуму, но такой пакет не сможет быть принят в репы.

и в конце-концов, ты можешь поступать, как Dr.Web: один большой деб со всеми нужными библиотеками ставится в /opt/appname. и вот никакой дебиан и его библиотеки тебе при этом не указ.

Да, но в репах тебя не будет.

Система сборки дебиана такова, что она не гарантирует сборку на измененном состоянии системы.

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

who cares? подключи свою. главное, не конфликтуй.

Репо-фанатики набигут.

я тебя умоляю! если твоя проблема фанатики, то реальный софт в enterprise ты не пишешь.

собирать на старом дебиан

Тогда на новом баботать не будет. Например, xcb библиотека будет иметь разное имя (реальная история). И что дальше, мне прямо xcb бандлить?

У меня есть вендософт, который смотрит свой конфиг в четырех разных местах. :)

Это однозначно плохо, с этим не спорю ни разу

Мы вроде о десктопе. Я конечно не пишу никакой энтерпрайз.

Мне хочется что если мне нужно поставить в систему более новую версию либы, чем идет в дистрибутиве, я мог это сделать быстро и легко, без плясок с бубном, разбираясь, почему при запуске по make все собирается, а при запуске dpkg-buildpackage не собирает, а сконцентрироваться на своей задаче

Ты не поверишь, но «более новая версия либы» установленная так, как ты себе придумал, с большой вероятностью просто поломает тебе всю систему (привет сраным дебилам которые непрерывно высирают долбанную icu4с например).

У тебя изначально неправильный подход, но ты почему-то предъявляешь претензии не себе, а пакетному менеджеру и системе сборки. Разберись как они работают в твоём дистрибутиве, и никаких проблем не будет. Дебиан ещё тот дистрибутивчик, но вот именно с системой сборки и пакетным менеджером у него особых проблем нет. Основные проблемы у Дебиана с теми, кто для него пакеты собирает.

Кароче, тебе нужно:

1. посмотреть с какими флагами конфигурируется и собирается штатная либа в твоём дебиане и какие у неё прописаны зависимости для сборки и для установки.
2. посмотреть в чейнджлоге/ридми либы нет ли каких изменений в используемых флагах, настройках и зависимостях в новой версии либы по сравнению с той, которая у тебя стоит.
3. в library-src-new/debian прописать флаги, настройки и зависимости из п1 с учётом п2, потому что далеко не факт, что разработчики либы вообще для дебиана туда сборочное барахло запихали. Может это для бубунты какой, или вообще для дивана.
4. поменять имя твоей либы и правила установки симлинков так, чтобы пакет с новой версией твоей либы не проапгрейдил случайно штатную либу что легко может привести к неработоспособности другого софта, собранного под старую версию либы из-за несовместимостей между версиями либ. Заодно можно будет легко апгрейдить и удалять эту более новую версию.

Если либа испольуется только для одной программы, которую ты тоже самостоятельно собираешь - то п4 можно опустить.

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

просто учесть это и собрать два разных пакета.

Я так и делал. Но я не считаю это нормой.

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

я, кстати, еще люблю, когда софт статически линкуют. но почему-то этот подход не моден сейчас.

Когда-то я издевался над дебианом при помощи apt-build.

«Архив, который распаковывается в корень» это и в дебиане почти так и есть. А если точнее, то .deb это контейнер с тремя файлами:

1) номер версии формата (везде одинаковый, никаких сложностей не создаёт)

2) тот самый архив .tar.gz для распаковки в корень

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

в чем причина вообще фейла сборки пакета deb-ом? Она может быть только в одном - dpkg-buildpackage не обеспечивает повторяемость сборки.

Как говорится, когда в руках молоток, все проблемы становятся гвоздями.

Повторяемость сборки и проблемы dpkg-buildpackage почти что не связаны. Более того, при определённых условиях использование dpkg-buildpackage может сфейлиться, если ты попытаешься намеренно испортить воспроизводимость сборки. ТС, похоже, так и делает. И почему-то сильно удивляется результатам.

когда каждое приложение живет в своей отдельной директории

Тебе может понравиться GoboLinux.

хочется, чтобы пакеты собирались по кнопке «сделать хорошо».

pbuilder

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

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

Подход, применяемый в винде и макоси
Потому что в таком варианте ничего не засоряется

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

Ещё как засоряется. И это не считая того что некоторый софт лезет в директории другого софта, чтобы там нагадить (привет поделкам от мейлрушек и яндексов)

Энтерпрайз не десктоп. Народ вон лапшу на питоне в интерпрайз зашивает, особенно в машинном обучении, да ещё такую которая умудряется работать только на определённом железе по которому надо ударить бубном когда 5 луна юпитера скрыта за ним столько раз, сколько лун Юпитера видно в тот момент с Земли.

На десктопе эти проблемы намного острее. На сервере у меня сейчас debian 9

Где дебиан, и где десктоп? Модель дебиановских реп и релизов сделана для серверов, проблемы хомячков там учитывали в последнюю очередь.

Но на десктопе я не поставлю debian 9 в 2022 году

Ну и правильно. О чём тогда спор? На десктоп убунту принято ставить, там хомячьего рака полные штаны (поэтому я ССЗБ с дебианом на десктопе).

На десктоп убунту принято ставить

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

собирался бы всегда и везде и в последующем.

К сожалению, так не бывает, например, в пакете может быть флаг Werror, на старом компиляторе ворнингов не было, а на новом есть, намучался с этим, когда собирал старый yocto в новом дистрибутиве

Делаю гит-клон, собираю с помощью cmake, make - все собирается. Делаю dpkg-buildpackage - не собирается

Если вкратце, то сборка Debian-пакета и то, что ты делаешь по cmake/make/make-install, это разные вещи. Например, если будешь собирать так ffmpeg, без передачи кучи параметров скрипту configure, результат не сможет кодировать H.264 видео, даже если во время сборки нужные библиотеки были установлены в системе.

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

https://imgs.xkcd.com/comics/standards_2x.png

К сожалению, так не бывает

Бывает. Это называется - повторяемая сборка. Она предполагает что у тебя, в числе прочего, и компилятор ровно нужной версии. Это может Nix, и что поразительнее всего - это может даже Flatpak!

Где дебиан, и где десктоп? Модель дебиановских реп и релизов сделана для серверов, проблемы хомячков там учитывали в последнюю очередь.

Нет. У них на глагне написано - Debian универсальная ОС. Назвался груздем - полезай в кузов.

На десктоп убунту принято ставить

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

Более того, при определённых условиях использование dpkg-buildpackage может сфейлиться, если ты попытаешься намеренно испортить воспроизводимость сборки.

Погоди, так вот это и говорит о том, что не обеспечивается воспроизводимость сборки. Если ее можно сломать даже не осознавая этого.

Это и называется - не дает гарантий.

Погоди, так вот это и говорит о том, что не обеспечивается воспроизводимость сборки.

Такой же «логикой» можно придти к выводу о том, что Nix не обеспечивает воспроизводимость сборки. Nix обеспечивает или нет?

Похоже что я неправильно понял, что ты имеешь в виду. Поясни, в чем основные проблемы dpkg-buildpackage о которых ты упоминал и в чем конкретно по твоему мнению сабжевый фейл.

Nix обеспечивает или нет?

Обеспечивает если выполнить ряд условий. А dpkg-buildpackage обеспечивает если таскать в виде образа точную копию системы, в которой была удачная сборка. Иначе он ничего не обеспечивает, там куча способов все сломать так что он совсем не заметит подмены.

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

Да и обнаружить такую ошибку невыносимо тяжело

На момент создания пакета ещё неизвестно, где будут варнинги на следующих компиляторах, как можно предположить, что в будущем компиляция споткнется на таком-то месте?

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

Укажешь для вот этого конкретного пакета использовать вот этот конкретный компилятор - и он будет использоваться всегда. И в будущем тоже.

Поясни, в чем основные проблемы dpkg-buildpackage о которых ты упоминал

Он не может собрать программу, если она зависит от библиотеки, которую неоткуда достать. К сожалению, не умеет доставать из эфира. Nix, видимо, может.

в чем конкретно по твоему мнению сабжевый фейл

ТС забыл поставить требуемые зависимости для сборки.

Ну собственно у меня убунта

Ну, а для кого делали snap?

Обеспечивает если выполнить ряд условий.

А dpkg-buildpackage обеспечивает если таскать в виде образа точную копию системы, в которой была удачная сборка.

То есть «обеспечивает, если выполнить ряд условий». Образ, кстати, представляет собой перечисление имён пакетов и их версий, а не бинарники, если ты не в курсе.

Он не может собрать программу, если она зависит от библиотеки, которую неоткуда достать. К сожалению, не умеет доставать из эфира. Nix, видимо, может.

Может, да. Либо коммит из гита достает, либо в особо запущенных случаях, как например установка Viber - из web archive за указанную дату качает.

Если гитхаб и вебархив сдохнут - то тут уже не до Nix будет.

А вот в дебиано-мире да, снесут библиотеку из репов и неоткуда брать сборщику будет.

ТС забыл поставить требуемые зависимости для сборки.

О чем и речь. Если обеспечивается воспроизводимость сборки - нужные зависимости должны ставиться автоматически. Иначе это называется - она не обеспечивается.

Образ, кстати, представляет собой перечисление имён пакетов и их версий

А что в дебиановском репозитории происходит с пакетом когда выходит обновление?

Таким образом, проблему можно решить конечно

все что нужно было для сборки стояло. И через cmake руками собиралось

и никаких там кучи опций, как у того же ffmpeg, нет

Дело в том, что deb сборщик мог добавить ключи для configure, которые требуют дополнительных зависимостей. При ручной сборке без этих ключей, возможно, эти зависимости не требуются.

Можно все-таки больше конкретики? Интересно же.

так в самом же ОП в тегах написано. pocl. в убунте версия 1.4, а на гитхабе уже 1.8 релизнули

Я не о том. Какие конкретно ошибки выдает? Мы же не будем тут ставить дебиан и проверять сами.

Может, да. Либо коммит из гита достает, либо в особо запущенных случаях, как например установка Viber - из web archive за указанную дату качает.

Прямо без интернета, из астрала?

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

Нет, это разные вещи.

Иначе это называется - она не обеспечивается.

Кем называется? Тобой? Официальный сайт Nix заявляет: "Nix builds packages in isolation from each other. This ensures that they are reproducible and don’t have undeclared dependencies, so if a package works on one machine, it will also work on another. " Про автоматическую установку зависимостей там ничего нет.

что в дебиановском репозитории происходит с пакетом когда выходит обновление?

Он уходит в архив. Старая версия уходит в архив.