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

[Alexey Tourbin]

On Sat, Jun 17, 2006 at 03:20:59PM +0400, Денис Смирнов wrote:
> AT> Какое количество априорной информации необходимо, чтобы автоматически
> AT> начать транзакцию?  Любой unmet начинает транзакцию, которая завершается
> AT> с его исчезновением?  В этом месте возникает "бифуркация", то есть сизиф
> AT> "расслаивается" на две части.  В контексте каких транзакций тогда нужно
> AT> собирать вновь поступающие пакеты?
> 
> Сизиф -- репозитория для разработчиков. Это я беру за аксиому. Он должен
> быть максимально удобен для разработчиков и мантейнеров, и мнение всех
> остальных в контексте Сизифа учитываться не должно.

С такими аксиомами мы далеко не уедем.
Это вообще не аксиома в более точном смысле.
Я предлагаю обсуждать более алгоритмические идеи.

> Для разработчиков удобно иногда совершать действия, которые приводят к
> появлению множества unmet'ов. Значит в сизифе наличие unmet'ов не
> рекомендовано, но выносить в orphaned неустанавливаемый пакет можно не
> ранее чем через 2 месяца (то бишь 8 недель),

Ты рассматриваешь простейший вариант, когда имеется непосредственный
unmet, в котором виноват сам этот пакет, содержащий unmet.  Существуют
другие варианты, когда пакет нельзя установить из-за unmet'ов в других
пакетах "вниз по дереву" (или "вверх"?).

> Вывод -- Sisyphus это репозиторий где целостность _рекомендована_, но _не
> гарантируется_.

Это не дает ничего нового.

Я задаюсь вопросом: как блокировать unmet'ы на входе (в incominger'е)?

Допустим, пришёл пакет, после которого количество unmet'ов увеличивается.
По логике вещей такому пакету надо дать reject.  Но следом за ним идёт
другой пакет, после которого количество unmet'ов опять становится на
место.  Эти два пакета могут образовать "транзакцию".  Но если и после
двух этих пакетов количество unmet'ов станет более высоким, тогда уже
нелегко определить, какой именно из этих пакетов виноват.  Тогда
остается зарубить всю транзакцию.

В общем случае ситуация может быть ещё сложнее: пакет разрешает один
старый unmet и добавляет один новый.  Хороший это пакет или плохой?

> Нам нужен второй репозиторий. В этот второй репозитория будут копироваться
> группы пакетов (от одного и более) из Сизифа таким образом, чтобы в этом
> репозитории не образовывалось unmet'ов. Никогда.  Пакеты переносятся сразу
> и исходные, и собраные из них _в контексте Сизифа_ бинарные.

А пересобираемость в этом репозитарии важна?
И откуда уверенность, что процесс сходится?  Другими словами, откуда
уверенность, что в этот репозитарий через некоторое время хоть что-то
можно будет перенести?

И вообще, как определить "группы пакетов (от одного и более) из Сизифа",
после копирования которых в репозитарии не будет unmet'ов?   Это что
NP-полная задача?  Hint: при копировании пакета A или пакета B в
репозитарий unmet'ов не появляется, а при копировании A и B одновременно
unmet появляется.  Может такое быть?

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

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

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

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

Я же говорю, не надо выдавать желаемое за реализуемое.
Попробуй нарисовать скрипт, импотенция сразу подступит к горлу.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 191 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20060617/02d4a23c/attachment-0001.bin>