[devel] [sisyphus -> devel] Стабильный Сизиф

Michael Shigorin =?iso-8859-1?q?mike_=CE=C1_osdn=2Eorg=2Eua?=
Пн Июн 19 12:44:10 MSD 2006


On Sun, Jun 18, 2006 at 04:36:50PM +0400, Денис Смирнов wrote:
> AT> Я предлагаю обсуждать более алгоритмические идеи.
> Нам нужен репозиторий для разработчиков. Sisyphus по факту
> выполняет эту задачу. Так как всех мантейнеров сажать на
> зарплату никто не собирается, им должно быть удобно. Иначе они
> просто уйдут.

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

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

> >> Для разработчиков удобно иногда совершать действия, которые
> >> приводят к появлению множества unmet'ов. Значит в сизифе
> >> наличие unmet'ов не рекомендовано, но выносить в orphaned
> >> неустанавливаемый пакет можно не ранее чем через 2 месяца
> >> (то бишь 8 недель),
> AT> Ты рассматриваешь простейший вариант, когда имеется непосредственный
> AT> unmet, в котором виноват сам этот пакет, содержащий unmet.  Существуют
> AT> другие варианты, когда пакет нельзя установить из-за unmet'ов в других
> AT> пакетах "вниз по дереву" (или "вверх"?).
> Обрати внимание на слова "не ранее". Ранее нельзя выносить даже виновных.

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

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

> AT> В общем случае ситуация может быть ещё сложнее: пакет разрешает один
> AT> старый unmet и добавляет один новый.  Хороший это пакет или плохой?
> Мое мнение -- это не важно. Для репозитория который используют
> разработчики это не имеет значения. Я выложил новую версию
> библиотеки, которую я поддерживаю, значит все должны с этим
> смириться. Или положить эту же библиотеку под другим именем
> другой версии. Это -- безусловный факт, и наличие unmet'ов этот
> процесс тормозить не должно.

Факт, но не согласующийся с заботой о коллегах.  Иногда бывают
дохлые, хотя полезные апстримы, и недостаток знаний для починки.
Выход -- параллельные версии библиотек, как это ни неприятно.
Но это тоже труд, особенно с учётом того, что предыдущая версия
скорее сломается в бегущем вперёд окружении (e.g. gcc).

> Такая ситуация может быть, и мне кажется что нам надо искать не
> "лучшее" решение, а просто приемлимое.

+1

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



Подробная информация о списке рассылки Devel