[sisyphus] [POLICY] Sisyphus

[info]

26 Январь 2004 15:43, Вы написали:
> info пишет:
> >>А в том что было [dd] вы не учли одну немаловажную вещь:
> >>мейнтейнер пакета XXXX, может не пользоваться YYY-WM (у
> >> меня например только 2 wm стоит один для меня другой для
> >> семьи, у кого-то может вообще быть один или не одного), и
> >> тогда ваша теория оказывается не работоспособной.
> >
> > Снова не поняли... Мы говорим не о конкретных случаях,
> > которых может быть до... Мы о том, что ритм обновлений
> > Сизифуса должен позволять _любому_ упаковщику:
> > 1. Обновить свою машину в _любом_ необходимом ему объеме;
>
> Как, кроме как через интер-/флоппи- NET мейнтейнер сможет это
> сделать?

Я имел в виду - "дать время, необходимое для обновления в любом 
необходимом объеме"

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

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

>
> > 3.  Проверить собранное.
>
> 100% согласен, с одной маленькой поправкой (...в доступных
> условиях)

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

>
> > Но в противовес Вашему примеру - что, мол, есть пакеты, для
> > сборки которых не нужны большие обновления - я вам отвечаю:
> > а есть такие, для которых нужны... И ритм обновлений
> > Сизифуса должен позволять в обоих этих случаях работать
> > нормально. В
>
> Я до сих пор не могу понять, а почему этот ритм не позволяет
> обновлений? Мы же говорим не про конкретный случай, да?

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

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

Результат: пакет собирался в одном окружении, а когда он попал в 
сизифус - там может быть уже другое.  Это потенциальный 
источник ошибок.


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

Панацея есть недостижимый идеал; единый универсальный инструмент 
(как и единый универсальный дистрибутив, кстати) - тоже. Важно 
соблюдать меру: при проектировании любого toolkit ~ 80% случаев 
покрываются by general instrument, еще 15-18% разного рода 
специализированными инструментами для "особых случаев", и для ~ 
2-5% допустим совсем уж индивидуальный подход, решаемый на 
квалификации специалистов.