On Wed, Aug 26, 2009 at 11:52:32AM +0400, Boris Savelev wrote:
> 26 августа 2009 г. 11:46 пользователь Alexey Tourbin (at@altlinux.ru) написал:
> > On Wed, Aug 26, 2009 at 11:36:37AM +0400, Boris Savelev wrote:
> >> 26 августа 2009 г. 11:27 пользователь Alexey Tourbin (at@altlinux.ru) написал:
> >> > On Wed, Aug 26, 2009 at 10:07:08AM +0400, Boris Savelev wrote:
> >> >> Может этот вопрос уже обсуждался и я отвечаю не по делу и не туда, тем не менее.
> >> >> Почему у нас бранчи не как в дебиане? Почему при сборке пакета в
> >> >> бранч, он попадает именно в репозиторий бранча, а не в спец.
> >> >> репозиторий с апдейтами к этому бранчу? Обновляю напрямую репозиторий
> >> >> бранча, можно сломать все что угодно и не добиться стабильности во
> >> >> веки веков. Ведь бранч для того и делается чтобы быть всегда
> >> >> стабильным и замороженным. А для secutiry и пр. фиксов есть репо с
> >> >> апдейтами для бранча.
> >> >
> >> > Потому что у нас принята такая фигня что в репозитории не должно быть
> >> > дупов.  А если делать repo+updates то появляются дупы, у тогда уже
> >> > например невозможно правильно проверить анметы!  Очень легко
> >> > сконструировать случай когда дупы маскируют анметы:
> >> >
> >> > A -> dep1 -> B_1
> >> > A -> dep2 -> B_2
> >> >
> >> > (то есть часть зависимостей пакета A разрешаются в пакет B
> >> > устаревшей версии).
> >
> > Более конкретный пример -- изменение сонейма без изменения названия
> > пакета с библиотекой.  Анметы проверять смысла нет -- два одноименных
> > пакета разных версий предоставляют разные сонеймы.  Но эти два пакета
> > нельзя установить одновременно.
> такое недопустимо в _бранче_

Такое недопустимо в целостном репозитории вообще.  Поэтому в целостном
репозитории не должно быть дупов (потому что дупы нельзя установить
одновременно, но при этом они могут разрешать разные зависимости).
А связка repo+updates подразумевает дупы по определению.

Как мы собираемся проверять что то что залили в updates годится?
Нужно сделать "срез" репозитария repo+updates, исключив дупы, и
проверять целостность этого среза.  Это примерно то что делать сборочная
система.

В апте тоже есть понятие пакета-кандидата, которое отчасти аналогично
понятию среза репозитория.  Маркером "кандидата" отмечаются пакеты
наиболее свежих версий, и аптовские алгоритмы работают на срезе
"кандидатов".  Иначе апт заклинит на дупах.  Но кандидаты решают
не все проблемы.  Если подключить два репозитория то апт скорее всего
заколбасит.

В принципе конечно можно делать updates, но какими-то другими средствами.

> > , более консервативные бранчи/стеки
> это как? можно как-то раскрыть эту фразу? почему в альте этого нет?-)

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