Стабильный дистрибутив со свежими стабильными версиями ПО

В венде ты получаешь не самый свежий софт, если судить опенсорсными мерками. То, что самое свежее в линуксах при закрытой разработке ещё находится в отделе тестирования компании-разработчика. Тебе достаётся версия закрытой программы примерно соответствующая версии софта из debian testing. Таким образом by design в линуксах ты можешь выбрать любую сборку нужной программы, а в вендах только «устаревшую», если говорить твоими терминами.

потому что зоопарк

а зоопарк потому что by design

У разработчика дистра есть unstable/testing/~arch/current/etc-ветка с ордой пользователей, проверяющих работоспособность софта на 100500 конфигураций машин.

а в вендах только «устаревшую», если говорить твоими терминами.

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

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

Такое могут себе позволить разве, что крупные компании, Intel, AMD, NVIDIA.

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

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

Зачем расщеплять тестеров по 100500 дистрибутивам ?

Перестаньте путать библитеки (детали) и прикладной софт (законченное изделие)

Запусти мне законченное изделие без деталей.

Прикладной софт нет.

Правда, что ли? growisofs - это часть или целое? Или не прикладной софт?

Аргументируйте

Программный продукт - это некий набор из приложений, библиотек и данных. Есть три способа доставить его потребителю - 1) каждый продукт включает в себя почти все компоненты (так одно время игрушки распространялись, каждая со своей осью), 2) есть один стандартный большой набор компонентов (винда, которая к 7 версии до 16 гиг разрослась), недостающее каждый программный продукт опять же с собой нёс и 3) каждый компонент присутствует 1 раз. Минусы 1 и 2 в избыточности и сложности обновления, минусы 3 в том, что в условиях, когда компонентов 100500, и у всех разные авторы, неизбежно появление конфликтов между компонентами, что приводит к концепции, ВНИМАНИЕ, ЛИТАВРЫ: ТА-ДАМ: ДИСТРИБУТИВА. Я кончил и закурил.

Дебиану

Ну а Дебиан сливает MacOS по качеству и комьюнити.

//Смешной

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

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

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

Такое могут себе позволить разве, что крупные компании, Intel, AMD, NVIDIA.

А почему ? Да потому что дизайн такой.

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

Если софт зависит только от glibc>=2.12 то ему должно быть глубоко пофигу сколько систем отвечают этим требованиям, одна или тысяча. Ровно до тех пор пока создатели дистрибутива решать не изголиться и подсунуть софту eglibc вместо glibc - но это уже их проблема.

неизбежно появление конфликтов между компонентами

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

Поэтому разработчики дистрибутива не должны подменять собою разработчиков софта.

К.О. намекает на то, что именно так оно в природе и есть.

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

Потому что именно разработчики дистрибутива реализуют свое видение того что значат понятия: „стабильно“, „удобно“ и т.д. и т.п. а принимать их точку зрения или нет решать пользователям их дистрибутива.

Зачем оно так ? Потому что только так истинно верно или таки просто by design ?

Затем, что

Дистрибути́в (англ. distribute — распространять) — это форма распространения программного обеспечения.

как правило дистрибутив linux содержит свой пакетный менеджер (и да даже LFS не отменяет пакетный менеджер )

Система управления пакетами — набор программного обеспечения, позволяющего управлять процессом установки, удаления, настройки и обновления различных компонентов программного обеспечения.

в то время как программное обеспечение от разработчиков как правило распространяется в виде так называемого исходного кода. Который увы но мало интересен пользователям дистрибутивов linux основанных на rpm и deb поскольку у них для того чтобы все работало все динамически компонуемые программы/библиотеки в дистрибутиве должны быть собраны одним и тем же toolchain-ом. И лишь уже потом упакованы в формат их пакетного менеджера, оттестированы и доставлены пользователям их дистрибутива.

В то врем как в: lfs, slackware, gentoo, arch и прочих source-based linux дистрибутах все абсолютно иначе и это обусловлено тем, что они source-based дистрибутивы.

Гораздо логичнее и продуктивнее было…

Вас никто не держит. Вперед и успехов вам.

С открытым софтом и в линухе нет проблем поставить последние версии при наличии желания. Например, у меня в дебиане последний хром из реп гугла. И чтобы воплотить это желание в жизнь, я добавил ровно один файл в /etc/apt/sources.list.d/ и выполнил две команды: apt-get update && apt-get install google-chrome.

К.О. намекает на то, что именно так оно в природе и есть.

Так почему софт береться из репозитария дистра, а не от разрабочика софта ?

Затем, что

Форма распространения ? отлично. На сайте разработчика софта уже лежит дистрибутив. И он его распространяет.

Большинство пользователей не могут составить грамотный багрепорт разработчику софта. Они пишут репорты в багзилу дистра, мантейнер, как более квалифицированный специалист или исправляет ошибку сам, если она связана с особенностями сборки или конфигурации, или составляет технически верный репорт разработчику. Таким образом непосредственно на разработчика идёт куда меньше нагрузки. Так что не вижу никакого расщепления.

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

Так почему софт береться из репозитария дистра, а не от разрабочика софта ?

Потому что разработчик софта отдает не опакеченные и готовые к применению во всех дистрибутивах программы а исходные коды.

Форма распространения ? отлично. На сайте разработчика софта уже лежит дистрибутив в форме исходных кодов. И он его распространяет.

fxd

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

Вы почитайте хотя бы файл README в директории с исходными кодами любой программы, там всё это и так указано.

и гарантирует что на этом окружении его софт работает.

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

В общем он в любом случае укажем как минимум те версии зависимостей, которые установлены в его системе (дистрибутиве), если он, конечно не установил их из вне.

А почему ? Да потому что дизайн такой.

Потому, что мощности у INTEL, AMD и NVIDIA и разработчика программы разные. У компаний есть большой штат программистов (разработчиков их продукта) и тестировщиков, плюс парк оборудования, на котором всё это можно протестировать.

Если софт зависит только от glibc>=2.12 то ему должно быть глубоко пофигу сколько систем отвечают этим требованиям, одна или тысяча.

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

Ровно до тех пор пока создатели дистрибутива решать не изголиться и подсунуть софту eglibc вместо glibc - но это уже их проблема.

eglibc полностью совместима с glibc, если софт разработчика по какой-то причине не «хочет» работать с eglibc значит разработчик «криво» его написал. С другой стороны разработчик дистрибутива, в котором вместо glibc используется eglibc и заинтересованный в работе программы, которая с eglibc, к примеру не собирается, может сам внести правки в код.

С открытым софтом и в линухе нет проблем поставить последние версии при наличии желания.

Везет вам. Я вот до сих пор не знаю как точно и достоверно поставить php 5.5. Обычно советчики начинают с подключения testing и unstable реп - что потенциально тут же начинает угрожать стабильности базовой системы.

Например, у меня в дебиане последний хром из реп гугла.

Это который недавно обрубил все дистры GTK+ младше 2.24. ? Но при этом оставил поддержку Windows XP ?

Отличный пример !

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

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

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

Если он заинтересован что бы программ Z работала под eglibc в его дистрибутиве Y, то почему бы ему сразу не внести изменения в upstream Z, не дожидаясь пока объявит о выходе стабильной ветки.

Потому что разработчик софта отдает не опакеченные и готовые к применению во всех дистрибутивах программы а исходные коды.

Что мешает ему отдавать и то и другое ? LSB есть ? есть !

fxd

Смотри выше.

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

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

Если он заинтересован что бы программ Z работала под eglibc в его дистрибутиве Y, то почему бы ему сразу не внести изменения в upstream Z

А с чего вы решили что так и не делается ?

Если он заинтересован что бы программ Z работала под eglibc в его дистрибутиве Y, то почему бы ему сразу не внести изменения в upstream Z, не дожидаясь пока объявит о выходе стабильной ветки.

Ага вот только во первых нигде нет никаких гарантий что циклы разработки этого „дистрибутива Y“ и eglibc совпадают и новый/исправленный eglibc успеет попасть в „дистрибутив Y“ до его релиза. В во вторых „дистрибутив Y“ вполне может вносить такие правки которые по мнению разработчиков eglibc не будут иметь никакого смысла.

Что мешает ему отдавать и то и другое ? LSB есть ? есть !

Лень или нежелание заниматься никому не нужной ерундой.

Смотри выше.

Аналогично.

Что мешает ему отдавать и то и другое ? LSB есть ? есть !

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

На всё это есть разработчики дистрибутива. Задача разработчика программы написать рабочую программу, отладить ошибки, проверить работу программы с указанными зависимостями и написать сборочный сценарий для программы, что бы её можно было собрать командой 'make' или аналогичной всё.

Так было и так будет. В этом суть распределённой разработки.

А с чего вы решили что так и не делается ?

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

Неизбежное появление конфликтов это не естественный процесс

Да ну? У разных авторов не может быть разного мнения?

результат хренового дизайна

Ты идиот? При чём здесь дизайн?

с забитым, вместо совместимости, болтом

Как раз совместимостью дистрибутивы и занимаются.

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

То, что это работа, как минимум установить дистрибутив, разобраться в формате пакетов,

Эм ... формат пакетов определен LSB - это rpm

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

Хм... то есть подписывать ключом megasoft.msi легко, а megasoft.rpm уже шибко думать нужно ?

В этом суть распределённой разработки.

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

Как раз совместимостью дистрибутивы и занимаются.

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

Разработчики дистрибутивов занимаются теми вопросами совместимости которые сами же и создали. То есть чинят то что сломали. Да и сломали скорее всего потому что решили что умнее разработчика софта.

Да ну? У разных авторов не может быть разного мнения?

Если авторы не уладив своих разногласия выпускаю софт и называют его стабильным - это хреновые авторы.

Я вот до сих пор не знаю как точно и достоверно поставить php 5.5.

Как это сделать в винде?

Обычно советчики начинают с подключения testing и unstable реп - что потенциально тут же начинает угрожать стабильности базовой системы.

При правильно настроенных приоритетах, не угрожает? Или ты не знаешь, как пользоваться apt?

└─> apt-get -s -t=jessie install php5
Чтение списков пакетов… Готово
Построение дерева зависимостей       
Чтение информации о состоянии… Готово
Будут установлены следующие дополнительные пакеты:
  apache2 apache2-bin apache2-data libapache2-mod-php5 libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap libc6 liblua5.1-0 libxml2 locales php5-common
Предлагаемые пакеты:
  apache2-doc apache2-suexec-pristine apache2-suexec-custom php-pear glibc-doc php5-user-cache
Рекомендуемые пакеты:
  ssl-cert php5-cli xml-core php5-json
Пакеты, которые будут УДАЛЕНЫ:
  apache2-mpm-prefork apache2-utils apache2.2-bin apache2.2-common
НОВЫЕ пакеты, которые будут установлены:
  apache2-bin apache2-data liblua5.1-0 php5
Пакеты, которые будут обновлены:
  apache2 libapache2-mod-php5 libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap libc6 libxml2 locales php5-common
обновлено 9, установлено 4 новых пакетов, для удаления отмечено 4 пакетов, и 228 пакетов не обновлено.
Inst locales [2.13-38] (2.17-92 Debian:testing [all]) []
Inst libc6 [2.13-38] (2.17-92+b1 Debian:testing [amd64])
Conf libc6 (2.17-92+b1 Debian:testing [amd64])
Inst libxml2 [2.8.0+dfsg1-7+nmu1] (2.9.1+dfsg1-3 Debian:testing [amd64])
Inst libapache2-mod-php5 [5.4.4-14+deb7u4] (5.5.3+dfsg-1 Debian:testing [amd64]) []
Remv apache2.2-common [2.2.22-13] [apache2-mpm-prefork:amd64 apache2:amd64 ]
Inst apache2 [2.2.22-13] (2.4.6-3 Debian:testing [amd64]) [apache2-mpm-prefork:amd64 ]
Remv apache2-mpm-prefork [2.2.22-13] []
Inst apache2-data (2.4.6-3 Debian:testing [all]) []
Remv apache2.2-bin [2.2.22-13] []
Inst libaprutil1-ldap [1.4.1-3] (1.5.2-1 Debian:testing [amd64]) []
Inst libaprutil1-dbd-sqlite3 [1.4.1-3] (1.5.2-1 Debian:testing [amd64]) []
Inst libaprutil1 [1.4.1-3] (1.5.2-1 Debian:testing [amd64]) []
Inst liblua5.1-0 (5.1.5-5 Debian:testing [amd64]) []
Inst apache2-bin (2.4.6-3 Debian:testing [amd64]) []
Inst php5-common [5.4.4-14+deb7u4] (5.5.3+dfsg-1 Debian:testing [amd64])
Remv apache2-utils [2.2.22-13]
Inst php5 (5.5.3+dfsg-1 Debian:testing [all])
Conf locales (2.17-92 Debian:testing [all])
Conf libxml2 (2.9.1+dfsg1-3 Debian:testing [amd64])
Conf libaprutil1 (1.5.2-1 Debian:testing [amd64])
Conf libaprutil1-dbd-sqlite3 (1.5.2-1 Debian:testing [amd64])
Conf libaprutil1-ldap (1.5.2-1 Debian:testing [amd64])
Conf liblua5.1-0 (5.1.5-5 Debian:testing [amd64])
Conf apache2-bin (2.4.6-3 Debian:testing [amd64])
Conf apache2-data (2.4.6-3 Debian:testing [all])
Conf apache2 (2.4.6-3 Debian:testing [amd64])
Conf php5-common (5.5.3+dfsg-1 Debian:testing [amd64])
Conf libapache2-mod-php5 (5.5.3+dfsg-1 Debian:testing [amd64])
Conf php5 (5.5.3+dfsg-1 Debian:testing [all])

Но при этом оставил поддержку Windows XP ?

Но при этом в этой XP не поддерживаются 64-битные версии Firefox. Косяки есть везде.

При чём здесь дизайн?

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

Что-то ты вообще бред какой-то несёшь.

apt-get update & apt-get upgrade -V //fixed - чтобы посмотреть что нового пришло :)

ага! спасибо. Забрал себе в поминальник :-)

Эм ... формат пакетов определен LSB - это rpm

А что rpm, собранный для, скажем fedora 19 прекрасно подойдёт для opensuse 12.4 или другого дистрибутива ? А потом, если в дистрибутивах произошли изменения нужно пересобрать пакеты, как же без этого и обязательно для всех поддерживаемых дистрибутивом архитектур, а для этого нужно разработчику озаботиться наличием соответствующего железа, ну либо мощного сервера, на котором он сможет эмулировать нужные ему архитектуры.

Это всё не говоря о том, что формат пактов не один, есть ещё к примеру deb.

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

Хм... то есть подписывать ключом megasoft.msi легко, а megasoft.rpm уже шибко думать нужно ?

У разработчика должен быть свой ключ, в таком случае.

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

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

Роль разработчика программы разрабатывать свою программу, а не лепить пакеты или делать что-то ещё.дистрибутива.

Да, ответьте какова цель ваших высказываний ?

Тебе никто ничего не навязывает. Тебе предлагают облегчить себе жизнь и ставить софт централизовано, а не искать его по интернетам и качать вручную. Не нравится? Ищи, качай и ставь/собирай. Запрещает кто-то что ли?

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

А никто пользователям дистров не запрещает качать tar.bz2 у разработчика софта из него делать rpm/deb/whatever и затем спокойно это использовать. Вот только им почему то проще тупо дождаться когда за них это сделают в их дистрибутиве.

Как это сделать в винде?

Идете на сайт разработчика, скачиваете официальный архив, ставите

При правильно настроенных приоритетах, не угрожает?

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

Или ты не знаешь, как пользоваться apt?

Мне не улыбается на каждый чих выполнять работу мантейнеров. А работа это их потому что design такой.

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

Ну вот я жду php 5.5 ... долго жду. Я понимаю, мне никто не должен, нужно собирай самому. Ибо design такой вот.

Роль разработчика программы разрабатывать свою программу, а не лепить пакеты или делать что-то ещё.дистрибутива.

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

Да, ответьте какова цель ваших высказываний ?

Мне интересен вопрос ТС, и я бы не отказался от дистра отвечающего его запросам.

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

Идём на сайт программы А, она зависит от libX 1.2, идём на сайт программы B, она зависит от libX 1.3, идём на сайт libX, там лежит 1.4, все libX не совместимы между собой. Спрашиваем у автора А чтозабайда, а он «а у меня новее 1.2 на макоси не собирается», спрашиваем у автора B, а он в ответ «1.2 - протухшее говно мамонта, где нет superfeature, а 1.4 чего-то дохера много жрёт», идём к автору libX, а он такой «а у меня i9 стоядерный, проблемы нищебродов и ахтунгов меня не колышат». Where your God now?

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

А зачем ему клепать пакеты для всех дистрибутивов ? Потому что они разные. А почему они разные ? Да потому что design дистрибутивов такой. А почему design дистрибутивов такой ? ...

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

Так со свежими, или стабильными?

все libX не совместимы между собой.

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

Спрашиваем у автора А чтозабайда

И он отвечает design такой у библиотеки такой. Извиняйте.

Идете на сайт разработчика, скачиваете официальный архив, ставите

И так для каждой программы? Да ну тебя в лес с таким геммороем.

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

Приоритеты настраиваются один раз для всех случаев.

Потому что design репозитариев позволяет парой движений превратит хост в труху ?

Какую труху? Я тебе выше показал, как поставить php5 просто и легко.

Мне не улыбается на каждый чих выполнять работу мантейнеров. А работа это их потому что design такой.

Работа мантейнера собрать пакет, настроить его взаимодействие с остальным софтом в репах и предоставить тебе инструмент для работы с этими репами. Инструмент есть, пользоваться ты им не умеешь, кто в этом виноват?

Мне интересен вопрос ТС, и я бы не отказался от дистра отвечающего его запросам.

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

Ну вот я жду php 5.5 ... долго жду.

Жди дальше, а я ставлю и использую.

И так для каждой программы? Да ну тебя в лес с таким геммороем.

Кто мешает прописать репозитарий программы с источники ? Да никто.

Приоритеты настраиваются один раз для всех случаев.

Почему репозитарий не настраивает их сам ?

Какую труху? Я тебе выше показал, как поставить php5 просто и легко.

При правильно настроенных приоритетах. Да. Применить твой совет к сожалению не могу.

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

И что мешает ему собрать пакет со свежим софтом ? Политика дистрибутива. Так что мешает мне получить стабильный софт в стабильном дистрибутиве. design дистрибутива который привязывает меня к его репозитарию вместо нужного мне софта.

Ваше мнение очень важно для нас. Разрешите идти ?

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

Очевидно, что это бубунта

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

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

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

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

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

Мне интересен вопрос ТС, и я бы не отказался от дистра отвечающего его запросам.

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

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