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

Это получается, что всё это нужно каким-то образом доустанавливать ещё и в /var/lib/mock/fedora-28-x86_64/root/.

Натурально, сборочный сервер на одном из этапов сделает yum-builddep твой_спек.spec внутри mock-ового чрута. Это всё не для локалхоста, можешь расслабиться и дальше собирать rpmbuild-ом.

ABS рулил, ABS рулит, ABS будет рулить.

Починил.

Этот ваш mock зачем-то устанавливает ещё одну (!) систему (!!!) в chroot.

Это называется чистый(!) build(!!) environment(!!!). И так делают все более-менее вменяемые мейнтейнеры. Сказать-то что хотел?

copr

говорящее название поддомена, что ещё сказать

говорящее название поддомена, что ещё сказать

Ты ещё их лого не видел.

чистый(!) build(!!) environment(!!!)

Любая сборка выполняется под конкретную систему. У юзера могут отличаться версии библиотек, и тогда оно у него не взлетит. А это какая-то абстрактная сборка в ваккуме.

Любая сборка выполняется под конкретную систему.

Нет, любая сборка выполняется под конкретную версию дистрибутива.

У юзера могут отличаться версии библиотек, и тогда оно у него не взлетит. А это какая-то абстрактная сборка в ваккуме.

А это какая-то сборка под конкретную версию дистрибутива.

P.S. Слушай, а тебя папа в детстве не насиловал? Ты какой-то совсем поехавший.

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

лол, мда

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

https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.or...

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

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

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

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

ты ща про роллинг-релиз говоришь или традиционные дистры с релизами и версиями?

Это получается, что всё это нужно каким-то образом доустанавливать ещё и в /var/lib/mock/fedora-28-x86_64/root/

Что именно «это»? mock ставит все зависимости пакета, что ты еще хочешь туда притащить и зачем?

Нет уж, rpmbuild рулил, rpmbuild рулит, rpmbuild будет рулить. А mock только на любителя.

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

Во-первых, с обновлениями могут приходить другие версии библиотек.

Ты что-нибудь слышал про бинарную совместимость в пределах релиза, мм?

Во-вторых, юзер сам может собирать себе другие версии библиотек.

И mock с этим справится, если ты ему дашь путь к репозиторию с нужным -devel пакетом, в spec файле укажешь, что версия должна быть не ниже такой-то.

В-третьих, конкретная система отличается от конкретного дистрибутива набором библиотек и их *-devel пакетов.

ЛОЛШТО? Система отличается от дистрибутива? Это как? Как ты эти понятия вообще сравнил, мне интересно узнать?

Чтобы собирать под весь дистрибутив в целом нужно установить все имеющиеся в нём библиотеки и модули интерпретаторов. Но, при этом ряд соответствующих пакетов могут конфликтовать друг с другом.

Что ты, мать твою, несешь? Все опции сборки прописаны в spec файле. Если в spec файле написано, что софт должен собраться с libfoo, то наличие libbar в системе никоим образом на сборку не влияет.

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

Этот ваш mock зачем-то устанавливает ещё одну (!) систему (!!!) в chroot.

Чтобы получить чистый и воспроизводимый билд. Там ещё и доступа к сети при сборке нету (ШОК! СЕНСАЦИЯ!). Специально чтобы авторам кривых спеков бить по рукам.

А в новую систему в chroot'е никто это не устанавливал. Это получается, что всё это нужно каким-то образом доустанавливать ещё и в /var/lib/mock/fedora-28-x86_64/root/. При том, что оно уже есть в корне.

Вообще для этого положено в спеке указывать BuildRequires.

Я кажись понял. saahriktu пытается сделать из Fedora шлакварь.

конкретно федора вроде не роллинг

Slackware тоже бывает разный. Slackware-stable != Slackware-current. А вот конкретный слакварист может сам выбирать версии библиотек и при желании даже бежать впереди поезда. А может и просто юзать Slackware-stable.

Slackware тоже бывает разный. Slackware-stable != Slackware-current. А вот конкретный слакварист может сам выбирать версии библиотек и при желании даже бежать впереди поезда. А может и просто юзать Slackware-stable.

А каким боком это к Fedora относится, скажи мне пожалуйста? Там такой проблемы нет. Там есть дистрибутив, в котором версии софта жестко прибиты гвоздями в пределах релиза, чтобы не дай бог все не поломалось. И любой major bump ты делаешь с оглядкой на то, что бинарная совместимость не поломается, иначе у тебя весь остальной софт работать перестанет.

В федоре бег впереди паровоза заключается в завышении циферок в Requires: libfoo>=123 в файле .spec

Зачем мне две разных системы? И, да, системы таки разные.

Конечно они разные! Они могут даже быть не федорой, а сусей или может быть даже альтинуксом (ну это хз) или даже другой архитектурой через qemu.

Ну так в любом случае конкретный юзер Федоры может стать сам себе маинтейнером и собирать себе новые версии библиотек и софт под них. При этом через rpmbuild всё работать у него будет. А у mock'а будет своя атмосфера, где всё это может и не собираться. Впрочем, конечно, подозреваю, что и тут есть возможность создания собственного репозитория, и тогда mock будет в него заглядывать и брать из него пакеты. Но, зачем, если в основной системе это всё уже есть и так?

Затем, что воспроизводимые сборки и организованное хранение артефактов есть благо, а помойка в / (превед шлакварь) — безблагодатность.

Вы называете установку Федоры в / помойкой?

Установка Слаквари в / ничем не отличается от установки Федоры в /,

А дальше речь конкретно про опакечивание и манипуляции пакетами, а не, якобы, "./configure && make && make install".

Нет, я говорю, что помойка в шлакваре начинается с /.

А у mock'а будет своя атмосфера, где всё это может и не собираться.

== баг в SPEC-файле.

Но, зачем, если в основной системе это всё уже есть и так?

Но зачем ты забиваешь себе основную систему dev-пакетами? Чтобы обновляться подольше? Взял, подмонтировал tmpfs и /var/lib/mock и собрал все со свистом и без единого лишнего пакета в корне. Нет, мы будем вываливать окружение сборки прямо в корень, а потом еще и обвинять мок в том что он не хочет срать посреди гостиной. И эти люди будут нас учит юниксвею?

Эта фраза была когда-то кем-то сказана про "./configure && make && make install". И этот человек явно не осилил слакбилды и makepkg.

И в Федоре и в Слаке есть пакетные менеджеры и в этом смысле они одинаковы.

Так юниксвей - это большие пакеты без отдельных *-devel пакетов. И сборка прямо в единственной системе.

А это уже не юниксвей, а энтерпрайз.

Во-во. Юниксвей: сваливаем все в одну кучу и молимся РМСу чтоб ничего не сломалось. Потому что когда оно сломается, хрен ты поймешь что и где. Что-то там вроде было про отдельные инструменты для отдельных задач, не?

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

Так mock'у то в его chroot'е нужно всё почти всё тоже самое, что и в основной системе. Если сборка зависит от pidgin'а, то mock и pidgin со всеми его зависимостями притянет, а не только *-devel пакеты. Вот если бы *-devel пакеты сразу бы устанавливась для mock'а, а всё остальное он бы брал в основной системе, это ещё можно было бы понять. А зачем дублировать одно и тоже?

Очевидно что бы была бинарная совместимость?

Вот если бы *-devel пакеты сразу бы устанавливась для mock'а, а всё остальное он бы брал в основной системе, это ещё можно было бы понять.

Хм. А ведь ты не понимаешь, как работает сборка софта. Как ни странно, я этим удивлен (хотя, наверное, не должен быть).

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

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

Что значит «не понимаю»? Не останавливайтесь уже на полуслове и поясняйте где именно на Ваш взгляд я ошибся.

Понятное дело, что у chroot'а свои особенности. Но, я об этом ни разу не говорил. я ж и пишу: «если бы».

Что значит «не понимаю»?

Ровно это и значит - не понимаешь. Не понимаешь, как работает configure.

Не останавливайтесь уже на полуслове и поясняйте где именно на Ваш взгляд я ошибся.

Тебе уже пояснили, коротко и по делу (хотя и неполно, ИМХО): Какие гадость эти copr.fedorainfracloud.org и mock (комментарий). Что непонятно?

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

это блин основа, об этом на собеседованиях спрашивают

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

А если юзер просто собирает систему себе самому на один жёсткий диск? Тогда зависимости собираемых пакетов в его системе таки обязательно нужны.

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

Не 90-е уже. Для этого есть mock.

Собирать надо mock'ом.

Т.е. люди проталкивают mock во все поля как, якобы, то, что пришло на смену rpmbuild'у. Даже для тех случаев, когда юзеру не нужны ни повторяемость сборок, ни альтернативные его системе зависимости. Просто дублируем систему в chroot просто ради самого mock'а.

Юзер собранные пакетики куда девает-то?

А точно оно так и делается?

Так, а может быть и наоборот. Например, маинтейнеры Федоры, судя по всему, не знают, что тот же worker умеет собираться с libXft. В Slackware эта библиотека есть из коробки, и с ней worker сразу собирается и работает как положено с векторными в шрифтами. В Федоре worker собран без libXft и это надо напрягаться прописывать эту зависимость. В то время как в Slackware всё работает без дополнительных усилий.

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

ну это обычный трейдофф: корректность сборки требует ресурсов.

У тебя ресурсов мало, и цена некорректной сборки невысока - поэтому ты выбрал один вариант.

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

# du -csh /var/lib/mock/fedora-28-x86_64/
941M    /var/lib/mock/fedora-28-x86_64/
941M    итого
# ls /var/lib/mock/fedora-28-x86_64/root/
bin  boot  builddir  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

Да, mock на моих глазах установил туда базовую Федору и дополнительные пакеты. Чтобы потом chroot'иться туда, и там всё собирать.

Так, а может быть и наоборот

Наоборот - это когда configure не находит установленных библиотек. Это просто баг в configure.

маинтейнеры Федоры, судя по всему, не знают, что тот же worker умеет собираться с libXft.

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

если стоит задача собрать пакет для репозитория

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

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