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

Вс Июн 18 16:36:50 MSD 2006

On Sat, Jun 17, 2006 at 04:33:13PM +0400, Алексей Турбин wrote:

>> Сизиф -- репозитория для разработчиков. Это я беру за аксиому. Он должен
>> быть максимально удобен для разработчиков и мантейнеров, и мнение всех
>> остальных в контексте Сизифа учитываться не должно.
AT> С такими аксиомами мы далеко не уедем.
AT> Это вообще не аксиома в более точном смысле.
AT> Я предлагаю обсуждать более алгоритмические идеи.

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

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

Обрати внимание на слова "не ранее". Ранее нельзя выносить даже виновных.

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

Это описание того что есть сегодня.

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

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

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

Мое мнение -- это не важно. Для репозитория который используют
разработчики это не имеет значения. Я выложил новую версию библиотеки,
которую я поддерживаю, значит все должны с этим смириться. Или положить
эту же библиотеку под другим именем другой версии. Это -- безусловный
факт, и наличие unmet'ов этот процесс тормозить не должно.

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

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

Нет.

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

Как минимум от того, что мы усердно боремся с циклическими зависимостями,
которые, по словам ldv@ есть зло.

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

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

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

И хорошо продуманые алгоритмы с тестами на результат :)

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

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

А логика, которую я предлагаю, простая:

1. циклически проходимся по всему списку пакетов, которые есть в sisyphus
но их нет в этом репозитории, и пытаемся перенести пакеты поштучно.
Проходимся до тех пор, пока не окажется что не можем перевести ни один.

2. строим ассоциативных массив, в котором ключ это provides из sisyphus, а данные это список пакетов его предоставляющих.

3. опять проходимся по списку пакетов, пытаясь перенести пакет, вместе с
пакетами, которые ему требуются.

Есть идеи как это можно ещё оптимизировать, да и обрабатывать некоторые
сложные случаи. Для меня сложна пока задача, как быстро определить будет
ли новый репозиторий содержать unmet'ы, не создавая руками этот
репозиторий и не натравливая на него apt.

Вынесение пакета из репозитория обрабатывается тоже просто -- если
транзакция порождает unmet'ы для пакета, которого уже нет в sisyphus, то
эта транзакция является допустимой, и в ней же мы выносим этот пакет.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Настоящие демоны могут так fork'аться, что их потом без pid-файла не
найти.
		-- ldv in devel@