В каком НЕ роллинг дистре легче всего собирать софт простому пользователю?

Попробуй Crux. Быстро перехочется странного.

А, "роллинг". Ну тут вариантов нет, лучше, чем в "арче", разве что в Gentoo, но там свои заморочки.

Не, я наоборот написал «не роллинг»

Арч (если не гента). Читайте про ABS. https://wiki.archlinux.org/index.php/Arch_Build_System

Не роллинг — федора / центось / рхел.

Что значит «легче всего собирать»? Оно везде плюс минус одинаковое.

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

make install

https://help.ubuntu.com/community/CheckInstall

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

деб сложно собирать, легче любой рпм

Они примерно одинаково собираются. Особой разницы нету.

А если надо ninja и ещё другие варианты?

Отваливающийся при обновах софт

Откатывай. Ну или ставь паразитирующий на арче дистрибутив.

Всё хуже, вот был момент, когда mkvtoolnix стал неправильно муксить mkv, а я не сразу заметил, несколько видео немного запорол.

Паразитирующие на Арче дистры ни чем не отличаются от самого Арча.

Паразитирующие на Арче дистры ни чем не отличаются от самого Арча.

Версии пакетов отличаются. В бамжаре могут неделями седеть пока арчеводы баги не пофиксят, а потом выкатить обнову. Пользователи потом писают кипятком в штаны (не только себе), что мол там пакеты «тестируют».

Вот там mkvtoolnix и запоролся, я отрепортил им даже, на что лаконично ответили: «Баг Арча».

Ну чтд.

Ладно, пока планирую рачевать, а как будет Дебиан 11, то на него.

В Slackware (если только вам не нужны systemd с Gnome и около него).

Да ну, почему? Это ж нечто для админов из 90-х.

Почему что?

Почему лучше для сборки, чем другое?

Да всё равно вряд ли, больно маргинальный дистр.

Наверно, стоит рассматривать между Сусей Лип и Дебианом.

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

Slackware

А попробовать сначала? Ты хоть собирать программы в Debian пробовал? Это ужасно.

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

В других дистрах тоже можно такое делать, но насколько же это сложнее...

Почему лучше для сборки, чем другое?

Со стороны дистрибутива дополнительных требований минимум.

всё равно вряд ли

Дело хозяйское.

Слаку, конечно.

Внимательно посмотри какие пакеты у тебя установлены с аура pacman -Qm. Может так оказаться, что ты только думаешь, что сильно зависишь от аура, а на самом деле у тебя оттуда установлена какая-то мелочь, как это было в моем случае. Переехал на Федору и сильного недостатка в пакетах не ощутил.

А флэтпак ты не любишь совершенно напрасно. В каком-нибудь гноме их использование не отличается от нативных приложений. Обновления, при этом, совершенно копеечные. Вот так, например, выглядят типичные обновления в флэтпаке (500Кб вместо 50Мб).

https://docs.freebsd.org/ru_RU.KOI8-R/books/handbook/ports-using.html

https://docs.freebsd.org/ru/books/handbook/pkgng-intro.html

Я остановился на Слаке и Арче, ну, void и alpine местами тоже ничего

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

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

CentOS 7 или SLES 12 SP5

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

«баги изза ролинга» - сказки протухшие уже лет 7 как. но люди упорно их продолжают пересказывать. научись готовить арч и нет проблем. если уж так не хочется поймать баг в нужном софте - мониторь багтрекер. поставь лтс ядро если надо. можешь еще arch-audit поставить и обновляться только когда много критических обновлений накопится. или можешь вообще не обновляться, а можешь раз в пол года. работает - не трогай. ну и вместо аура можно подключить сторонние репы. хотя наверняка щас скажут «НИБИЗАПАСНА!11».

а вообще есть убунта с PPA.

ну и https://repology.org/repositories/statistics

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

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

перестать сталкиваться с разными багами из-за роллинга

Манжаро, три месяца, полёт нормальный. Самый серьёзный (наверное, даже единственный) инцидент — это отвал нового ядра (кажется, 5.10) после обновления. Из GRUB запустил LTS-ядро и пересидел на нём до следующего апдейта. Уж на что я любитель штабильности, но пока оченно доволен.

ABS же в арч похоронили несколько лет назад, не? ASP вместо него.

ЕМНИП, да, но статья называется АБС, да и так привычней.

Собрать в дебиане пакет для локального использования с использованием checkinstall проще пареной репы. Собственно, тот же make install, только с .deb на выходе.

про мейк инсталл вижу, а, как выше спрашивал, если ninja или ещё чего?

Nix же!
Сам не пользую [но не осуждаю]:

• пакеты (условно) собираются сразу в ось но при этом не затирают предшественников, всегда можно посмотреть/пересобрать/откатить/сравнить
• портабельность на уровне системы а не пакета
• при переносе пакета между разными системами, когда требуются правки, не надо его перепакечивать - достаточно подправить описание перед сборкой
• пакеты можно собирать сразу с гитхаба из коробки без промежуточных действий
• ну и в целом никаких лишних действий - все лежит в фс, все цепляется через фс

Ну тогда, наверное, debhelper.
Там тоже ничего сложного, просто создать в директории с исходниками субдиректорию /debian, а в неё сложить файлы с описанием нужных для сборки параметров:

• control, где будут описаны собственно параметры пакета (версия, зависимости, зависимости для сборки и т.п.)
  
• rules, где будут описаны опции сборки, и собственно там и надо будет написать debhelper'у, что у тебя используется ninja или ещё чего
  
• changelog, в котором, как ни странно, будет чейнджлог.

Понятно, что это сложнее, чем просто собрать и распихать библиотеки по файловой системе, но ничего криминального тут нет.
Тем более что всегда можно взять и раскурочить какой-нибудь пакетик попроще через apt-get source <пакет>, залезть в папку debian и посмотреть, как эти файлы выглядят.
А если ты, допустим, собираешь тот же пакет из репозиториев, но, например, из свежих гитовских исходников, то директорию /debian можно утянуть целиком, поправить чейндждлог, убрать дебиановские патчи (если есть) и спокойно собирать неподписанный (а подпись для локального использования всё равно ни к чему) пакет через dpkg-buildpackage -us -uc

Alpine, NixOS.

конечно последняя лтс убунта

OpenSUSE там есть OBS

Тогда что-то типа

checkinstall ninja -C build install

https://asic-linux.com.mx/~izto/checkinstall/docs/README

  NOTE: If you give no arguments to checkinstall it will run a "make install".
  If you give arguments, the first non-option argument will be used as the
  install command. This is useful when the install command is not "make install"
  but something else like "make install_packages" or "setup" or whatever, i.e. 

  checkinstall make install_packages
  checkinstall make modules_install
  checkinstall install.sh
  checkinstall setup
  checkinstall rpm -i my-package-1.0.i386-1.rpm

NixOS смотрит несогласным взглядом.