Обновление Pacman в Arch Linux

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

Проблема в старом package-query, но на самом деле это вообще меня не касается! Я сделал 'pacman -Suy'. Он честно предложил проапгрейдить pacman, я согласился. ВСЁ, что вылезло после этого, проблема криворуких пакетостроителей. Про левый yaourt вообще узнал только после гугла.
Причём я даже уверен, что уже сотни людей натолкнулись на эту кокашку, однако «всем пох» и при апгрейде pacman нет ни одного сообщения, мол, «обновите сначала это, потом ставьте pacman'. Это - халтура.

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

Cуществование msi само по себе не обязывает отказываться от идеи централизованного хранилища пакетов, но такое хранилище невозможно без унификации бинарного пакета. Так что единый формат «setup.msi» это не шаг назад, а шаг вперед.

ROLF.

но на самом деле это вообще меня не касается!

А нахера ты полез обновлять систему, если это тебя не касается? Вот вернутся родители с работы, они тебя накажут за испорченную ОС.

ВСЁ, что вылезло после этого, проблема криворуких пакетостроителей.

Нет, дорогой, это проблема твоих кривых ручек.

Про левый yaourt вообще узнал только после гугла.

А кто ж его в систему поставил? Неужели... ОН САМ?! Это бомба! Срочно на главную!

Даю подсказку для альтернативно одаренных: yaourt не является официальным пакетом Арча.

Бороться надо с раздробленностью системы дистрибуции.

Надо же, хоть одна здравая мысль.

Лично я не вижу никаких причин для существования deb и rpm как раздельных сущностей. Один из них можно смело выкидывать.

Из source-based дистров пусть выживет только гента, остальные не нужны.

Из промежуточных — оставить Арч. Арч, кстати, тоже можно перевести на deb/rpm. (Или наоборот взять pacman за общую основу всех дистров. Вообще похрену.)

Не логичнее ли сразу пытаться удалить мешающий package-query?

хм... самому не смешно? :) Что зн. «мешающий»? Я даже понятия не имею, что он делает вообще, но раз он стоит, значит кому-то был нужен! И если у него проблема, он тоже должен быть обновлён!

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

Неа. Как я понял, yaourt мешал своими зависимостями обновиться остальным пакетам, поэтому я его снёс. Хотя по идее, я вообще не должен думать о сторонних пакетах: pacman должен был жёстко обновиться, никаких интерфейсов в нём не меняли, поэтому дебильные пакеты с зависимостями от старого pacman должны были просто использовать новый.
ЭТО логично?

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

Первая попытка была _С_ учётом зависимостей. Хотя по идее, что за чухонская зависимость существует от pacman, если это тупо «менеджер пакетов»??? Ну а далее обновлял без зависимостей, что логично - опять же, смотрим на функционал: pacman управляет пакетами, юзает какие-нибудь bzip2, libarchive, etc... ему не пофик, какие там либы, если он тупо их ЮЗАЕТ?

Видимо, это старая как Линус проблема - пакеты собираются с черезчур жёсткими зависимостями от библиотек, хотя по сути между версиями а-ля 2.6.3 и 2.6.5 не должно быть НИКАКОЙ разницы.

хм... самому не смешно? :) Что зн. «мешающий»? Я даже понятия не имею, что он делает вообще, но раз он стоит, значит кому-то был нужен! И если у него проблема, он тоже должен быть обновлён!

Не умеешь пользоваться пакетной системой? Значит не трогай комп!

Через cab или запуском exe.

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

но на самом деле это вообще меня не касается!

Иди перечитай стартовую страницу арчвики.

Он честно предложил проапгрейдить pacman, я согласился. ВСЁ

И он ничего не сломал, потому что не смог обновить. А ты, если не знал, как решить проблему нормально, лучше бы вообще не трогал.

Про левый yaourt вообще узнал только после гугла.

Он у тебя до этого сам установился?

Причём я даже уверен, что уже сотни людей натолкнулись на эту кокашку, однако «всем пох» и при апгрейде pacman нет ни одного сообщения, мол, «обновите сначала это, потом ставьте pacman'. Это - халтура.

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

Не умеешь пользоваться пакетной системой? Значит не трогай комп!

geekless, твои сентенции бесполезны, не сри в тырнеты.

должен был
дебильные пакеты
должны были
я вообще не должен думать
ЭТО логично?

Логично, черт побери: ты не должен, ты и не думаешь.

pacman управляет пакетами, юзает какие-нибудь bzip2, libarchive, etc... ему не пофик, какие там либы, если он тупо их ЮЗАЕТ?

RORL RORL RORL.

Видимо, это старая как Линус проблема - пакеты собираются с черезчур жёсткими зависимостями от библиотек, хотя по сути между версиями а-ля 2.6.3 и 2.6.5 не должно быть НИКАКОЙ разницы.

Йа плакал. Что ни день, то праздник.

Срёшь тут только ты. Впрочем, если бы ты был достаточно вежлив, я бы рассказал тебе, как отремонтировать сломанную твоими кривыми руками систему. Но теперь у тебя только один выход: обидеться на опенсорс и поскорее скачать windows-seven-ultimate-x64-dvd-with-crack.iso бесплатно без регистрации.

И он ничего не сломал, потому что не смог обновить.

В чём причина? Что за фундаментальная библиотека помешала арчу стать свежее? Какие вообще проблемы должны возникать у тривиальной программы, которую просто пытаются обновить? Я не хакер, в системе ничего не менял, значит ОБЯЗАНА ОБНОВЛЯТЬСЯ.

Тебе уже сказали — проблемы нет.

Упорот как раз ты - проблема есть, но ты как дебил игнорируешь её наличие и пытаешься говорить о чьей-то криворукости. Напоминает ментально незрелую прыщету, которая поставила линукс и чуть не лопнула от гордости. Остынь, сынок, сквозит от тупости.

Ещё один бессмысленный пост. Я правильно сделаю, если тебя заигнорю?

Матумба, зачем ты слезла с паль^W убунты?

хм... самому не смешно? :)

Смешно, честно говоря.

Что зн. «мешающий»? Я даже понятия не имею, что он делает вообще, но раз он стоит, значит кому-то был нужен! И если у него проблема, он тоже должен быть обновлён!

Я повторю свой вопрос — зачет ты взял арч?

Неа. Как я понял, yaourt мешал своими зависимостями обновиться остальным пакетам, поэтому я его снёс.

И как ты, интересно, это понял?

Хотя по идее, я вообще не должен думать о сторонних пакетах

Можно и вообще не думать, какие проблемы.

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

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

Первая попытка была _С_ учётом зависимостей. Хотя по идее, что за чухонская зависимость существует от pacman, если это тупо «менеджер пакетов»??? Ну а далее обновлял без зависимостей, что логично - опять же, смотрим на функционал: pacman управляет пакетами, юзает какие-нибудь bzip2, libarchive, etc... ему не пофик, какие там либы, если он тупо их ЮЗАЕТ?

Жесть вообще…

Надо же, хоть одна здравая мысль.

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

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

То есть путь к коммунизму я вижу таким: 1 - принимаем общий формат пакета, 2 - принимаем общие ветки версий (bleeding/testing/staging/stable/decaying/rotting/whatever). Отсюда: нужен ровно один _бинарный_ репозиторий (что не мешает существованию миллиона зеркал, но не требует орды народа на поддержку), и если какой-то софтописец хочет вбросить свой пакет, например, в stable, то пусть он его сам сконпеляет с зависимостями из stable и спокойно вбросит.

Я правильно сделаю, если тебя заигнорю?

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

1 - принимаем общий формат пакета

ЧСВ разработчиков не позволит.

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

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

Какие вообще проблемы должны возникать у тривиальной программы, которую просто пытаются обновить? Я не хакер, в системе ничего не менял, значит ОБЯЗАНА ОБНОВЛЯТЬСЯ.

Жаль, цитатник умер…

проблема есть

Только у криворучек же.

Напоминает ментально незрелую прыщету, которая поставила линукс и чуть не лопнула от гордости. Остынь, сынок, сквозит от тупости.

До-до-до, и пожками ещё потопай, и дульки в монитор покрути.

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

А тут всё те же и льют всё то же! Грустно...

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

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

1 - принимаем общий формат пакета

Посольку это невозможно в силу ЧСВ дистрописателей, надо искать другой путь. Нужно, чтобы какой-то из пакетных менеджеров (dpkg/rpm) научился нативно ставить пакеты от другого. Разумеется, несовместимости самих пакетов в плане зависимостей друг от друга и правила именования это не исправит. Но. Это создаст стимул преодолеть эти несовместимости. После чего один из типов форматов упаковки тупо отомрет.

2 - принимаем общие ветки версий (bleeding/testing/staging/stable/decaying/rotting/whatever). Отсюда: нужен ровно один _бинарный_ репозиторий (что не мешает существованию миллиона зеркал, но не требует орды народа на поддержку), и если какой-то софтописец хочет вбросить свой пакет, например, в stable, то пусть он его сам сконпеляет с зависимостями из stable и спокойно вбросит.

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

Тем не менее, это лишние руки. Руки, делающие дурную работу по доставке еды со стола(от автора) до пользователя - просто потому, что пользователь, как правило, технически неспособен брать еду со стола сам.

Нет. Это руки, которые делают нужную работу - по интеграции ПО в дистрибутив.

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

Да не говорю я, что там _всё_ зашибись. Просто венда готова к централизованному репу (просто его нет), а вот в люниксах как-то все кисло даже в теории.

Посольку это невозможно в силу ЧСВ дистрописателей, надо искать другой путь.

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

Вот хорошо бы Торвальдс в один прекрасный день встал во весь рост и звучно сказал: ДА ГОВНО ВАШ .(ДЕБ|РПМ)! ХВАТИТ УЖЕ СЛОНИКОВ ИЗ ГОВНА ЛЕПИТЬ, ГО МЕЙНСТРИМ! Но не встанет же(

Я ж говорю «дурную», а не «ненужную». Эта работа действительно нужна - но лишь ввиду идиотизма существующей ситуации с раздробленностью дитрибутивов.

Еще мысль такая есть:

Софт в репах можно по способу сборки классифицировать как:

1. Основной софт системы, собранный мейнтейнерами дистрибутива.

2. Популярный софт, который тоже собирают мейнтейнеры, потому что он популярный. (Но билдскрипты не обязательно пишут они сами.)

3. Софт, который собран автором программы. (Нужен механизм верификации, что чувак N — автор программы?)

4. Билдскрипты, добавленные пользователями, для которых нет сборок, но которые могут потенциально попасть в группу 2, если будут популярны. Собираются автоматически на локальной машине при «установке».

Вот относительно 4-й категории. Пусть чувак Ч ставит такой софт. Почему бы не закэшировать собранный им пакет в репозиторий? Потому что мы не доверяем чуваку Ч. Вот если бы была криптографическая гарантия, что пакет П действительно собран по скрипту С без дополнительных патчей и «левых» библиотек — тогда другое дело. Такое теоретически можно сделать?

Потому что тогда всё зверски упрощается.

1. Нанимаем толпу волонтеров, желающий обсепечивать сборку пакетов для своего-любимого-дистрибутива. Они ставят демон, демон всё остальное делает сам.

2. Вторая, третья и чертвертая категория пакетов автоматически объединяются в одну: «софт за пределами базовой платформы, для большинства из которого есть готовые пакеты, а остальные — компилируются автоматически при установке по сборочным скриптам».

3. Профит!

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

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

Нет никакого «способа уломать», но можно улучшать условия для. Одно из условий я и назвал.

Ты меня не понял. Под setup.msi я не имел в виду конкретно формат пакета, я подразумевал общую концепцию установки пакетов в винде: сам нашел сайт нужной проги, сам скачал, сам поставил. Вот такая система доставки это шаг назад, по сравнению с репами в линуксе. Против единого бинарного формата пакетов я и не спорю.

Почему идиотизма?

Между федорой и дебианом - различий не меньше чем между разными ядрами ОС. Вполне нормальная ситуация - дистрибутив это набор ПО, собранного и сконфигурированного в соответствии с определенными правилами.

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

Ему приспичило обновить pacman и filesystem одновременно.

Обман. Пока не обновишь pacman, ничего другое не будет обновляться.

а затем беги с злого этого форума

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

Между федорой и дебианом - различий не меньше чем между разными ядрами ОС. Вполне нормальная ситуация - дистрибутив это набор ПО, собранного и сконфигурированного в соответствии с определенными правилами.

1. Эти различия не относятся к пакетному менеджеру.

2. Прикладному софту на большинство этих различий начхать.

3. В тех местах, где не начхать, проблему можно разрулить срабатыванием разных хуков (в дебиане один, в федорке — другой) на этапе установки пакета. Если бы пакеты имели одинаковый формат.

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

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

3) Как костыльный вариант - hello_isden.txt, закоммиченный в корень авторского репозитория с сорцами. Но вообще для этого есть механизмы подписывания пакетов.

Пункт 4 можно вынести за скобки. Я думаю, автору не западло написать для своего поделия билдскрипт, и абсолютное большинство юзеров всегда предпочтет «родную» версию, то есть, версию автора, а не васи. А если вася хочет поделиться своим пакетом, то геть нафиг из основного репа, велкам ту песочница по типу аура или даже арчевской же community, над которой висит гигантский плакат «ТЕПЕРЬ ВЫ САМИ ВО ВСЁМ ВИНОВАТЫ».

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

Фу, тролль. При чём тут маны, ясно ведь, что ищущий всё найдёт. Вопрос лишь в том, чтобы искать меньше.

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

Между федорой и дебианом - различий не меньше чем между разными ядрами ОС.

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

В вашем ауре 146% пакетов криво собраны.

Откуда ты такой взялся... Учи матчасть, в ауре собранных пакетов вообще нет.

1. Эти различия не относятся к пакетному менеджеру.

В том числе и к нему. Форматы действительно разные, в dpkg есть

2. Прикладному софту на большинство этих различий начхать.

Мне не начхать, как пользователю этого самого «софта». Только мое мнение и релевантно, а не куска байтов.

3. В тех местах, где не начхать, проблему можно разрулить срабатыванием разных хуков (в дебиане один, в федорке — другой) на этапе установки пакета. Если бы пакеты имели одинаковый формат.

А ничего, что политики релизов совершенно разные? Что «хуки» сейчас устроены совершенно по-разному.

Не поясните как совместить модель вызова скриптов мейнтейнера в дебиан и в федоре? Или вы тупо не имеете понятия о чем речь? :)

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

Я уже приводил пример - патчи. Вам мало?

Значит у нас сильно разные наборы пакетов. У меня - были.

Как всегда, в новости про арч арчехейтеров больше чем арчефилов.

Ага, даже не удивительно.

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

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

О, ну может ты мне что-то расскажешь, м? Примеры «различий». которые нельзя упихать в пакеты?

Надо же, хоть одна здравая мысль.

Для этого уже есть smart.

Арч, кстати, тоже можно перевести на deb/rpm.

Самая гениальная мысль во всём треде про pacman. :)

Меня гораздо больше привлекала идея пакетного менеджера razor, которым мы с Ричардом Хьюзом как-то обсуждали. Идея была в том, что в нём существовали бы разные бэкэнды для разных форматов пакетов (deb, rpm, .pkg.tar.gz), разные бэкэнды для баз данных пакетов (yum, apt, pacman), и единый код их скачивания, разрешения зависимостей и установки. Тогда можно было бы прийти к единому пакетному менеджеру.

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

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

Вообще я считаю, что сборкой пакетов должны заниматься buildhost-ы. Разработчик забросил через веб-интерфейс .src.rpm, и всё сразу собралось и для stable, если зависимости в спеке позволяют, и для current.

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

На базовую систему нужно. В случае базовых пакетов, мейнтейнер == разработчик, делающий из кучи разрозненного ПО работоспособную ОС.

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

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

Пункт 4 можно вынести за скобки. Я думаю, автору не западло написать для своего поделия билдскрипт, и абсолютное большинство юзеров всегда предпочтет «родную» версию, то есть, версию автора, а не васи. А если вася хочет поделиться своим пакетом, то геть нафиг из основного репа, велкам ту песочница по типу аура или даже арчевской же community, над которой висит гигантский плакат «ТЕПЕРЬ ВЫ САМИ ВО ВСЁМ ВИНОВАТЫ».

Ты недопонял. Это стирает фактически различия между 3-й и 4-й группой. Написал скрипт, кинул в репозиторий, пакеты пересобрались на любой свободной машине. Различие лишь в цифровой подписи, что этот скрипт — от автора ПО, а тот — от дяди Пети.

А сама сборка выглядит так:

1. «Я волонтёр, нанявшийся отвечать за сборку пакетов в разделе community репозитория. Мой комп настроен пересобирать все пакеты, начинающиеся на буквы k,l,m,n для 3-х веток двух платформ.»

2. «Я дядя Петя с кустомными патчами на несколько софтин. Мой комп автоматически пересобирает пакеты, как только я запиливаю в репозиторий обновление сборочных скриптов.»

3. «А я Разработчик Разработкович, мой комп тоже автоматом собирает обновления для релизных пакетов, а также каждую ночь пересобирает тестовые пакеты.»

А сам репозиторий должен быть, логически, общим. (Физически, не важно как он организован.) Просто поделить его на зоны видимости и при подборе пакетов закрыть по дефолту часть зон. По принципу «хочешь видеть непроверенное ПО от дядь-Петь — включи опцию в конфигах пакетного менеджера».

Уже привел чуть выше пример - maintainer scripts. см. Debian Policy, ch. 6.

То что и как они делают, скажем так - различается для rpm и deb очень сильно. Начиная от того как именно (в какой последовательности, с какими аргументами) вызываются и заканчивая конкретным наполнением.

Не поясните как совместить модель вызова скриптов мейнтейнера в дебиан и в федоре? Или вы тупо не имеете понятия о чем речь? :)

Ты выделенную жирным надпись «Если бы пакеты имели одинаковый формат.» хорошо видишь, нет?

Я уже приводил пример - патчи. Вам мало?

Только когда патчи затрагивают API библиотек.

Вообще я считаю, что сборкой пакетов должны заниматься buildhost-ы.

Да это подробности и детали.

Разработчик забросил через веб-интерфейс .src.rpm, и всё сразу собралось и для stable, если зависимости в спеке позволяют, и для current.

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

Меня гораздо больше привлекала идея пакетного менеджера razor, которым мы с Ричардом Хьюзом как-то обсуждали. Идея была в том, что в нём существовали бы разные бэкэнды для разных форматов пакетов (deb, rpm, .pkg.tar.gz), разные бэкэнды для баз данных пакетов (yum, apt, pacman), и единый код их скачивания, разрешения зависимостей и установки. Тогда можно было бы прийти к единому пакетному менеджеру.

Это хорошая идея. Я тоже об этом думаю.

И я бы расширил идею. Вот я использузую, предположим, 20 пакетов из AUR-а. Что я хочу: я хочу научить пакетный менеджер видеть виртуальный «репозиторий» этих пакетов. Когда PKGBUILD обновляется, «обновляется» виртуальный пакет в репозитории. Когда я такой пакет буду апдейтить, backend, отвечающий за скачивание пакета, выполнит его сборку.

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

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

Самая гениальная мысль во всём треде про pacman. :)

И зачем тогда нужен этот ваш арч?

Но это всё утопия, всё равно каждый дебианщик захочет биндинги на перле/плюсах и всякие autoremove

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

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