[devel] копировать нельзя отменить

[Alexey Borovskoy]

* Воскресенье 03 мая 2009 Dmitry V. Levin

> On Sun, May 03, 2009 at 12:48:07AM +0400, Wartan Hachaturow 
wrote:
> > 2009/5/2 Dmitry V. Levin <ldv@>:
> > > Это всё слова.  Попробуй расписать в деталях, как это
> > > будет работать.
> >
> > Ну, в принципе, всё довольно очевидно.
>
> Это только в принципе очевидно, а не в деталях.
>
> > Общая схема такая: вначале есть Сизиф. Сизиф целиком в
> > некоторый момент бранчуется, и этот бранч называется словом
> > "testing". Дальше основная разработка происходит в Сизифе,
>
> До этого момента всё ещё очевидно.
>
> > пакеты же автоматически
> > мигрируют в testing. Критерии миграции для Debian описаны
> > тут: http://www.debian.org/devel/testing
> > Их можно адаптировать с учётом меньшего user base.
>
> А вот тут и начинаются те самые детали.

У нас есть git.alt. Который отлавливает наиболее распространенные 
ошибки и разломы репо.

> Например, как на практике трактовать п.5,
> The operation of installing the package into "testing" must
> not break any packages currently in "testing".
> Как правильно определить, что такое "break"?

break -- невозможность дистапгрейда. тоесть новый пакет дает 
несовместимость по зависмостям.

Если стейбл собирается гит.альтом, то у него нету анмитов в 
пределах стейбла.

Если анстейбл собирается гит.альтом, то у него нету анмитов в 
пределах стейбла.

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

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

Перенос и пересборка требуют тестовой пересбоки всего стейбла.
При этом из анстейбла берутся все переносимые пакеты и все их 
зависимости. Тоесть из анстейбла выбирается такой себе минирепо 
и вбрасывается-пересобирается в стейбле.

Все это требует чудовищные машинные ресурсы.
Почему бы не замещать стейлб анстейблом полностью? Тоесть 
анстейбл пересобирается полностью, раз в неделю например. У него 
исчезают внутренние анмиты. И после этого анстейбл путем полного 
копирования переезжает в стейбл.

> Допустим, например, что перенос пакета A в "testing" не
> порождает новых анметов.  Спрашивается,
> - если перенос пакета A в "testing" ломает устанавливаемость
> пакета B из "testing", это "break" или нет, и почему?

Значит надо перенести не только А но и В. Это же тестинг. И вот 
тут нужны карманы гит.альт.

Как же перенести А в тестинг. А сломает тестинг на момент 
переноса и до пересборки тестинга. Но можно сделать следующее: 
перенести В вместе с А, или пересобрать А с В в окружении 
тестинга.

> - если перенос пакета A в "testing" ломает сборку пакета B из
> "testing", это "break" или нет, и почему?

Значит надо перенести не только А но и В. Или починить сборку В.

> - если перенос пакета A в "testing" ломает устанавливаемость
> пересобранного с ним пакета B из "testing", это "break" или
> нет, и почему?

Значит надо перенести не только А но и В.

> Вот более-менее реалистичный пример: новая версия gcc может
> вызвать изменение soname в пересобранном с ним libapt, что, в
> свою очередь, вызовет изменение зависимостей клиентов libapt. 
> Вопрос, перенос такого обновления gcc в "testing" без
> пересобранного с ним libapt и всех его клиентов -- это "break"
> или нет, и почему?

Надо перенести новую версию gcc и всех кто от нее зависит.

P.S. Я где-то ошибаюсь и причем очень сильно. Но не могу понять 
где именно.

-- 
Алексей.
GPG key fingerprint
DBB3 1832 13C6 5C96 4A58  4AFF 78F7 159F 66AD 8D7E