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

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

[@ 2006-06-15 9:48 UTC (permalink / raw)]

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

[@ 2006-06-15 10:22 UTC (permalink / raw)]

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

[@ 2006-06-15 10:30 UTC (permalink / raw)]

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

[@ 2006-06-15 10:41 UTC (permalink / raw)]

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

[@ 2006-06-15 11:03 UTC (permalink / raw)]

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

[@ 2006-06-15 11:07 UTC (permalink / raw)]

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

[@ 2006-06-15 11:50 UTC (permalink / raw)]

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

[@ 2006-06-15 12:01 UTC (permalink / raw)]

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

[@ 2006-06-15 12:04 UTC (permalink / raw)]

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

[@ 2006-06-15 12:17 UTC (permalink / raw)]

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

[@ 2006-06-15 12:24 UTC (permalink / raw)]

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

[@ 2006-06-15 12:42 UTC (permalink / raw)]

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

[@ 2006-06-15 12:44 UTC (permalink / raw)]

Re: [devel] Стабильный Сизиф

[@ 2006-06-15 12:45 UTC (permalink / raw)]

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

[@ 2006-06-15 12:49 UTC (permalink / raw)]

Re: [devel] Стабильный Сизиф

[@ 2006-06-15 12:54 UTC (permalink / raw)]

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

[@ 2006-06-15 12:58 UTC (permalink / raw)]

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

[@ 2006-06-15 12:58 UTC (permalink / raw)]

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

[@ 2006-06-15 12:58 UTC (permalink / raw)]

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

[@ 2006-06-15 12:58 UTC (permalink / raw)]

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

[@ 2006-06-15 13:00 UTC (permalink / raw)]

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

[@ 2006-06-15 13:03 UTC (permalink / raw)]

Re: [devel] Стабильный Сизиф

[@ 2006-06-15 13:06 UTC (permalink / raw)]

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

[@ 2006-06-15 14:58 UTC (permalink / raw)]

Re: [devel] Стабильный Сизиф

[@ 2006-06-15 14:59 UTC (permalink / raw)]

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

[@ 2006-06-15 16:40 UTC (permalink / raw)]

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

[@ 2006-06-15 16:44 UTC (permalink / raw)]

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

[@ 2006-06-15 16:50 UTC (permalink / raw)]

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

[@ 2006-06-15 16:57 UTC (permalink / raw)]

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

[@ 2006-06-15 17:00 UTC (permalink / raw)]

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

[@ 2006-06-15 17:02 UTC (permalink / raw)]

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

[@ 2006-06-15 17:08 UTC (permalink / raw)]

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

[@ 2006-06-15 17:16 UTC (permalink / raw)]

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

[@ 2006-06-15 17:17 UTC (permalink / raw)]

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

[@ 2006-06-15 17:24 UTC (permalink / raw)]

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

[@ 2006-06-15 17:25 UTC (permalink / raw)]

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

[@ 2006-06-15 20:29 UTC (permalink / raw)]

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

[@ 2006-06-15 20:46 UTC (permalink / raw)]

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

[@ 2006-06-15 20:48 UTC (permalink / raw)]

[devel] Стабильный пакет > Стабильный Сизиф

[@ 2006-06-16 3:14 UTC (permalink / raw)]

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

[@ 2006-06-16 7:09 UTC (permalink / raw)]

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

[@ 2006-06-16 7:16 UTC (permalink / raw)]

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

[@ 2006-06-16 7:38 UTC (permalink / raw)]

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

[@ 2006-06-16 7:44 UTC (permalink / raw)]

Re: [devel] Стабильный пакет > Стабильный Сизиф

[@ 2006-06-16 9:18 UTC (permalink / raw)]

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

[@ 2006-06-16 10:29 UTC (permalink / raw)]

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

[@ 2006-06-16 10:31 UTC (permalink / raw)]

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

[@ 2006-06-16 10:32 UTC (permalink / raw)]

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

[@ 2006-06-16 10:44 UTC (permalink / raw)]

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

[@ 2006-06-16 10:44 UTC (permalink / raw)]

Re: [devel] cups

[@ 2006-06-16 12:02 UTC (permalink / raw)]

Re: [devel] Стабильный пакет > Стабильный Сизиф

[@ 2006-06-16 12:07 UTC (permalink / raw)]

Re: [devel] Стабильный пакет > Стабильный Сизиф

[@ 2006-06-16 12:13 UTC (permalink / raw)]

Re: [devel] Стабильный пакет > Стабильный Сизиф

[@ 2006-06-16 12:21 UTC (permalink / raw)]

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

[@ 2006-06-16 13:14 UTC (permalink / raw)]

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

[@ 2006-06-16 13:24 UTC (permalink / raw)]

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

[@ 2006-06-16 13:51 UTC (permalink / raw)]

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

[@ 2006-06-16 14:18 UTC (permalink / raw)]

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

[@ 2006-06-16 14:20 UTC (permalink / raw)]

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

[@ 2006-06-16 14:38 UTC (permalink / raw)]

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

[@ 2006-06-16 14:55 UTC (permalink / raw)]

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

[@ 2006-06-16 15:00 UTC (permalink / raw)]

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

[@ 2006-06-16 15:17 UTC (permalink / raw)]

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

[@ 2006-06-16 15:22 UTC (permalink / raw)]

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

[Fr. Br. George]

On Fri, Jun 16, 2006 at 06:20:57PM +0400, Денис Смирнов wrote:
> On Fri, Jun 16, 2006 at 05:51:36PM +0400, Fr. Br. George wrote:
> 
> >> А CUPS после обновления отлично работает, если пользователя в группу lp
> >> добавить :)
> FBG> Ты знал! Ты знал!!
> 
> Нет, я сначала потратил два часа, чтобы понять почему не могу распечатать
> нужный мне документ :(
А мне за пять минут  самба помогла -- она прямо так в логе и писала, что
сокет открыть не может. Я глянул на сокет -- а он, гад, 600. Кстати, lp
-- служебная группа, по идее в неё тлько некоторые setgid-ные программки
лазать должны, и после того, как inger пофиксит багу (а это именно
бага), надо будет всех из неё выкинуть.

-- 
			George V Kouryachy (aka Fr. Br. George)
			mailto:george at altlinux_ru

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

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 995 bytes --]

On Thu, Jun 15, 2006 at 02:50:05PM +0300, Led wrote:
> > 1) Не всегда содержимое Sisyphus настолько стабильно, что бы на его базе
> > можно было бы собрать инсталяционный образ. Например - в данный момент
> > это возможно только теоретически. На практике ничего не получится.
> 
> А как на счёт внедрения схемы TRANSACT/COMMIT в incoming или между incoming и 
> Sisyphus? Это вроде могло бы стабилизировать репозитарий хотя бы в плане 
> целостности...

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

Какое количество априорной информации необходимо, чтобы автоматически
начать транзакцию?  Любой unmet начинает транзакцию, которая завершается
с его исчезновением?  В этом месте возникает "бифуркация", то есть сизиф
"расслаивается" на две части.  В контексте каких транзакций тогда нужно
собирать вновь поступающие пакеты?

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

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

[Денис Смирнов]

On Sat, Jun 17, 2006 at 02:17:45AM +0400, Алексей Турбин wrote:

AT> Какое количество априорной информации необходимо, чтобы автоматически
AT> начать транзакцию?  Любой unmet начинает транзакцию, которая завершается
AT> с его исчезновением?  В этом месте возникает "бифуркация", то есть сизиф
AT> "расслаивается" на две части.  В контексте каких транзакций тогда нужно
AT> собирать вновь поступающие пакеты?

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

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

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

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

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

Тем самым мы не создавая никакх проблем мантейнерам облегчаем жизнь тем,
кто хочет жить на девелоперских срезах. После этого, скорее всего, _Сизиф_
у мантейнеров будет жить исключительно в hasher'е, а этот новый
репозиторий большее количество людей сможет установить на свои рабочии
машины -- а значит увеличится база тестеров.

Ответственно заявляю -- пакет, который нельзя установить, очень трудно
тестировать :)

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

http://freesource.info

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

[Sergey Bolshakov]

>>>>> "mithraen" == mithraen  <mithraen@altlinux.ru> writes:
[skipped]

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

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

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

-- 

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

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 3452 bytes --]

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 появляется.  Может такое быть?

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

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

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

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

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

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

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

[Денис Смирнов]

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@

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

[Денис Смирнов]

On Sat, Jun 17, 2006 at 03:27:37PM +0400, Sergey Bolshakov wrote:

SB> Бишь, предполагается, что в таком репозитарии будет соблюдаться
SB> условие замкнутости и по сборочным зависимостям ? 

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

Собираемости -- однозначно нет.

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

http://freesource.info
----------------------------------------------------------------------------
Какой-то патч страшненький у тебя получился.
		-- ldv in #6099

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

[Alexey Rusakov]

Anton Farygin пишет:
>> собственно у мантейнра nautilus есть доступ к x86_64 среде.. Я так 
>> понимаю что просто нет времени/желания исправлять.
>>     
Не хочу ни на кого сваливать вину, но 5 июня пакет nautilus-2.14.1-alt4 
с исправлением этой проблемы был отправлен в Сизиф.  Результат сборки 
можно посмотреть, например, здесь: 
http://lists.altlinux.org/pipermail/sisyphus-incominger/2006-June/002316.html
Если не совсем понятно - пакеты libeel и libeel-devel собираются из 
одного исходного пакета. Как удалось получить такую неразрешённую 
зависимость, я не знаю. Внимание incoming'а на это я обратил в тот же 
день. Результат, как я понимаю, в том, что мне нужно переотправить 
пакет. Замечу, что после изменения порядка сборки пакетов это уже далеко 
не первый раз, когда приходится прибегать к дополнительной пересборке 
из-за криво разрешившихся зависимостей.

> В продолжение:
> sed падает вот на этом:
> s,@ALL_LINGUAS@,af am ar az be bg bn bs ca cs cy da de el en_CA en_GB
> es et eu fa fi fr ga gl gu he hi hr hu id is it ja ka
> km ko ku li lt lv mi mk ml mn ms nb ne nl nn no nso pa
> pl pt pt_BR ro ru rw sk sl sq sr sr@Latn sr@ije sv ta
> te th tk tr uk vi wa xh yi zh_CN zh_HK zh_TW zu,;t t
>   
Спаси-ибо. Что бы я без вас делал. Когда я спрашивал о том, как это 
лучше пофиксить, хоть бы одна св^Wживая душа откликнулась. Точнее, одна 
и откликнулась - mike@, которому почему-то до всего есть дело. У всех 
остальных, я так понимаю, просто нет этих, как их, времени/желания.
Извините, вспылил.

-- 
  Alexey "Ktirf" Rusakov

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

[Epiphanov Sergei]

В сообщении от Monday 19 June 2006 01:31 Alexey Rusakov написал(a):
> > В продолжение:
> > sed падает вот на этом:
> > s,@ALL_LINGUAS@,af am ar az be bg bn bs ca cs cy da de el en_CA en_GB
> > es et eu fa fi fr ga gl gu he hi hr hu id is it ja ka
> > km ko ku li lt lv mi mk ml mn ms nb ne nl nn no nso pa
> > pl pt pt_BR ro ru rw sk sl sq sr sr@Latn sr@ije sv ta
> > te th tk tr uk vi wa xh yi zh_CN zh_HK zh_TW zu,;t t
> >  
>
> Спаси-ибо. Что бы я без вас делал. Когда я спрашивал о том, как это
> лучше пофиксить, хоть бы одна св^Wживая душа откликнулась. Точнее, одна
> и откликнулась - mike@, которому почему-то до всего есть дело. У всех
> остальных, я так понимаю, просто нет этих, как их, времени/желания.
> Извините, вспылил.

Бывает. Мне, например, сложно помогать из-за того, что Сизиф получаю где-то 
раз в месяц-полтора, а тащить через сотовый телефон мегабайтные пакеты для 
проверки очень дорого и долго. Так и в трубу недолго вылететь. :)

-- 
С уважением, Епифанов Сергей

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

[Anton Farygin]

Alexey Rusakov wrote:
> Anton Farygin пишет:
>>> собственно у мантейнра nautilus есть доступ к x86_64 среде.. Я так 
>>> понимаю что просто нет времени/желания исправлять.
>>>     
> Не хочу ни на кого сваливать вину, но 5 июня пакет nautilus-2.14.1-alt4 
> с исправлением этой проблемы был отправлен в Сизиф.  Результат сборки 
> можно посмотреть, например, здесь: 
> http://lists.altlinux.org/pipermail/sisyphus-incominger/2006-June/002316.html
> Если не совсем понятно - пакеты libeel и libeel-devel собираются из 
> одного исходного пакета. Как удалось получить такую неразрешённую 
> зависимость, я не знаю. Внимание incoming'а на это я обратил в тот же 
> день. Результат, как я понимаю, в том, что мне нужно переотправить 
> пакет. Замечу, что после изменения порядка сборки пакетов это уже далеко 
> не первый раз, когда приходится прибегать к дополнительной пересборке 
> из-за криво разрешившихся зависимостей.

Аналогично. Но я в этом случае долго не думаю.. release++ и вперёд.


> 
>> В продолжение:
>> sed падает вот на этом:
>> s,@ALL_LINGUAS@,af am ar az be bg bn bs ca cs cy da de el en_CA en_GB
>> es et eu fa fi fr ga gl gu he hi hr hu id is it ja ka
>> km ko ku li lt lv mi mk ml mn ms nb ne nl nn no nso pa
>> pl pt pt_BR ro ru rw sk sl sq sr sr@Latn sr@ije sv ta
>> te th tk tr uk vi wa xh yi zh_CN zh_HK zh_TW zu,;t t
>>   
> Спаси-ибо. Что бы я без вас делал. Когда я спрашивал о том, как это 
> лучше пофиксить, хоть бы одна св^Wживая душа откликнулась. Точнее, одна 
> и откликнулась - mike@, которому почему-то до всего есть дело. У всех 
> остальных, я так понимаю, просто нет этих, как их, времени/желания.
> Извините, вспылил.

Я не видел этого письма, к сожалению.

Так проблема ещё актуальна ?

Почему оно только на x86_64 вылезает ?

Rgds,
Rider

Re: [devel] Стабильный Сизиф

[Michael Shigorin]

On Thu, Jun 15, 2006 at 01:48:57PM +0400, Fr. Br. George wrote:
> 5. Ещё раз: sync, freeze, testing, release -- это стадии Сизифа, а не
>    какого-либо дистрибутива. Это для сообщества, для нас самих.

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

> 6. Дистрибутив -- это _отличия_ от Сизифа, которые его авторы
> доводят параллельно. Накатим отличия на стабильный Сизиф --
> получим стабильный дистрибутив. Хоть сейчас в release.

Если снять крашеную оптику, то всё равно остаётся фиксация 
и более жёсткая прогонка результата (очень понравилось
бета-тестирование ALM2.4, ну и результат вполне).

> 		Примерный план-график рабочего цикла.
> 
> Стоит заметить, что действительные даты (особенно freeze и release) могут
> слегка (на неделю-две) сдвигаться вперёд, так, чтобы было удобнее всем, но
> ориентироваться всё же удобнее по месяцам, без неопределённостей.
> 
> Июнь-Август		Эксперименты, сессия и отпуска.
> Сентябрь		Sync
> 		Кидается клич: "Народ! Через месяц freeze! У вас всё готово?"
> 		Со словами "Какой там готово!" отдохнувший с лета народ
> 		принимается приводить в порядок дела. Возможно, сентября будет
> 		мало, заедем на октябрь.

Это, кстати, пора конференций, выставок и вообще повышенния
деловой активности.  На многих сказывается по части свободного
времени.

> Октябрь			Freeze
> 		Когда всё более-менее на уровне, объявляется заморозка.
> 		Все на блох! Обновления _версий_ пакетов допускаются только в
> 		крайнем случае (дыра в безопасности) или для специального
> 		класса пакетов (документация). Длится до тех пор, пока все
> 		release critical блохи не будут удушены.

Это очень жёсткий фриз, обычно делается двухступенька вроде --
сперва блокируются изменения soname и подобные, влекущие за собой 
серьёзный развал, а вообще изменения версии блокируются только
уже на стадии глубокой заморозки. (и без лоббирования специальных
классов ;)

> Ноябрь			Testing
> 		Объявляется первый release candidate. Кидается клич:
> 		"Сообщество! Ты боялось нестабильного Сизифа? Этот --
> 		стабильный! Кто найдёт ошибку сегодня -- исправим завтра, кто
> 		поленится -- исправим только через полгода!". RC продолжают
> 		выпускаться до тех пор, пока не перестанут приходить release
> 		critical блохи, или пока не надоест.

Тоже интересное "или".  Или пока не настанет декабрь?..
(это если верить в то, что это всё вообще планируемо в
абсолютных, а не относительных, интервалах и тем более
точках времени)

> Декабрь			Release
> 		(не позже середины декабря). Выпуск. Стабильный Сизиф
> 		оформляется в виде ветки. Если на ней выпущены какие-то
> 		дистрибутивы, ветка даже оказывается отчасти поддерживаемой.
> 		Сам Сизиф семимильными шагами движется в гору, навстречу
> 		новым блохам, зимней сессии и рождественским каникулам.
> Январь			Эксперименты и сессия
> Февраль			Sync
> Март			Freeze
> Апрель			Testing
> Май			Release

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

Если не торопиться впереди планеты всей, то на основе
декабрьского чего-то в принципе можно как раз к весне 
сделать rock solid distro.  При условии, конечно, что
зимой хватит здоровья, интереса и напильника вывалить
заморозку, а к весне оно будет коммерчески надо.

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

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

[Michael Shigorin]

On Sat, Jun 17, 2006 at 02:17:45AM +0400, Alexey Tourbin wrote:
> Как вы себе представляете идею с транзакциями?  Напишите подробнее.

Поищи мои письма про RPMS.incoming.  И поспрошай Большакова про
карманы (pockets) в sandman.

> Причем (сразу хинт) исходите не из желаемого, а попытайтесь
> понять, какие трудности могут возникнуть в реализации.  Это
> интересно.

Да, метод "пофантазировать" порой неплохо помогает :-)
Если его применением не заканчивается.

> Какое количество априорной информации необходимо, чтобы
> автоматически начать транзакцию?  Любой unmet начинает
> транзакцию, которая завершается с его исчезновением?  В этом
> месте возникает "бифуркация", то есть сизиф "расслаивается" на
> две части.  В контексте каких транзакций тогда нужно собирать
> вновь поступающие пакеты?

По-умолчанию -- в "большом" сизифе.  Возможно, получится как-то
автоматизировать процесс перемещения пакета в песочницу с новой
libA (где её как раз колбасят), если в его BuildRequires она
прямо (или даже косвенно) висит.

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

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

[Michael Shigorin]

On Sat, Jun 17, 2006 at 03:20:59PM +0400, Денис Смирнов wrote:
> Сизиф -- репозитория для разработчиков. Это я беру за аксиому.
> Он должен быть максимально удобен для разработчиков и
> мантейнеров, и мнение всех остальных в контексте Сизифа
> учитываться не должно.

Но может.

> Например компакту гарантии возможности пересобрать любой пакет
> в своем окружении не обязательны (AFAIK).

Но очень помогает, если всё-таки получается... долго думал, когда
поймал непересобираемость gnome2-utils на 3.0 (а надо было патчить).

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

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

[Michael Shigorin]

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/

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

[Michael Shigorin]

On Thu, Jun 15, 2006 at 08:08:48PM +0300, Led wrote:
> > А то обновил я тут  CUPS, блин.
> Я рассылку стараюсь читать, потому на Hold его сразу поставил:)

Я обновил, хотя читаю.

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

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

[Michael Shigorin]

On Fri, Jun 16, 2006 at 06:38:50PM +0400, Sergey V Turchin wrote:
> > Может мне рандомайзер какой добавить на группы, чтобы никто
> > так не делал?
> Лучше такие группы обзывать c подчеркиванием в начале, чтоб
> очевидно было.

В смысле "технические".  Кстати, эта мода вроде как наблюдается
(уже?) не только у нас.

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

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

[Michael Shigorin]

On Thu, Jun 15, 2006 at 04:42:06PM +0400, Epiphanov Sergei wrote:
> Может кто дать отмашку а-ля более-менее работает?

Читайте wiki.sisyphus.ru/changes (интересно, Sisyphus@Etersoft
сейчас разливают в удачные моменты?)

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

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

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 449 bytes --]

* Michael Shigorin <mike@> [060619 12:40]:
> > Как вы себе представляете идею с транзакциями?  Напишите подробнее.
> Поищи мои письма про RPMS.incoming.  И поспрошай Большакова про
> карманы (pockets) в sandman.
Это взаимоперпендикулярные понятия.  pocket в sandman это аналог
--repo + --with-stuff в hasher.  А RPMS.incoming это общий repo
для всех hasher'ов (beehive таки распределённая система в отличие
от).

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Michael Shigorin]

On Thu, Jun 15, 2006 at 04:04:50PM +0400, Damir Shayhutdinov wrote:
> > А вот выдержать месяц-два заморозки самого Сизифа, да и
> > поработать в это время не на гонку за фичами, а на
> > совместимость и более плотный багфикс, я вполне способен.
> А что делать в период фриза тем, у кого пакеты в порядке?

Если есть настроение -- помочь коллегам?  Например, анонсировав
"а я тут умею починять 64-битные примусы" ;-)

В команде наметилось несколько людей, которые помогают другим.
Мне кажется, другие им по жизни признательны.

> Плевать в потолок? Новую версию с новыми фичами выложить "на
> потестировать" не дадут...

Это в lkml вроде проходили, нет?  Может, кому-нибудь ещё
интересна история больших апстримов?  Я вот как-то интересовался
и ветками в ядре, и тем, как оцикливали mozilla.  Поучительно.


В ядре получалось так, что если прорывались деятели с фичами при
заморозке (и отсутствии unstable), то некоторое время штормило 
и нередко заканчивалось выбрасыванием нафиг притащенного.
На сейчас они вроде как пришли не только к stable maintenance
отдельной командой, а и к тому, что kernel.org -- это вообще-то
не совсем stable, за production -- к вендорам.

Мне кажется, что это вполне параллельно sisyphus/stable/distros,
если под stable понимать то, о чём Гоша говорил "под декабрь".


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

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

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

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

[Michael Shigorin]

On Thu, Jun 15, 2006 at 09:00:09PM +0400, Fr. Br. George wrote:
> И было бы хорошо, если бы эти времена можно было предугадать, и
> совсем здорово, если бы можно было предугадать времена, когда

Ты, разумеется, читаешь (а то и пополняешь)
http://wiki.sisyphus.ru/changes?

(был ещё проект Sisyphus newsletter, который помер не родившись;
в т.ч. из-за обсуждаемых здесь пользовательских эффектов, тогда
как раз касательно updates человек решил пойти на Debian)

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

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

[Michael Shigorin]

On Fri, Jun 16, 2006 at 12:46:14AM +0400, Damir Shayhutdinov wrote:
> > > А что делать в период фриза тем, у кого пакеты в порядке?
> > > Плевать в потолок? Новую версию с новыми фичами выложить
> > > "на потестировать" не дадут...
> > Во-первых, есть Дедал.
> Ага, с отсутствующим QA и таким же контингентом тестеров :(
> В Sisyphus/x86_64 частично похожая ситуация.

У backports та же проблема, но требовать её исправления от aris@
я лично никак не могу.  Если кто-то быстрее управится, то
предоставить молотилку, где можно пускать QA-роботов, за лето 
должно выйти.

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

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

[Michael Shigorin]

On Mon, Jun 19, 2006 at 12:54:40PM +0400, Alexey I. Froloff wrote:
> > > Как вы себе представляете идею с транзакциями?  Напишите
> > > подробнее.
> > Поищи мои письма про RPMS.incoming.  И поспрошай Большакова
> > про карманы (pockets) в sandman.
> Это взаимоперпендикулярные понятия.

Не совсем, скорее тонко/толсторезаное одно и то же.

> pocket в sandman это аналог --repo + --with-stuff в hasher.
> А RPMS.incoming это общий repo для всех hasher'ов (beehive таки
> распределённая система в отличие от).

Предлагался как по крайней мере big repo lock, который на самом
деле unlock по части unmets.  Вроде бы вполне понятно, что такое
может помочь при ситуации "упала 1 (одна) бомба, жертв и
разрушений -- полсизифе".

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

Последний раз проблемы были вроде как в apt, но с другой стороны 
-- дистрибутив + updates разве не ту же проблему ставят? (двойные
версии)

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

[devel] Daedalus (was: [sisyphus -> devel] Стабильный Сизиф)

[Michael Shigorin]

On Thu, Jun 15, 2006 at 04:24:42PM +0400, Damir Shayhutdinov wrote:
> > Почему не дадут? Дедал всегда живой...
> А по-моему, он всегда мертвый.

У меня было как I, так и O по Daedalus.

> В смысле тестируют пакеты из Дедала исчезающее малое количество
> пользователей.

Мне почему-то кажется, что он создан не для широкого, а как раз
для узкоспециализированного тестирования.

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

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

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

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 325 bytes --]

* Michael Shigorin <mike@> [060619 13:31]:
> Предлагался как по крайней мере big repo lock, который на самом
> деле unlock по части unmets.
Попытайся описать цикл работы с этим repo в виде пригодном к
скриптованию.

P.S. Описание должно быть пригодно с скриптованию, а не собсно
цикл ;-)

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Slava Semushin]

--- Michael Shigorin 2006-06-19 11:46:51 +0300
+++ Vyacheslav Semushin 2006-06-19 16:48:07 +0700

MS> > Лучше такие группы обзывать c подчеркиванием в начале, чтоб
MS> > очевидно было.
MS> В смысле "технические".  Кстати, эта мода вроде как наблюдается
MS> (уже?) не только у нас.

    Видел подобную тенденцию в OpenBSD ;-)

    К примеру, у них mpd работает от имени пользователя _mpd:
    http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/audio/mpd/pkg/PLIST?rev=1.2&content-type=text/plain


-- 
+ Slava Semushin | php-coder @ ngs.ru
+ ALT Linux Team | php-coder @ altlinux.ru
+ Expand QA Team | vsemushin @ swsoft.com

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

[Led]

В сообщении от 17 июня 2006 01:17 Alexey Tourbin написал(a):
> On Thu, Jun 15, 2006 at 02:50:05PM +0300, Led wrote:
> > > 1) Не всегда содержимое Sisyphus настолько стабильно, что бы на его
> > > базе можно было бы собрать инсталяционный образ. Например - в данный
> > > момент это возможно только теоретически. На практике ничего не
> > > получится.
> >
> > А как на счёт внедрения схемы TRANSACT/COMMIT в incoming или между
> > incoming и Sisyphus? Это вроде могло бы стабилизировать репозитарий хотя
> > бы в плане целостности...
>
> Как вы себе представляете идею с транзакциями?  Напишите подробнее.
> Причем (сразу хинт) исходите не из желаемого, а попытайтесь понять,
> какие трудности могут возникнуть в реализации.  Это интересно.
>
> Какое количество априорной информации необходимо, чтобы автоматически
> начать транзакцию?  Любой unmet начинает транзакцию, которая завершается
> с его исчезновением?  В этом месте возникает "бифуркация", то есть сизиф
> "расслаивается" на две части.  В контексте каких транзакций тогда нужно
> собирать вновь поступающие пакеты?

-- 
Led.

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

[Led]

В сообщении от 17 июня 2006 01:17 Alexey Tourbin написал(a):
> On Thu, Jun 15, 2006 at 02:50:05PM +0300, Led wrote:
> > > 1) Не всегда содержимое Sisyphus настолько стабильно, что бы на его
> > > базе можно было бы собрать инсталяционный образ. Например - в данный
> > > момент это возможно только теоретически. На практике ничего не
> > > получится.
> >
> > А как на счёт внедрения схемы TRANSACT/COMMIT в incoming или между
> > incoming и Sisyphus? Это вроде могло бы стабилизировать репозитарий хотя
> > бы в плане целостности...
>
> Как вы себе представляете идею с транзакциями?  Напишите подробнее.
> Причем (сразу хинт) исходите не из желаемого, а попытайтесь понять,
> какие трудности могут возникнуть в реализации.  Это интересно.
>
> Какое количество априорной информации необходимо, чтобы автоматически
> начать транзакцию?  Любой unmet начинает транзакцию, которая завершается
> с его исчезновением?  В этом месте возникает "бифуркация", то есть сизиф
> "расслаивается" на две части.  В контексте каких транзакций тогда нужно
> собирать вновь поступающие пакеты?

Основные проблемы возникать могут при поступлении в incoming библиотеки с 
новым soname.
Упрощённо алгоритм обработки "транзакции" вижу таким образом
1) Была libfoo с libfoo.so.x, от которой зависят пакеты в репозитарии.
2) В incoming пришла libfoo м libfoo.so.y.
3) Попытка пересобрать зависимые пакеты роботом с вновь поступившей libfoo
4) Если попытка полностью успешна - commit
5) Если попытка (п.3) полностью или частично НЕуспешна - уведомить мэйнтейнера 
libfoo и зависимых пакетов.
6) После уведомления мэйнтейнера libfoo (п.5), он должен собрать libfoo_X 
(очень желателен скрипт-инструмент для изготовления libfoo_X.spec из 
libfoo.spec, хотя бы частично автоматизирующий эту работу).
7) После уведомления мэйнтейнеры зависимых от libfoo пакетов пересобирают свои 
пакеты с libfoo.so.y.
8) В случае невозможности п.7 - мэйнтейнеры зависимых от libfoo пересобирают 
свои пакеты с libfoo_X, или (как вариант, на котором я не настаиваю, потому 
как "закидают гнилыми помидорами" - с libfoo.a версии X).
9) Если п.7 или п.8 успешны - commit.

Сорри, может что-то упустил - со стороны будет виднее.

Можете "пинать" ("пинки" с оскрблениями, в т.ч. в личку будут 
проигнорированны).

-- 
Led.

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

[Stanislav Ievlev]

On Fri, Jun 16, 2006 at 07:46:50PM +0400, Fr. Br. George wrote:
> On Fri, Jun 16, 2006 at 06:20:57PM +0400, Денис Смирнов wrote:
> > On Fri, Jun 16, 2006 at 05:51:36PM +0400, Fr. Br. George wrote:
> > 
> > >> А CUPS после обновления отлично работает, если пользователя в группу lp
> > >> добавить :)
> > FBG> Ты знал! Ты знал!!
> > 
> > Нет, я сначала потратил два часа, чтобы понять почему не могу распечатать
> > нужный мне документ :(
> А мне за пять минут  самба помогла -- она прямо так в логе и писала, что
> сокет открыть не может. Я глянул на сокет -- а он, гад, 600. Кстати, lp
> -- служебная группа, по идее в неё тлько некоторые setgid-ные программки
> лазать должны, и после того, как inger пофиксит багу (а это именно
> бага), надо будет всех из неё выкинуть.
Надеюсь что пофиксил, как минимум у меня несгидный lpq работает в режиме
control - server.

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

[Денис Смирнов]

On Mon, Jun 19, 2006 at 11:33:57AM +0300, Michael Shigorin wrote:
>> Сизиф -- репозитория для разработчиков. Это я беру за аксиому.
>> Он должен быть максимально удобен для разработчиков и
>> мантейнеров, и мнение всех остальных в контексте Сизифа
>> учитываться не должно.
MS> Но может.

Может. Но приоритетны для именно Сизифа -- разработчики и их удобство.

>> Например компакту гарантии возможности пересобрать любой пакет
>> в своем окружении не обязательны (AFAIK).
MS> Но очень помогает, если всё-таки получается... долго думал, когда
MS> поймал непересобираемость gnome2-utils на 3.0 (а надо было патчить).

Полезно. Но _такое_ без фриза малореально. А вот то о чем я говорю, можно
поддерживать полностью автоматически и _ежедневно_. 

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

http://freesource.info
----------------------------------------------------------------------------

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

[Денис Смирнов]

On Mon, Jun 19, 2006 at 11:44:10AM +0300, Michael Shigorin wrote:

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

Разумеется возможность вмешаться руками должна быть всегда.

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

Поэтому надо эти репозитории разделить.

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

Поэтому нужна автоматика. Которая не будет мешать ни одной стороне, а даст
результат. И логику такой автоматики я описал. Это не идеал, но
существенно лучше чем сложившаяся сейчас ситуация.

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

О чем я и говорю -- такая возможность _должна быть_. И Сизиф либо будет
перманенто частично разломаный, либо полноценная работа будет попросту
невозможна.

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

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

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

Я это понимаю :) Но обычно с этой библиотекой действительно _надо_
пересобрать пол сизифа. Только на пользователях другой половины Сизифа это
отражаться не должно.

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

http://freesource.info
----------------------------------------------------------------------------

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

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2714 bytes --]

On Mon, Jun 19, 2006 at 01:12:37PM +0300, Led wrote:
> Основные проблемы возникать могут при поступлении в incoming библиотеки с 
> новым soname.
> Упрощённо алгоритм обработки "транзакции" вижу таким образом
> 1) Была libfoo с libfoo.so.x, от которой зависят пакеты в репозитарии.
> 2) В incoming пришла libfoo м libfoo.so.y.
> 3) Попытка пересобрать зависимые пакеты роботом с вновь поступившей libfoo
> 4) Если попытка полностью успешна - commit
> 5) Если попытка (п.3) полностью или частично НЕуспешна - уведомить мэйнтейнера 
> libfoo и зависимых пакетов.
> 6) После уведомления мэйнтейнера libfoo (п.5), он должен собрать libfoo_X 
> (очень желателен скрипт-инструмент для изготовления libfoo_X.spec из 
> libfoo.spec, хотя бы частично автоматизирующий эту работу).

Либо помочь исправить пакеты, которые не удается собрать с libfoo.so.y.

> 7) После уведомления мэйнтейнеры зависимых от libfoo пакетов пересобирают свои 
> пакеты с libfoo.so.y.
> 8) В случае невозможности п.7 - мэйнтейнеры зависимых от libfoo пересобирают 
> свои пакеты с libfoo_X, или (как вариант, на котором я не настаиваю, потому 
> как "закидают гнилыми помидорами" - с libfoo.a версии X).
> 9) Если п.7 или п.8 успешны - commit.

Это разумно.  Это наводит на кое-какие мысли насчет модульной структуры
incominger'а.  То есть в данном случае после сборки каждого пакета
incominger должен попытаться обнаружить смену сонейма.  Если смена
сонейма обнаружена, в репозитарии генерируется некоторый абстрактный
"сигнал", который распространяется (propagate) на все остальные пакеты
и который система пытается обработать.  Зачатки этого подхода описаны
здесь: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-22.html#%_sec_3.3.4

По существу не ясно, чем гарантируется смена сонейма в конечное время.
То есть пункты 6, 7, 8 могут занять месяц, два, три...  Если для смены
каждого сонейма формировать отдельный отстойник и коммитить его целиком
только тогда, когда проблема будет полностью решена, тогда возможны
новые проблемы.  Допустим приходит новый пакет, который зависит от двух
отстойников ("транзакций").  Вопрос такой: к какому отстойнку его
отнести?  Нужно уже формировать "объединение" двух отстойников.
Если развить мысль (исходя из того, что полная смена сонейма занимает
довольно долгое время), то "объединение" нескольких отстойников
в конечном счете даст один большой новый отстойник, который до конца
переместить в сизиф никогда не удатся.  То есть будет "затык" в
альтернативном сизифе, который никак не удается слить в основной сизиф.

> Можете "пинать" ("пинки" с оскрблениями, в т.ч. в личку будут 
> проигнорированны).

Уже лучше чем про фортран и sisyphus-full. :)

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

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

[Led]

В сообщении от 19 июня 2006 15:12 Alexey Tourbin написал(a):
> On Mon, Jun 19, 2006 at 01:12:37PM +0300, Led wrote:
> > Основные проблемы возникать могут при поступлении в incoming библиотеки с
> > новым soname.
> > Упрощённо алгоритм обработки "транзакции" вижу таким образом
> > 1) Была libfoo с libfoo.so.x, от которой зависят пакеты в репозитарии.
> > 2) В incoming пришла libfoo м libfoo.so.y.
> > 3) Попытка пересобрать зависимые пакеты роботом с вновь поступившей
> > libfoo 4) Если попытка полностью успешна - commit
> > 5) Если попытка (п.3) полностью или частично НЕуспешна - уведомить
> > мэйнтейнера libfoo и зависимых пакетов.
> > 6) После уведомления мэйнтейнера libfoo (п.5), он должен собрать libfoo_X
> > (очень желателен скрипт-инструмент для изготовления libfoo_X.spec из
> > libfoo.spec, хотя бы частично автоматизирующий эту работу).
>
> Либо помочь исправить пакеты, которые не удается собрать с libfoo.so.y.
>
> > 7) После уведомления мэйнтейнеры зависимых от libfoo пакетов пересобирают
> > свои пакеты с libfoo.so.y.
> > 8) В случае невозможности п.7 - мэйнтейнеры зависимых от libfoo
> > пересобирают свои пакеты с libfoo_X, или (как вариант, на котором я не
> > настаиваю, потому как "закидают гнилыми помидорами" - с libfoo.a версии
> > X).
> > 9) Если п.7 или п.8 успешны - commit.
>
> Это разумно.  Это наводит на кое-какие мысли насчет модульной структуры
> incominger'а.  То есть в данном случае после сборки каждого пакета
> incominger должен попытаться обнаружить смену сонейма.  Если смена
> сонейма обнаружена, в репозитарии генерируется некоторый абстрактный
> "сигнал", который распространяется (propagate) на все остальные пакеты
> и который система пытается обработать.  Зачатки этого подхода описаны
> здесь:
> http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-22.html#%_sec_3.3.4
>
> По существу не ясно, чем гарантируется смена сонейма в конечное время.
> То есть пункты 6, 7, 8 могут занять месяц, два, три...

А это и есть пресловутый "человеческий фактор" - без него никак :( Чтоб не 
было "месяц-два-три" и привёл пункт 6. Либо новая libfoo не пропускается 
вобще, либо мэйнтейнеру нужно немножко озадачиться изготовлением libfoo_X 
(думаю, если продумать policy на libfoo => libfoo_X, то и "заскриптовать" это 
будет возможно).

> Если для смены 
> каждого сонейма формировать отдельный отстойник и коммитить его целиком
> только тогда, когда проблема будет полностью решена, тогда возможны
> новые проблемы.  Допустим приходит новый пакет, который зависит от двух
> отстойников ("транзакций").  Вопрос такой: к какому отстойнку его
> отнести?  Нужно уже формировать "объединение" двух отстойников.
> Если развить мысль (исходя из того, что полная смена сонейма занимает
> довольно долгое время), то "объединение" нескольких отстойников
> в конечном счете даст один большой новый отстойник, который до конца
> переместить в сизиф никогда не удатся.  То есть будет "затык" в
> альтернативном сизифе, который никак не удается слить в основной сизиф.

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

>
> > Можете "пинать" ("пинки" с оскрблениями, в т.ч. в личку будут
> > проигнорированны).
>
> Уже лучше чем про фортран и sisyphus-full. :)

Я уже понял, что кроме смайликов надо ещё слово "ЛОПАТА" ставить, чтоб не 
нарваться:)

-- 
Led.

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

[Michael Shigorin]

On Mon, Jun 19, 2006 at 04:12:39PM +0400, Alexey Tourbin wrote:
> Допустим приходит новый пакет, который зависит от двух
> отстойников ("транзакций").  Вопрос такой: к какому отстойнку
> его отнести?

Вот поэтому я и говорил пока про один RPMS.incoming.  А там,
отдышавшись, городить далее.

Нет, если тебя или кого ещё хватит это всё продумать и сделать
сразу, только лучше.  Просто не верится в такое.

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

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

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 3507 bytes --]

On Mon, Jun 19, 2006 at 03:26:26PM +0300, Led wrote:
> > По существу не ясно, чем гарантируется смена сонейма в конечное время.
> > То есть пункты 6, 7, 8 могут занять месяц, два, три...
> 
> А это и есть пресловутый "человеческий фактор" - без него никак :( Чтоб не 
> было "месяц-два-три" и привёл пункт 6. Либо новая libfoo не пропускается 
> вобще, либо мэйнтейнеру нужно немножко озадачиться изготовлением libfoo_X 
> (думаю, если продумать policy на libfoo => libfoo_X, то и "заскриптовать" это 
> будет возможно).

Кстати изготовление отдельного пакета libfoo_X в ряде случаев
нежелательно.  Потому что библиотеки libfoo_X и libfoo_Y могут оказаться
в одном адресном пространстве, что может быть фатальным.  Гипотетический
пример: библиотека libbar зависит от glib1, а библиотека libbaz зависит
от glib2.  Приложение, которое использует libbar и libbaz одновременно,
загружает в свое адресное пространство сразу glib1 и glib2.  Я не знаю,
насклько ELF/ld.so умеет или пытается разруливать такие ситуации, но в
общем-то ясно, что это может кончиться очень плохо.

> > Если для смены 
> > каждого сонейма формировать отдельный отстойник и коммитить его целиком
> > только тогда, когда проблема будет полностью решена, тогда возможны
> > новые проблемы.  Допустим приходит новый пакет, который зависит от двух
> > отстойников ("транзакций").  Вопрос такой: к какому отстойнку его
> > отнести?  Нужно уже формировать "объединение" двух отстойников.
> > Если развить мысль (исходя из того, что полная смена сонейма занимает
> > довольно долгое время), то "объединение" нескольких отстойников
> > в конечном счете даст один большой новый отстойник, который до конца
> > переместить в сизиф никогда не удатся.  То есть будет "затык" в
> > альтернативном сизифе, который никак не удается слить в основной сизиф.
> 
> Возможно "отстойник" стОит "залочить" от "внешего вмешательства", т.е. пока 
> транзакция не завершена, ничего увеличивающего энтропию в неё не добавлять.

Что значит залочить от внешнего вмешательства?  То есть допустим
сменился soname у libjpeg, и под это дело выделяется отдельный
отстойник, пока все пакеты не будут пересобраны с новым libjpeg.

Вновь посутпающие пакеты должны пересобираться в отстойнике или
на сизифе без отстойника?  Очевидно, в отстойнике, иначе не выполняется
требование завершения транзакции (все пакеты должны пересобраться с
новой библиотекой libjpeg).

Через месяц меняется soname у libssl.  Транзакция по libjpeg ещё не
завершена.  Нужно формировать новый отстойник для libssl, или вообще
зарубить libssl на том основании, что "отстойник залочен", т.е. в
отдельный момент времени нельзя допускать более одной тразакции по смене
сонейма?

Допустим, есть два отстойника (уже пересказываю) по libjpeg и libssl.
Теперь идёт пакет, который зависит одновременно от libjpeg и libssl.
В каком отстойнике собирать этот пакет?  Очевидно, что условие
завершения одной из транзакций будет нарушено.  Тогда нужно слить два
этих отстойника вместе и собирать этот пакет на объединенном отстойнике
libjpeg+libssl.  После этого условие завершения объединенной транзакции
становится гораздо сложнее.  Короче, слияние отстойников формирует
"параллельный сизиф", а транзакцию по объединенному отстойнику завершить
никогда не удается.

Так можно ли автоматически бороться с анметами (то есть существует ли
более тонкий автоматический критерий, чем просто давать reject пакетам,
которые увеличивают количество анметов)?

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

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

[Led]

В сообщении от 19 июня 2006 16:03 Alexey Tourbin написал(a):
> On Mon, Jun 19, 2006 at 03:26:26PM +0300, Led wrote:
> > > По существу не ясно, чем гарантируется смена сонейма в конечное время.
> > > То есть пункты 6, 7, 8 могут занять месяц, два, три...
> >
> > А это и есть пресловутый "человеческий фактор" - без него никак :( Чтоб
> > не было "месяц-два-три" и привёл пункт 6. Либо новая libfoo не
> > пропускается вобще, либо мэйнтейнеру нужно немножко озадачиться
> > изготовлением libfoo_X (думаю, если продумать policy на libfoo =>
> > libfoo_X, то и "заскриптовать" это будет возможно).
>
> Кстати изготовление отдельного пакета libfoo_X в ряде случаев
> нежелательно.  Потому что библиотеки libfoo_X и libfoo_Y могут оказаться
> в одном адресном пространстве, что может быть фатальным.  Гипотетический
> пример: библиотека libbar зависит от glib1, а библиотека libbaz зависит
> от glib2.  Приложение, которое использует libbar и libbaz одновременно,
> загружает в свое адресное пространство сразу glib1 и glib2.  Я не знаю,
> насклько ELF/ld.so умеет или пытается разруливать такие ситуации, но в
> общем-то ясно, что это может кончиться очень плохо.
>
> > > Если для смены
> > > каждого сонейма формировать отдельный отстойник и коммитить его целиком
> > > только тогда, когда проблема будет полностью решена, тогда возможны
> > > новые проблемы.  Допустим приходит новый пакет, который зависит от двух
> > > отстойников ("транзакций").  Вопрос такой: к какому отстойнку его
> > > отнести?  Нужно уже формировать "объединение" двух отстойников.
> > > Если развить мысль (исходя из того, что полная смена сонейма занимает
> > > довольно долгое время), то "объединение" нескольких отстойников
> > > в конечном счете даст один большой новый отстойник, который до конца
> > > переместить в сизиф никогда не удатся.  То есть будет "затык" в
> > > альтернативном сизифе, который никак не удается слить в основной сизиф.
> >
> > Возможно "отстойник" стОит "залочить" от "внешего вмешательства", т.е.
> > пока транзакция не завершена, ничего увеличивающего энтропию в неё не
> > добавлять.
>
> Что значит залочить от внешнего вмешательства?  То есть допустим
> сменился soname у libjpeg, и под это дело выделяется отдельный
> отстойник, пока все пакеты не будут пересобраны с новым libjpeg.
>
> Вновь посутпающие пакеты должны пересобираться в отстойнике или
> на сизифе без отстойника?  Очевидно, в отстойнике, иначе не выполняется
> требование завершения транзакции (все пакеты должны пересобраться с
> новой библиотекой libjpeg).
>
> Через месяц меняется soname у libssl.  Транзакция по libjpeg ещё не
> завершена.  Нужно формировать новый отстойник для libssl, или вообще
> зарубить libssl на том основании, что "отстойник залочен", т.е. в
> отдельный момент времени нельзя допускать более одной тразакции по смене
> сонейма?
>
> Допустим, есть два отстойника (уже пересказываю) по libjpeg и libssl.
> Теперь идёт пакет, который зависит одновременно от libjpeg и libssl.
> В каком отстойнике собирать этот пакет?  Очевидно, что условие
> завершения одной из транзакций будет нарушено.  Тогда нужно слить два
> этих отстойника вместе и собирать этот пакет на объединенном отстойнике
> libjpeg+libssl.  После этого условие завершения объединенной транзакции
> становится гораздо сложнее.  Короче, слияние отстойников формирует
> "параллельный сизиф", а транзакцию по объединенному отстойнику завершить
> никогда не удается.
>
> Так можно ли автоматически бороться с анметами (то есть существует ли
> более тонкий автоматический критерий, чем просто давать reject пакетам,
> которые увеличивают количество анметов)?

Ок, попробую объяснить по другому (вариант libfoo_X для упрощения пока не 
учитываю - он был приведён как временное решение, "костыль" для быстрейшего 
(надеюсь, только в некоторых случаях) завершения транзакции в 
случае "ленивости" мэйнтейнеров зависимых пакетов):
1) Термин "отстойник" и то, что вы в него вкладываете не совсем подходит
2) Предлагается термины "очередь" и "триггер".
3) libfoo с новым soname, поступающая в incoming (и, естественно, прошедшая 
сборку в хешере), устанавливает триггер, по которому все собранные уже с ней 
пакеты ставятся в очередь, триггер снимается и эти пакеты проходят в основной 
репозитарий только после прохождения в этот репозитрарий самой libfoo.
4) Если какой-либо пакет зависит (в момент поступления в incoming) от двух или 
нескольких библиотек, находящихся в "режиме ожидания", то в очереди он будет 
нходиться, естественно, до тех пор, пока остаётся хотя бы один относящийся к 
нему триггер.

Сорри, если немного путанно, но ИМХО это как раз тот случай, когда "показать 
на пальцах" или "на картошке" (как В.И.Чапаев) проще, чем описать словами:)

-- 
Led.

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

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 1665 bytes --]

* Alexey Tourbin <at@> [060619 17:03]:
> Так можно ли автоматически бороться с анметами (то есть существует ли
> более тонкий автоматический критерий, чем просто давать reject пакетам,
> которые увеличивают количество анметов)?
Ну вот такая идея мне в голову пришла:

Если пакет baz зависит от пакета libfoo, получаемого из исходного
пакета foobar, то пакет baz должен иметь сборочную зависимость на
пакет bar, тоже получаемый из исходного пакета foobar.  Примем
это за постулат.

((note: под это правило не попадают зависимости проставленные
вручную, зависимости на исполняемые файлы (/bin/ls -> coreutils)
и зависимости на модули (python, tcl, но попадает perl). ))

Пакет foobar, генерирующий libfoo у которого сменился SONAME
попадает в отстойник с именем FUBAR.  Далее мы имеем список
FUBAR-src с именами всех исходных пакетов и FUBAR-req-src с
именами исходных пакетов, предоставляющих сборочные зависимости
для FUBAR-src.

Для каждого нового пакета генерим список типа FUBAR-req-src и
если он пересекается с FUBAR-src, то помещаем этот пакет в
отстойник FUBAR.

Если этот новый пакет попадает в список FUBAR-req-src, то
обработка этого пакета блокируется до окончания обработки
отстойника.

Если ни то ни другое, пакет обрабатывается как обычно.


Что я в этой схеме не предусмотрел?  Например когда foo зависит
от libbar и libbaz, находящихся в разных отстойниках.  Есть
реальные примеры таких сочетаний пакетов?  Не раскрыто понятие
"как обычно".

Под "неувеличением количества unmet'ов" наверно лучше следует
понимать "недобавление новых unmet'ов", т.е. схема -2+1 под это
не попадает.

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 497 bytes --]

* Michael Shigorin <mike@> [060619 17:03]:
> > Допустим приходит новый пакет, который зависит от двух
> > отстойников ("транзакций").  Вопрос такой: к какому отстойнку
> > его отнести?
> Вот поэтому я и говорил пока про один RPMS.incoming.  А там,
> отдышавшись, городить далее.
Любое число между единицей и бесконечностью не имеет никакого
смысла, а бесконечно количество отстойников бесконечно
увеличивает энтропию.

P.S. Какая полезная вещь - отпуск ;-)

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Led]

В сообщении от 19 июня 2006 16:47 Alexey I. Froloff написал(a):
> * Michael Shigorin <mike@> [060619 17:03]:
> > > Допустим приходит новый пакет, который зависит от двух
> > > отстойников ("транзакций").  Вопрос такой: к какому отстойнку
> > > его отнести?
> >
> > Вот поэтому я и говорил пока про один RPMS.incoming.  А там,
> > отдышавшись, городить далее.
>
> Любое число между единицей и бесконечностью не имеет никакого
> смысла, а бесконечно количество отстойников бесконечно
> увеличивает энтропию.

ОтстойникИ не нужны. Один "отстойник" и в нём "очереди" и "триггеры". 
Фактически таким "отстойником" является сегодняшний Сизифус, осталось 
добавить в него очереди и триггеры:)

>
> P.S. Какая полезная вещь - отпуск ;-)

-- 
Led.

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

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 392 bytes --]

* Led <led@> [060619 18:07]:
> ОтстойникИ не нужны. Один "отстойник" и в нём "очереди" и "триггеры". 
> Фактически таким "отстойником" является сегодняшний Сизифус, осталось 
> добавить в него очереди и триггеры:)
Ты хочешь проверять пересобираемость пакета с новой библиотекой
заливкой этого пакета в инкаминг?  Это дороговато выходит.  И
очень небыстро.

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Michael Shigorin]

On Mon, Jun 19, 2006 at 01:34:49PM +0400, Alexey I. Froloff wrote:
> > Предлагался как по крайней мере big repo lock, который на
> > самом деле unlock по части unmets.
> Попытайся описать цикл работы с этим repo в виде пригодном к
> скриптованию.

0. исходное состояние: в этом repo пусто.
1. возникает надобность временно насоздавать unmets, о чём
   делается объявление в devel@ со списком задетых пакетов 
   и востребованных майнтейнеров (хорошо -- с уже известными
   типами проблем, характерными ошибками сборки/работы и совсем
   идеально -- с рекомендациями по исправлению таковых).
2. корневая причина (e.g. libA новой версии) вливается в пусть
   /incoming/Sisyphus/sandbox/; туда же заливаются по мере
   подготовки пакеты, которые требуют пересборки с новой libA,
   майнтейнерами по мере исправления и роботами по мере
   подтверждения успеха (?)
3. идут оперативные автоматические пересборки этого repo с ним
   самим включительно (это было ключевым, когда incoming
   запускался на обработку вручную раз в сутки; сейчас может
   быть проще ввесить отдельную разгребалку, поскольку по факту
   она уже создана -- так, Лёш?); логи "как сейчас сделано для
   Sisyphus" рассылаются так же.
4. когда список исходных пакетов, который был выделен по
   результатам тестовой пересборки или спрогнозирован по пакетным
   зависимостям на уходящий soname или иной признак, совпадает
   со списком в песочнице+orphaned полностью (что определяемо
   автоматически?) или в достаточной мере, определяемой incoming@
   -- происходит перекладывание пакетов в Sisyphus, очистка
   sandbox/ и объявляется техническая возможность для следующего
   переворота.
5. init 0 ;-)

Здесь есть несколько мест, которые мне с моими знаниями о
технической стороне текущей организации не нравятся или непонятны
(2 legion: нет, не добрался почитать); плюс временные рамки на
существование такого переездного репозитория тоже чем-то надо
ограничить (месяцем? -- за сколько у нас более-менее исправляются
крупные разломы?).

Вот ещё по теме:
http://lists.altlinux.org/pipermail/devel/2004-October/014806.html
http://lists.altlinux.org/pipermail/sisyphus/2004-January/034511.html
http://lists.altlinux.org/pipermail/devel/2005-October/025144.html
http://lists.altlinux.org/pipermail/devel/2006-March/030521.html

Также под руку попалось:
http://lists.altlinux.org/pipermail/devel/2005-April/019638.html
http://lists.altlinux.org/pipermail/devel/2004-October/014815.html
http://lists.altlinux.org/pipermail/sisyphus/2004-January/034675.html

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Lnux.Kiev http://www.linux.kiev.ua/

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

[Led]

В сообщении от 19 июня 2006 17:09 Alexey I. Froloff написал(a):
> * Led <led@> [060619 18:07]:
> > ОтстойникИ не нужны. Один "отстойник" и в нём "очереди" и "триггеры".
> > Фактически таким "отстойником" является сегодняшний Сизифус, осталось
> > добавить в него очереди и триггеры:)
>
> Ты хочешь проверять пересобираемость пакета с новой библиотекой
> заливкой этого пакета в инкаминг?

Ммм... честно говоря, не совсем понял о чём речь... Вроде бы разговор шёл пока 
только об избалении от unmet'ов. или я что-то пропустил?

> Это дороговато выходит.  И 
> очень небыстро.

-- 
Led.

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

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 738 bytes --]

* Led <led@> [060619 18:19]:
> > > ОтстойникИ не нужны. Один "отстойник" и в нём "очереди" и "триггеры".
> > > Фактически таким "отстойником" является сегодняшний Сизифус, осталось
> > > добавить в него очереди и триггеры:)
> > Ты хочешь проверять пересобираемость пакета с новой библиотекой
> > заливкой этого пакета в инкаминг?
> Ммм... честно говоря, не совсем понял о чём речь... Вроде бы разговор шёл пока 
> только об избалении от unmet'ов. или я что-то пропустил?
Как мне, простому мантейнеру foo, получить доступ к "очереди",
где лежит новая libbar, чтобы проверить что мой пакет с ней
соберётся?  Пересобирать у себя libbar?  Выкладывать foo как есть
и ловить сообщения об ошибке сборки?

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Led]

В сообщении от 19 июня 2006 17:22 Alexey I. Froloff написал(a):
> * Led <led@> [060619 18:19]:
> > > > ОтстойникИ не нужны. Один "отстойник" и в нём "очереди" и "триггеры".
> > > > Фактически таким "отстойником" является сегодняшний Сизифус, осталось
> > > > добавить в него очереди и триггеры:)
> > >
> > > Ты хочешь проверять пересобираемость пакета с новой библиотекой
> > > заливкой этого пакета в инкаминг?
> >
> > Ммм... честно говоря, не совсем понял о чём речь... Вроде бы разговор шёл
> > пока только об избалении от unmet'ов. или я что-то пропустил?
>
> Как мне, простому мантейнеру foo, получить доступ к "очереди",
> где лежит новая libbar, чтобы проверить что мой пакет с ней
> соберётся?

Точно так же, как вы сейчас получаете доступ к Sisyphus. Я всего лишь 
предлагаю "прикрутить" очереди и триггеры к Сизифу (для чего - уже устал 
повторять:))

> Пересобирать у себя libbar?  Выкладывать foo как есть 
> и ловить сообщения об ошибке сборки?

-- 
Led.

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

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2400 bytes --]

On Mon, Jun 19, 2006 at 04:44:35PM +0300, Led wrote:
> Ок, попробую объяснить по другому (вариант libfoo_X для упрощения пока не 
> учитываю - он был приведён как временное решение, "костыль" для быстрейшего 
> (надеюсь, только в некоторых случаях) завершения транзакции в 
> случае "ленивости" мэйнтейнеров зависимых пакетов):
> 1) Термин "отстойник" и то, что вы в него вкладываете не совсем подходит
> 2) Предлагается термины "очередь" и "триггер".
> 3) libfoo с новым soname, поступающая в incoming (и, естественно, прошедшая 
> сборку в хешере), устанавливает триггер, по которому все собранные уже с ней 
> пакеты ставятся в очередь, триггер снимается и эти пакеты проходят в основной 
> репозитарий только после прохождения в этот репозитрарий самой libfoo.
> 4) Если какой-либо пакет зависит (в момент поступления в incoming) от двух или 
> нескольких библиотек, находящихся в "режиме ожидания", то в очереди он будет 
> нходиться, естественно, до тех пор, пока остаётся хотя бы один относящийся к 
> нему триггер.

Зачем тогда нужен триггер?  Если отстойник всего один, тогда задача
сводится вот к чему: все входящие пакеты собираются в отстойнике (если
сборка не удается, пакет получает reject).  Из всех пакетов в отстойнике
нужно выделить максимальное подмножество этих пакетов, которое, будучи
перемещенных из отстойника в основной сизиф, не увеличивает в основном
сизифе количество анметов (и/или не ухудшает других характеристик).

Тогда возникает только вычислительная проблема.  Придется анализировать
т.н. power set отстойника (т.е. всевозможные подмножества, которые можно
составить из пакетов в отстойнике).  Т.е. если в отстойнике находится 10
пакетов, то в поисках максимального "хорошего" подмножества пакетов
придется анализировать 2^{10} = 1024 подмножества (включая полное и
пустое).  Если же в отстойнике 100 пакетов, то имеем порядка 10^{30}
вариантов, и задачу в строгом смысле вряд ли удастся решить.  Есть
конечно градиентные методы и всякая прочая хрень...

Есть ещё более тонкая проблема косвенной интерференции пакетов между
сизифом и отстойником.  Пакет собирается в среде отстойника, а
перемещается в сизиф, где может уже не собраться (или собраться с
отличным результатом).  Более сильным критерием может стать
дополнительный запрет на перемещение пакета в сизиф, если при сборке
он зацепил хотя бы один пакет из отстойника.

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

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

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1868 bytes --]

On Mon, Jun 19, 2006 at 05:45:43PM +0400, Alexey I. Froloff wrote:
> Если пакет baz зависит от пакета libfoo, получаемого из исходного
> пакета foobar, то пакет baz должен иметь сборочную зависимость на
> пакет bar, тоже получаемый из исходного пакета foobar.  Примем
> это за постулат.

Не обязательно.

> ((note: под это правило не попадают зависимости проставленные
> вручную, зависимости на исполняемые файлы (/bin/ls -> coreutils)
> и зависимости на модули (python, tcl, но попадает perl). ))
> 
> Пакет foobar, генерирующий libfoo у которого сменился SONAME
> попадает в отстойник с именем FUBAR.  Далее мы имеем список
> FUBAR-src с именами всех исходных пакетов и FUBAR-req-src с
> именами исходных пакетов, предоставляющих сборочные зависимости
> для FUBAR-src.
> 
> Для каждого нового пакета генерим список типа FUBAR-req-src и
> если он пересекается с FUBAR-src, то помещаем этот пакет в
> отстойник FUBAR.
> 
> Если этот новый пакет попадает в список FUBAR-req-src, то
> обработка этого пакета блокируется до окончания обработки
> отстойника.
> 
> Если ни то ни другое, пакет обрабатывается как обычно.
> 
> 
> Что я в этой схеме не предусмотрел?  Например когда foo зависит
> от libbar и libbaz, находящихся в разных отстойниках.  Есть
> реальные примеры таких сочетаний пакетов?  Не раскрыто понятие
> "как обычно".
> 
> Под "неувеличением количества unmet'ов" наверно лучше следует
> понимать "недобавление новых unmet'ов", т.е. схема -2+1 под это
> не попадает.

Достаточно попробовать сделать initroot + полная установка сборочных
зависимостей вновь пришедшего пакета на каждом из отстойников.
Хешер напишет список пакетов, который он ставит в сборочную среду.
Если среди этого списка есть пересечение с пакетами из отстойника,
то пакет прописывается в отстойник. :)

В общем довольно сложно получается...

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

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

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 444 bytes --]

On Mon, Jun 19, 2006 at 07:26:00PM +0400, Alexey Tourbin wrote:
> Достаточно попробовать сделать initroot + полная установка сборочных
> зависимостей вновь пришедшего пакета на каждом из отстойников.
> Хешер напишет список пакетов, который он ставит в сборочную среду.
> Если среди этого списка есть пересечение с пакетами из отстойника,
> то пакет прописывается в отстойник. :)

Вписывается.

> В общем довольно сложно получается...

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

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

[Alexey Rusakov]

Anton Farygin пишет:
> Так проблема ещё актуальна ?
>   
Уже нет, сегодня исправленный nautilus добрался-таки до Сизифа. Теперь 
нужно точно таким же образом протолкнуть исправленный file-roller, 
увязший в incoming по той же причине.

-- 
  Alexey "Ktirf" Rusakov

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

[Денис Смирнов]

On Mon, Jun 19, 2006 at 12:03:34PM +0300, Michael Shigorin wrote:

MS> Мне кажется, что это вполне параллельно sisyphus/stable/distros,
MS> если под stable понимать то, о чём Гоша говорил "под декабрь".

Миша, посмотри на FreeBSD. Одним из моих вывдов с последнего чаепития на
Волхонке было то, что release engineering надо внимательно посмотреть
именно у них. Это особенно актуально в связи с плавным переходом на jit.

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

http://freesource.info
----------------------------------------------------------------------------
 * Vitls сегодня отмечает 3-х ление участия в проекте Linux Ru Net 

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

[Денис Смирнов]

On Mon, Jun 19, 2006 at 07:18:02PM +0400, Алексей Турбин wrote:

AT> Тогда возникает только вычислительная проблема.  Придется анализировать
AT> т.н. power set отстойника (т.е. всевозможные подмножества, которые можно
AT> составить из пакетов в отстойнике).  Т.е. если в отстойнике находится 10
AT> пакетов, то в поисках максимального "хорошего" подмножества пакетов
AT> придется анализировать 2^{10} = 1024 подмножества (включая полное и
AT> пустое).  Если же в отстойнике 100 пакетов, то имеем порядка 10^{30}
AT> вариантов, и задачу в строгом смысле вряд ли удастся решить.  Есть
AT> конечно градиентные методы и всякая прочая хрень...

Эта задача решается куда проще. При условии что у нас есть алгоритм,
который по группе пакетов дает четкий ответ есть там unmet'ы или нет. И
если есть, то какой пакет не устанавливается, и каких provides ему не
хватает. Ну и, разумеется, есть информация по requires/provides всех
пакетов.

Берем пакет. Если unmet'ов нет -- сразу переносим. Если unmet'ы есть, то
смотрим какие из пакетов во временном репозитории имеют соответствующие
provides, повторяя этот процесс рекурсивно до получения либо группы
пакетов, которые можно установить, либо информации о том, что этот пакет
нельзя установить вообще.

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

http://freesource.info
----------------------------------------------------------------------------
плохо закрыл - вот теперь закрываю :)
		-- lav in #575

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

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2077 bytes --]

On Tue, Jun 20, 2006 at 08:11:47PM +0400, Денис Смирнов wrote:
> AT> Тогда возникает только вычислительная проблема.  Придется анализировать
> AT> т.н. power set отстойника (т.е. всевозможные подмножества, которые можно
> AT> составить из пакетов в отстойнике).  Т.е. если в отстойнике находится 10
> AT> пакетов, то в поисках максимального "хорошего" подмножества пакетов
> AT> придется анализировать 2^{10} = 1024 подмножества (включая полное и
> AT> пустое).  Если же в отстойнике 100 пакетов, то имеем порядка 10^{30}
> AT> вариантов, и задачу в строгом смысле вряд ли удастся решить.  Есть
> AT> конечно градиентные методы и всякая прочая хрень...
> 
> Эта задача решается куда проще. При условии что у нас есть алгоритм,
> который по группе пакетов дает четкий ответ есть там unmet'ы или нет. И
> если есть, то какой пакет не устанавливается, и каких provides ему не
> хватает. Ну и, разумеется, есть информация по requires/provides всех
> пакетов.

Есть только предикат, который для данной группы (точнее, подмножества;
слово группа здесь лучше не произносить) дает однозначный ответ:
появились новые анметы или нет.

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

Если исходить только из предиката, то получается экспоненциально трудная
задача -- найти максимальное подмножество, удовлетворяющее критерию.
То есть перебор подмножеств B(U) aka булеан aka power set.

> Берем пакет. Если unmet'ов нет -- сразу переносим. Если unmet'ы есть, то
> смотрим какие из пакетов во временном репозитории имеют соответствующие
> provides, повторяя этот процесс рекурсивно до получения либо группы
> пакетов, которые можно установить, либо информации о том, что этот пакет
> нельзя установить вообще.

Я склоняюсь к тому, что автоматически ничего волшебно-простого сделать
нельзя.  Сказывается также отсутствие постановки задачи.  Так может быть
стоит посмотреть примеры анметов за последний год...

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

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

[Денис Смирнов]

On Wed, Jun 21, 2006 at 06:40:31AM +0400, Алексей Турбин wrote:

AT> Есть только предикат, который для данной группы (точнее, подмножества;
AT> слово группа здесь лучше не произносить) дает однозначный ответ:
AT> появились новые анметы или нет.
AT> Предикат не может дать ответ, какой пакет "виноват" в том, что появились
AT> новые анметы.  В общем случае это нетривиальная задача.  Есть некоторые
AT> соображения и на эту тему, могу вербализовать.

Это было бы очень хорошо.

AT> Если исходить только из предиката, то получается экспоненциально трудная
AT> задача -- найти максимальное подмножество, удовлетворяющее критерию.
AT> То есть перебор подмножеств B(U) aka булеан aka power set.

Я не ставлю такой задачи. Достаточно решения задачи найти произвольное
подмножество, содержащее конкретный пакет.

>> Берем пакет. Если unmet'ов нет -- сразу переносим. Если unmet'ы есть, то
>> смотрим какие из пакетов во временном репозитории имеют соответствующие
>> provides, повторяя этот процесс рекурсивно до получения либо группы
>> пакетов, которые можно установить, либо информации о том, что этот пакет
>> нельзя установить вообще.
AT> Я склоняюсь к тому, что автоматически ничего волшебно-простого сделать
AT> нельзя.  Сказывается также отсутствие постановки задачи.  Так может быть
AT> стоит посмотреть примеры анметов за последний год...

Дашь скриптик, могу прогнать его на истории за год.

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

http://freesource.info
----------------------------------------------------------------------------
*** Bug 3334 has been marked as a duplicate of this bug. ***
		-- mouse in #4443

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

[Michael Shigorin]

On Tue, Jun 20, 2006 at 07:59:30PM +0400, Денис Смирнов wrote:
> MS> Мне кажется, что это вполне параллельно sisyphus/stable/distros,
> MS> если под stable понимать то, о чём Гоша говорил "под декабрь".
> Миша, посмотри на FreeBSD. Одним из моих вывдов с последнего
> чаепития на Волхонке было то, что release engineering надо
> внимательно посмотреть именно у них. Это особенно актуально в
> связи с плавным переходом на jit.

В смысле по basesystem?  Не уверен, что смасштабируется.
Хотя поспрошать надо будет.

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

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

[Денис Смирнов]

On Wed, Jun 21, 2006 at 11:42:16AM +0300, Michael Shigorin wrote:

MS> В смысле по basesystem?  Не уверен, что смасштабируется.
MS> Хотя поспрошать надо будет.

По крайней мере git существенно облегчит мантейнером обслуживание разных
версий пакетов в разных branch'ах.

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

http://freesource.info
----------------------------------------------------------------------------
> alias char-major-10-134 fglrx
сурово. Это надо в фортунки ;)
		-- lakostis in community@

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

[Fr. Br. George]

On Wed, Jun 21, 2006 at 11:42:16AM +0300, Michael Shigorin wrote:
> On Tue, Jun 20, 2006 at 07:59:30PM +0400, Денис Смирнов wrote:
> > MS> Мне кажется, что это вполне параллельно sisyphus/stable/distros,
> > MS> если под stable понимать то, о чём Гоша говорил "под декабрь".
> > Миша, посмотри на FreeBSD. Одним из моих вывдов с последнего
> > чаепития на Волхонке было то, что release engineering надо
> > внимательно посмотреть именно у них. Это особенно актуально в
> > связи с плавным переходом на jit.
> 
> В смысле по basesystem?  Не уверен, что смасштабируется.
> Хотя поспрошать надо будет.
Не только basesystem; разумеется, и база портов тоже. Особенность
FreeBSD -- в том, что basesystem они уделяют как можно больше внимания,
а ports base остаётся полностью на совести community. В нашем случае
больше свободы, но больше и разброса: помимо community имеются
заинтересованные в Сизифе организации (например, ALT), которые могут
использовать свои ресурсы для повышения внимания к той части
репозитория, которая им нужна. Это и будет подобие basesystem -- менее
строгое, но зато более гибкое.

-- 
			George V Kouryachy (aka Fr. Br. George)
			mailto:george at altlinux_ru

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

[Michael Shigorin]

On Thu, Jun 22, 2006 at 02:48:17PM +0400, Fr. Br. George wrote:
> > > Миша, посмотри на FreeBSD. Одним из моих вывдов с последнего
> > В смысле по basesystem?  Не уверен, что смасштабируется.
> > Хотя поспрошать надо будет.
> Не только basesystem; разумеется, и база портов тоже.
> Особенность FreeBSD -- в том, что basesystem они уделяют как
> можно больше внимания, а ports base остаётся полностью на
> совести community.

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

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

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

> В нашем случае больше свободы, но больше и разброса: помимо
> community имеются заинтересованные в Сизифе организации
> (например, ALT), которые могут использовать свои ресурсы для
> повышения внимания к той части репозитория, которая им нужна.
> Это и будет подобие basesystem -- менее строгое, но зато более
> гибкое.

Боюсь, даже Owl больше, чем FreeBSD basesystem.  Потому и 
сказал про масштабируемость.  Гентушники вон эту проблему тоже
то ли не видели, то ли решили, что бранчи портов им поддерживать
как сообществу дороговато и ненужновато.  Потому они тоже -- не
серверная ОС, за поддержку которой я как контора могу взяться.

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

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

[Igor Zubkov]

[-- Attachment #1: Type: text/plain, Size: 1820 bytes --]

В сообщении от 22 июня 2006 16:08 Michael Shigorin написал(a):
> On Thu, Jun 22, 2006 at 02:48:17PM +0400, Fr. Br. George wrote:
> > > > Миша, посмотри на FreeBSD. Одним из моих вывдов с последнего
> > >
> > > В смысле по basesystem?  Не уверен, что смасштабируется.
> > > Хотя поспрошать надо будет.
> >
> > Не только basesystem; разумеется, и база портов тоже.
> > Особенность FreeBSD -- в том, что basesystem они уделяют как
> > можно больше внимания, а ports base остаётся полностью на
> > совести community.
>
> Угу, и потом ловить клинья, как прошлым летом дырявый apache2
> и разломанная сборка с починенным -- mod_perl2.

И что там такого было?

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

Да. Они не бранчатся. А зачем?

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

И какие у неё признаки не сервантной ОС?

> > В нашем случае больше свободы, но больше и разброса: помимо
> > community имеются заинтересованные в Сизифе организации
> > (например, ALT), которые могут использовать свои ресурсы для
> > повышения внимания к той части репозитория, которая им нужна.
> > Это и будет подобие basesystem -- менее строгое, но зато более
> > гибкое.
>
> Боюсь, даже Owl больше, чем FreeBSD basesystem.  Потому и
> сказал про масштабируемость.  

> Гентушники вон эту проблему тоже 
> то ли не видели, то ли решили, что бранчи портов им поддерживать
> как сообществу дороговато и ненужновато.  Потому они тоже -- не
> серверная ОС, за поддержку которой я как контора могу взяться.

А я вот генту ставлю сейчас. Устал я от разломаного в репозитории kde...

-- 
Placebo - Peeping Tom

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Fr. Br. George]

On Thu, Jun 22, 2006 at 04:08:36PM +0300, Michael Shigorin wrote:
> Порты -- это поделка, которая фундаментально не годится для ОС,
> за поддержку которуй можно отвечать.  Они не бранчатся.  Вообще.
Фи. Если бы не были знакомы лично, заподозрил бы агрессивную
неграмотность.

> Я фрю за серверную операционку уже по двум клиническим признакам
> не считаю, и это сугубо технически, а не эмоционально (впрочем,
> того уже хватало, чтобы не связываться с этим проектом).
Миша, а я 12 лет её эксплуатирую и как production сервер-ы, и как
desktop. Поторопился я с предыдущим утверждением. Всё-таки это с твоей
стороны именно агрессивная неграмотность. Ты, видимо, просто не в теме, и
пыл твой представляется чисто религиозным, что печально.

>  Гентушники вон эту проблему тоже
> то ли не видели, то ли решили, что бранчи портов им поддерживать
> как сообществу дороговато и ненужновато.  Потому они тоже -- не
> серверная ОС, за поддержку которой я как контора могу взяться.
Они "тоже" не серверная ОС по той же причине, что и Сизиф -- не
серверная ОС. Gentoo -- это такой живущий репозиторий. Без зачёса на
Gentoo-based профильные дистрибутивы. Ну так никто и не хочет объять
необъятное.

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

-- 
			George V Kouryachy (aka Fr. Br. George)
			mailto:george at altlinux_ru

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

[Michael Shigorin]

PreScriptum: это я к тому, куда стоит ходить за примерами
и про что проще сразу забыть.

On Thu, Jun 22, 2006 at 04:44:30PM +0300, Igor Zubkov wrote:
> > > > > Миша, посмотри на FreeBSD. Одним из моих вывдов с последнего
> > > > В смысле по basesystem?  Не уверен, что смасштабируется.
> > > > Хотя поспрошать надо будет.
> > > Не только basesystem; разумеется, и база портов тоже.
> > > Особенность FreeBSD -- в том, что basesystem они уделяют как
> > > можно больше внимания, а ports base остаётся полностью на
> > > совести community.
> > Угу, и потом ловить клинья, как прошлым летом дырявый apache2
> > и разломанная сборка с починенным -- mod_perl2.
> И что там такого было?

Съезд API в округе исправленной дырки, которую стоило фиксить.

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

Затем, чтобы получалось на развёрнутых системах отделываться
минимальными изменениями.  Это денег может стоить, а вот
"соберите из cvs" может стоить грубостей...

> > Я фрю за серверную операционку уже по двум клиническим
> > признакам не считаю, и это сугубо технически, а не
> > эмоционально (впрочем, того уже хватало, чтобы не связываться
> > с этим проектом).
> И какие у неё признаки не сервантной ОС?

Отсутствие бранчей большинства серверных пакетов и то, что по
части поддержки оно *сейчас* напоминает линукс даже не
десятилетней давности -- "с пашпилем на танки":

http://tinyurl.com/j7nhf

(что-то ещё было фундаментального, сейчас не вспомню)

> А я вот генту ставлю сейчас.

Ну ставь, мне-то что.

> Устал я от разломаного в репозитории kde...

Хихикс :]

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

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

[Michael Shigorin]

On Thu, Jun 22, 2006 at 06:39:44PM +0400, Fr. Br. George wrote:
> > Порты -- это поделка, которая фундаментально не годится для ОС,
> > за поддержку которуй можно отвечать.  Они не бранчатся.  Вообще.
> Фи. Если бы не были знакомы лично, заподозрил бы агрессивную
> неграмотность.

Это мне рассказал один из пострадавших коммиттеров, который потом
потратил время на попытки найти способ исправить этот design bug,
поскольку хостинг был под угрозой и попадать на такое ещё уже не
хотелось.  В обратном как-то кто-то из юзеров пытался убедить,
даже не помню кто.

Короче, вот уж куда смысла смотреть по части _инфраструктуры_
именно что не вижу.

[почтой ответил на остальное]

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

[devel] debian query language (was: Стабильный Сизиф)

[Michael Shigorin]

On Sat, Jun 17, 2006 at 04:33:13PM +0400, Alexey Tourbin wrote:
> Я предлагаю обсуждать более алгоритмические идеи.

(abusing the thread)  Кстати, попалось тут на глаза:

---

Debian Query Language. Berke Durak from the French National
[7]Institute for Research in Computer Science and Control is
[8]seeking feedback and ideas for defining a query language that
would be useful to maintainers, power-users and researchers. They have
already developed a [9]dependency checker based on boolean form.
Tools for handling the Debian meta data with its evolution in time are
also being implemented.

 7. http://www.inria.fr/
 8. http://lists.debian.org/debian-devel/2006/05/msg01912.html
 9. http://bugs.debian.org/365087
---

Есть соображение, что роботов и особенно результаты их работы
хорошо бы не клонировать/дублировать, а сопрягать.

-- 
PS: единственный старый ламер-дантист,
к которому меня угораздило попасть
в лапы, имел фамилию Криворук...
но тогда это предупреждение
было проигнорировано.

Re: [devel] debian query language (was: Стабильный Сизиф)

[Michael Shigorin]

On Wed, Jun 28, 2006 at 08:47:48AM +0300, I wrote:
> > Я предлагаю обсуждать более алгоритмические идеи.
> (abusing the thread)  Кстати, попалось тут на глаза:

И ещё оттуда же (http://lwn.net/Articles/189364/):

http://packages.debian.org/unstable/devel/edos-rpmcheck
edos-rpmcheck -- Checks whether dependencies of Red Hat packages
can be satisfied.

http://packages.debian.org/unstable/devel/mock
mock -- Build RPM packages inside a chroot.

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

Re: [devel] debian query language (was: Стабильный Сизиф)

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 836 bytes --]

On Wed, Jun 28, 2006 at 09:05:10AM +0300, Michael Shigorin wrote:
> http://packages.debian.org/unstable/devel/edos-rpmcheck
> edos-rpmcheck -- Checks whether dependencies of Red Hat packages
> can be satisfied.

+.SH OPTIONS                                                                                                                                 
+.TP                                                                                                                                         
+.B -check                                                                                                                                   
+Double-check the results                                                                                                                    

Гы-гы.  Я не верю судьбе а себе ещё меньше.

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

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

[Fr. Br. George]

On Thu, Jun 22, 2006 at 06:07:49PM +0300, Michael Shigorin wrote:
> On Thu, Jun 22, 2006 at 06:39:44PM +0400, Fr. Br. George wrote:
> > > Порты -- это поделка, которая фундаментально не годится для ОС,
> > > за поддержку которуй можно отвечать.  Они не бранчатся.  Вообще.
> > Фи. Если бы не были знакомы лично, заподозрил бы агрессивную
> > неграмотность.
> Это мне рассказал один из пострадавших
Вот именно. А один из непострадавших рассказывал мне про дистанционное
обновление FreeBSD4 -> FreeBSD5 на сервисе 24/7 с временем простоя =
временеи загрузки. Не разговор.

-- 
			George V Kouryachy (aka Fr. Br. George)
			mailto:george at altlinux_ru

Re: [devel] [OT] (не)серверные ОС

[Michael Shigorin]

On Wed, Jun 28, 2006 at 06:37:47PM +0400, Fr. Br. George wrote:
> > > > Порты -- это поделка, которая фундаментально не годится
> > > > для ОС, за поддержку которуй можно отвечать.  Они не
> > > > бранчатся.  Вообще.
> > > Фи. Если бы не были знакомы лично, заподозрил бы
> > > агрессивную неграмотность.
> > Это мне рассказал один из пострадавших
> Вот именно. А один из непострадавших рассказывал мне про
> дистанционное обновление FreeBSD4 -> FreeBSD5 на сервисе 24/7 с
> временем простоя = временеи загрузки. Не разговор.

Я тут на днях высказывал (по совершенно другой ситуации) сестре,
что дурак интересуется, у кого вышло без проблем, а умный --
какие возникли.

Без рассказов -- переводил сервер, у которого практически каждое
моргание eth0 означало денюжку ($1--2), с RH7.3 на ALM2.2.  
Даунтайм был тоже порядка минут.  Это тоже ничего не значит.

Рекомендовать использовать Windows 95 на гейтвее я точно так же
не могу.  Хотя и таких гениев только сам повидал немало.


Гош, давай на фесте.  Мож Антон вон молодость повспоминает,
да ещё кто. ;)

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

Re: [devel] [OT] ( не ) серверные ОС

[Epiphanov Sergei]

В сообщении от Wednesday 28 June 2006 23:20 Michael Shigorin написал(a):
> Рекомендовать использовать Windows 95 на гейтвее я точно так жене могу.
>  Хотя и таких гениев только сам повидал немало.

У нас на работе такое было. Хорошо, что это не внешний, а внутрирабочий 
(отделял нашу собственную сеть от общеинститутской).

-- 
С уважением, Епифанов Сергей