Какие гадость эти copr.fedorainfracloud.org и mock

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

Откуда mock может знать что твой libfoo-1.2.3.so это тот же, что лежит в репозитории Fedora 28?

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

При чём тут «глупее»? Люди просто тестируют на своих локалях. А кракозябры и прочие баги иной раз вылазят именно при русскоязычных локалях и локализациях.

Да.

Какой-то странный вопрос. mock просто делает то, что ему сказано делать.

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

Да. Например, на грязной машине установлена через configure && make библиотека, собран пакет, библиотека прибита. В зависимости от варианта сборки, пакет будет устанавливаться и не работать (или сломается, если был установлен).

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

При чём тут «глупее»?

Глупее или знают меньше. Вот при этом:

saahriktu> маинтейнеры Федоры, судя по всему, не знают, что

А вот если в chroot mock'а разворачивается точно такая же система как и основная? Зачем дублировать то, что и так уже есть в основной системе?

Я тебе на вот это написал. Смогёшь ответить?

Ну так всё знать и невозможно. Софта тонны. А worker не такой уж и популярный файловый менеджер. Вряд-ли кто-то в нём долго разбирался. Собрался и работает - чего ещё-то? А собрать его можно по-разному.

Вряд-ли кто-то в нём долго разбирался.

Ну ты-то разобрался - значит, и другие могли.

Я уже ответил. В /etc/mock/ прописано из каких репозиториев брать пакеты. mock просто берёт пакеты из тех источников, которые там указаны. И ему фиолетово чему они соответствуют или несоответствуют.

Нет, ты чего! Эти дураки mock'ом пакеты собирают, куда им...

Ты свой текст, который я выделил, прочитал? Прочти, а потом посмотри что я тебя спросил и попробуй ответить.

Я разобрался только потому, что собирал его в Slackware. А когда я увидел, что сборка в Slackware отличается, то взял бинарник из Slackware и начал сравнивать через ldd. И обнаружил отличие в библиотеке libXft. Явно эта библиотека через ./configure worker'а, кстати, не задаётся - только подхватывается автоматически если она есть в системе.

И что? Я ж призывал задуматься над конкретной ситуацией, когда mock разворачивает в chroot точно такую же систему как и основная.

Ещё раз: как мок узнает что либфу в основной системе это либфу а не другой файл с таким же именем?

Что значит «узнает»? У него нет таких задач.

А если Вы намекаете на воспроизводимость и надёжность сборки, то об этом уже было выше. Это всё можно понять, но не всем и не всегда они нужны.

Было бы круто решить это оверлеями из докера. Типа запускаешь федорку отдельно, а она 99% системы шарит из базового образа и стартует мгновенно. Только она не запустится по понятной причине ((

а есть что-нибудь типа докера, но не докер, где оно таки запустится?

Ясно, ты не отвечаешь на вопрос, но с умным видом что-то пытаешься доказать. Просто ответь, для себя, «как» и после этого возможно поймёшь для чего он формирует себе чистое рабочее место.

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

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

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

для чего он формирует себе чистое рабочее место

Но, повторяю, эти самые воспроизводимость и надёжность сборки нужны не всем и не всегда.

Но что делать, когда она не нужна.

Когда не нужен Docker? Тогда можно использовать unshare, mount, да хоть nspawn.

продолжали есть кактус.

Если эти фичи не нужны, то зачем пользоваться, мучать себя и других?

Здесь, по сути, важнее не «как?», а «для чего?».

Как раз «как», потому что «для чего» и дураку ясно – чтоб собрать пакет нормальный. Но тыж не дурак и так сам знаешь, что лучше мантейнеров Фёдоры фм'ы собираешь.

Но, повторяю, эти самые воспроизводимость и надёжность сборки нужны не всем и не всегда.

Тебе не нужны, так тогда это не твой инструмент. Твой это мейк инсталл.

Поставил и забыл? А если хард сдох — все сначала?

Как раз «как»

mock запускает сборочный процесс в chroot'е в рамках которого бинарники линкуются ld из этого chroot'а с библиотеками из этого chroot'а. При чём здесь библиотеки вне chroot'а и разница между ними и библиотеками в chroot'е?

Обо всём этом можно только теоретически рассуждать в русле «а вот если бы». А вот если бы mock собирал не в chroot'е, а используя компоненты основной системы. Тогда /var не жирел бы, но и такой надёжности и воспроизводимости сборки не было бы, да. А это вопрос именно «для чего?».

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

Не знаю, я вот как белый человек бекаплю только /home. Все конфиги у меня в ansible, а пакеты можно поставить заново. Потому что список пакетов есть в том же ansible.

Дык, это же для того, чтобы не устанавливать в основную систему ненужные завсимости, ну и вообще, чтобы состояние твоей системы не имело влияния на сборку пакета, я вот вообще в docker-контейнере собираю пакеты для Launchpad'а, при том, что основная система у меня Gentoo или NixOS.

Переживает, что на сборку тратиться лишнее место. Бекапит пакеты и всю систему. /0

Я тоже пытался юзать этот мок вместе с копром,но это какой-то ужас и вверх неудобства после obs, так что для себя obs и живем, osc cli просто у удобен. Воркеры обс у нас тоже федоры, и они чрутят билдтрут у нас вместо запуска виртуалок. На в чрут ставится тоже много лишнего из настроек проекта, федора например ожидает что в системе будет gcc-c++, его не нужно указавать в спеках явно, но в итоге имеем что бы собрать любой пакет оно ставит минимум 240 пакетов в чрут независмо от зависимостей сборки.

по-моему все бинарные дистры так работают

даже бинарные роллинги так работают

Его можно понять.

Почему это «/0»? Бэкаплю-то я на DVD (пожав в .tar.xz). А бэкапить на тот же самый жёсткий диск, для устранения проблем с которым и нужны будут бэкапы, нет смысла.

А если Вы намекаете на воспроизводимость и надёжность сборки, то об этом уже было выше. Это всё можно понять, но не всем и не всегда они нужны.

Ну да, не всем. Если собираешь для себя, то и собирай рпмбилдом, ставь -devel ручками, чисти BUILDROOT. Только когда захочешь поделиться рпмкой или спекфайлом - проверь сперва в моке.

Почему это «/0»? Бэкаплю-то я на DVD (пожав в .tar.xz).

Каждую неделю? P____P

А бэкапить на тот же самый жёсткий диск, для устранения проблем с которым и нужны будут бэкапы, нет смысла.

Ходят легенды, что жестких дисков может быть больше одного -___-

Зачем каждую? После значительных изменений системы.

Делиться надо сборочными скриптами и .src.rpm файлами.

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

Зачем придумывать? У меня так было пару раз. Собирал пакеты в системе и ставил туда же. Часть зависимостей оказывалась не указанной. Как то почистив «ненужные пакеты» часть саомсборных программ отказывалась запускаться.

Зачем каждую? После значительных изменений системы.

LOL. Зачем бекапить систему? Нужно бекапить пользовательские данные. Система и так развернется из конфигов. Ну, только если у тебя не шлакварь :D

Устанавливает себе, конечно. Опционально может и делиться ими с другими людьми, но тут уже на страх и риск. Делиться надо сборочными скриптами и .src.rpm файлами.

Нет, лол. Это же бинарный дистрибутив.

И что, что бинарный? Собирать пакеты можно и в бинарных дистрибутивах.

Зачем бекапить систему?

Система не сводится к сумме файлов из пакетов в репозитории. Это ещё и пользовательские настройки по всей файловой системе.

А так и Slackware умеет быстро разворачиваться и доустанавливать конкретные наборы пакетов. Но, независимо от дистрибутива, новую систему нужно будет ещё настраивать.

А тут просто развернул тарбол - и всё уже установленное и настроенное.

Я приеду в Старый Оскол и подожгу твой дом.

Неужели так сильно заполыхало?

Неужели так сильно заполыхало?

Нет, я еще не доехал.

Система не сводится к сумме файлов из пакетов в репозитории. Это ещё и пользовательские настройки по всей файловой системе.

Нет, только в /etc и /home, лол. Их и надо бекапить.

воспроизводимость и надёжность сборки нужны не всем и не всегда.

Тогда зачем ты создал этот тред? Пользуйся дальше своим rpmbuild и клепай пакетики для себя.

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

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

Система не сводится к сумме файлов из пакетов в репозитории. Это ещё и пользовательские настройки по всей файловой системе.

по всей файловой системе

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