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

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

Что за софистика? На сгоревшем компьютере тоже Nix не работает. Поэтому он плохой? Что это за логика?

А как ты в дебиане без интернета будешь вообще что-то собирать? Все сорц пакеты на DVD нарезаешь и носишь в чемодане?

Nix builds packages in isolation

Ты просто невнимательно читаешь. Вот это - означает что он сам все ставит. Иначе ты никак in isolation ничего не соберешь. Сначала надо поставить все зависимости во внутрь этой isolation. Что Nix автоматически и делает.

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

Ну, а что тогда имелось в виду под «которую неоткуда достать»? Все же в архиве есть.

Что за софистика?

А, гнуть слова только тебе можно? Я не знал.

А как ты в дебиане без интернета будешь вообще что-то собирать? Все сорц пакеты на DVD нарезаешь и носишь в чемодане?

У меня есть локальное зеркало. Периодически обновляю.

Ты просто невнимательно читаешь. Вот это - означает что он сам все ставит.

Нет, не означает. Это твои домыслы.

Сначала надо поставить все зависимости во внутрь этой isolation. Что Nix автоматически и делает.

Зависимости можно поставить руками. Или если ставить руками, Nix внезапно теряет воспроизводимость? Если не теряет, то почему воспроизводимость в твоём понимании требует автоматической установки?

У меня есть локальное зеркало

Так можно чего угодно зеркало создать.

Зависимости можно поставить руками

Ты просто подменяешь понятия. Дело не в том, что можно поставить руками. А в том, можно ли поставить автоматически. Nix гарантированно ставит автоматически все что еще не стоит. Этим он и обеспечивает повторяемость. Руки тут вообще не причем.

Ну, а что тогда имелось в виду под «которую неоткуда достать»?

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

потому что для установки зависимостей уже есть другие утилиты

Вот именно - их две. Левая и правая. Вот в этом и беда.

Nix гарантированно ставит автоматически все что еще не стоит.

Проблема с твоей риторикой состоит в нарушении некоторых подразумеваемых правил общения. Когда ты сравнивая Nix с чем-то другим заявляешь, что Nix делает что-то гарантированно, ты подразумеваешь, что Nix даёт какие-то гарантии, которые не может дать сравниваемый объект. В данном случае — комбинация пользователя и комплекса программ dpkg-dev. Это подразумеваемое утверждение — ложное, потому что если Nix может что-то сделать, это может сделать и человек.

Руки тут вообще не причем.

Руки тут являются примером ортогональности аспектов. Повторяемость не связана с автоматической установкой зависимостей.

Это подразумеваемое утверждение — ложное, потому что если Nix может что-то сделать, это может сделать и человек.

Блин, ну да нет же. Причем тут человек. Мы говорили про то что сборщик пакетов обеспечивает либо не обеспечивает повторяемость. Человек не является компонентом сборщика пакетов, я вообще в шоке и не знаю как ты вот такое придумываешь. Причем тут какие-то комбинации с человеком?

Nix делает что-то гарантированно

Возвращаясь к Nix. Строго говоря, при сборке через Nix ты не можешь вручную поставить пакеты in isolation. Это делается только автоматически.

Вот именно - их две. Левая и правая. Вот в этом и беда.

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

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

Не я считаю, а так и есть. -dev пакеты нужно вагонами наяривать вручную.

Причем тут человек.

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

Возвращаясь к Nix

Да-да, ТС возьмёт Nix, и у него внезапно появится нужный пакет. Видимо, так всё произойдёт?

Не я считаю, а так и есть.

Спасибо, насмешил.

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

Я утверждал обратное? Вот это новости.

Я тебе пишу что это является необходимым условием для «сборщик обеспечивает повторяемость». А не Папа Римский, человек или Зевс.

Да-да, ТС возьмёт Nix, и у него внезапно появится нужный пакет

Я где-то такое утверждал? Ты сегодня какой-то странный. Я ни разу не писал что конкретную сабжевую проблему прямо сейчас решает Nix.

В schroot пакеты собираются и никакого «засорения» системы не нужно. Если открыть launchpad.net то в логе сборки любого пакета можно увидеть как там все это на CI поднимается, тоже самое можно настроить на своей машине как в debian так и в ubuntu.

Собирал mesa и ядро в schroot несколько лет назад, в заметках неразбериха. Есть такие линки:
https://wiki.ubuntu.com/SimpleSbuild
https://wiki.debian.org/Schroot

потому что нифига не было оттестировано. сборка ломалась, зависимости не собирались и т.д.

Так и запишем crypt - неосилил один из самых простых дистрибутивов.

Подход, применяемый в винде и макоси, когда каждое приложение живет в своей отдельной директории, а не раскидано по куче директорий (bin/, lib/, share/) куда адекватнее.

И тем не менее и в винде и в макоси хватает приложух размазанных по директориям.

все что нужно было для сборки стояло.

Там в репозитории нет своей версии директории debian/, как это бывает в некоторых проектах. Каждый пытающийся тебе помочь должен сам догадаться, откуда ты взял debian/ или что ты там насоздавал?

и никаких там кучи опций

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

• -DWITH_LLVM_CONFIG=<path-to-llvm-config>
• -DSINGLE_LLVM_LIB
• -DSTATIC_LLVM
• -DENABLE_ICD
• -DENABLE_FP64
• -DPOCL_INSTALL_<something>_DIR
• -DLLC_HOST_CPU=<something>
• -DKERNELLIB_HOST_CPU_VARIANTS
• -DLLC_TRIPLE=<something>
• -DENABLE_TESTSUITES
• -DENABLE_TESTS=ON/OFF
• -DENABLE_EXAMPLES=ON/OFF
• -DENABLE_POCLCC=ON/OFF
• -DENABLE_CONFORMANCE=ON/OFF
• -DENABLE_{A,L,T,UB}SAN
• -DENABLE_{CUDA,TCE,HSA}=ON/OFF
• -DPOCL_DEBUG_MESSAGES=ON
• -DEXAMPLES_USE_GIT_MASTER=ON
• -DENABLE_POCL_FLOAT_CONVERSION=ON/OFF
• -DINTEL_SDE_AVX512=<PATH>

Я утверждал обратное? Вот это новости.

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

Я где-то такое утверждал? Ты сегодня какой-то странный. Я ни разу не писал что конкретную сабжевую проблему прямо сейчас решает Nix.

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

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

Ага, давайте всё слинкуем статиком и забьем Мике баки перегоним офтопик по обьему.

Так и запишем crypt - неосилил один из самых простых дистрибутивов.

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

Ага, давайте всё слинкуем статиком и перегоним офтопик по обьему.

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

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

Что-то выходит, что это лично твое мнение. А мнение Торвальдса вот оно

Shared libraries are not a good thing in general.

Pretty much the only case shared libraries really make sense is for
truly standardized system libraries that are everywhere, and are part
of the base distro.

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

по моему мнению тоже. мы с тобой и ТС говорили про сторонний софт. это anc, пришел и без разбора просто возмутился на слово «статический». мне нужно было ему с начала весь тред объяснить? или тебе сейчас?

выходит, что это лично твое мнение. Это совсем не то что ты пытаешься, скажем грубо, «втереть» нам

да ладно! чего стесняться! действительно пытался «втереть»

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

мне нужно было добавить «имхо», «лично я» и «я, конечно, дико извиняюсь»?

К твоему высказыванию я претензий никаких не имею, просто у меня впечатление что ты приписал Торвальдсу не совсем то что он говорил. Все же «статическая линковка не актуальна» это вообще радикальное высказывание.

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

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

к моменту, когда появился тот email, я задавал себе вопрос «почему так не делают» уже не один год и, ес-но, был обсмеян не раз на форуме, как сейчас это сделал anc. но дело в том, что мне как-то удалось запустить Opera6 (это где-то 2005 год) на линуксе 201х годов, просто скачав rpm.«так не делают». меня поразило, что Linus так просто и прямо это написал, а я, оказался, не не понимаю банальных вещей.

Все ненавидят почему-то оверхед от дополнительно занимаемого места. За это же и флатпак долбят (я не утверждаю сейчас что надо всем кидаться на флатпак, просто как пример что есть разные подходы). А получается так, что этой ценой достигается решение многих проблем с совместимостью. Так действительно, что лучше? Чтобы все работало или чтобы занимало минимум места и было сломано.

Но если рассуждать о истоках «динамической религии», то тут именно дебиан играет далеко не последнюю роль. Ведь он продвигает идею обновления зависимости без обновления самого приложения. Я так понимаю - для минимизации объема обновления, плюс для того, чтобы сторонние приложения (не из репов) тоже получали обновления безопасности своих зависимостей, даже если сами не обновляются.

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

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

А теперь некоторый fun факт на эту тему. Вот возьмем Nix. Технически, там все линкуется динамически. Но фактически - все библиотеки линкуются через прописывание жесткого пути, содержащего уникальный для пакета хеш, в rpath бинарника. То есть вообще невозможно обновить библиотеку не обновляя приложение, от нее зависящее. Фактически - это статическая линковка.

То есть имеем практически целый дистрибутив на идеях статики (хотя чисто технически там и .so). Это дает, кстати, возможность очень легко вытянуть все дерево зависимостей для любого пакета в бандл и потом так запускать на любом другом дистрибутиве.

Еще бонусы. Как и с настоящей статикой, исчезают конфликты между приложениями. В старой системе может быть установлено приложение с новым деревом зависимостей, не влияя на остальную систему. И наоборот. Вручную это везде можно, но в Nix это можно штатно на уровне пакетного менеджера.

apt-src /thread

По любому там каких-то build-dependencies не хватало. Не факт, что без них нельзя — но тогда их надо как-то корректно отключить, возможно, поправив исходники (и описав это в debian/changelog). Это гораздо надёжнее, чем впоследствии падать с runtime error.