[devel] RPMS.*

[Michael Shigorin]

On Wed, Apr 04, 2012 at 10:04:19PM +0400, Dmitry V. Levin wrote:
> > Щас глянул в текущую очередь на "исправление" невооруженным
> > взглядом, -- по настоящему сизифов труд, вместо реального
> > исправления/обновления/тестирования -- полировка хлама.

Бывает и так, что особенно досадно.

> > И, кстати, по результатам предущей починки RPATH имеем:
> > $ rpm -qRp Sisyphus/files/SRPMS/*|grep chrpath|wc -l
> > 171
> > В 99% процентах случаев хватило бы %autoreconf.

Кажется, у меня была среди них минимум пара пакетов,
где %autoreconf не обошлось и пришлось воткнуть chrpath.
Так что уже не 99%. :)

> Кто мешает исправлять пакеты правильно?

Время, силы, приоритеты.

> > Пожалуй, я скоро начну выступать за RPMS.contrb
> Зачем RPMS.contrb нужен в Сизифе?  Пусть лучше живет отдельно,
> и у каждого свой.

Не хотелось бы настаивать и разводить, но тогда пусть и сизиф
живёт отдельно у каждого свой.  Потому что сейчас бОльшая часть
сизифа и есть по качеству RPMS.contrib даже по моим меркам,
не говоря о вдумчивых и придирчивых разработчиках.

Проблема с таким сизифом была бы ровно того же плана:
управляемость (хотя бы на уровне sources.list) и discoverability.
Если без адекватных инструментов поиска/подключения/отключения
решить, что персональные репо заменят хоть и свалку, но городскую
-- получится примерно такой же пшик, как с кличем "всё собирать
из git".  Надеюсь, ты не жаждешь и это выяснить экспериментально.

То же и опыт Daedalus показывает: там хоть найти можно было,
а по частным нычкам на тогдашнем http://search.altlinux.org
умаялся составлять и поддерживать мини-каталог.

Т.е. я бы хотел:
- иметь возможность поддерживать пакеты в Sisyphus main,
  потому что они достаточно интересны и в приличном виде
  для последующего вхождения в стабильные бранчи и выпуски
  (при этом для них можно и дальше закручивать гайки в
  sisyphus_check);
- также и в Sisyphus contrib/media -- то, что бывает полезно,
  но на первосортный продукт не тянет (и моими силами тянуть
  не будет) либо не является программным продуктом вовсе;
- публиковать нетривиальные бэкпорты или эксперименты
  в "долгоиграющих" частных репозиториях, которые можно найти;
- иметь возможность подготавливать обновления во все эти места
  с использованием короткоживущих "карманов", которые удобно
  предоставлять по записи e.g. всем тем, чьи пакеты получили бы
  анметы при попытке мержа такого "кармана" в базовый репо.

При этом смешивать (де)централизацию и (не)качество не стоит:
напомню, ott@ ушёл тогда, когда вместо перемещения из такого
main в такой contrib пакеты emacs* перестали и пересобираться,
и поддерживаться.  Это было крайне небрежно и расточительно.

Если это всё обсуждаемо -- давай попробуем не спеша вывести
список вариантов и выписать уже предсказуемые плюсы-минусы.

-- 
 ---- WBR, Michael Shigorin <mike на altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/