[devel] Бранчи и расширения. was: branch 5.0 RIP ?

Wed Aug 26 13:27:27 MSD 2009

26 августа 2009 г. 12:20 пользователь Boris Savelev
(boris at altlinux.org) написал:
> 26 августа 2009 г. 12:11 пользователь Alexey Tourbin (at at altlinux.ru) написал:
>> On Wed, Aug 26, 2009 at 11:52:32AM +0400, Boris Savelev wrote:
>>> 26 августа 2009 г. 11:46 пользователь Alexey Tourbin (at at altlinux.ru) написал:
>>> > On Wed, Aug 26, 2009 at 11:36:37AM +0400, Boris Savelev wrote:
>>> >> 26 августа 2009 г. 11:27 пользователь Alexey Tourbin (at 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, исключив дупы, и
>> проверять целостность этого среза.  Это примерно то что делать сборочная
>> система.
>>
>> В апте тоже есть понятие пакета-кандидата, которое отчасти аналогично
>> понятию среза репозитория.  Маркером "кандидата" отмечаются пакеты
>> наиболее свежих версий, и аптовские алгоритмы работают на срезе
>> "кандидатов".  Иначе апт заклинит на дупах.  Но кандидаты решают
>> не все проблемы.  Если подключить два репозитория то апт скорее всего
>> заколбасит.
>>

Жаль, что это догадки, жаль, что этим пока никто не занимается... APT
- это уже сложная штука. Если его можно пофиксить без полного
редизайна, то эти задачи стоит озвучить.

> удивительно, что никто до сих пор в этом не убедился! к тому же, как я
> понимаю, apt в дебиане по этому поводу не колбасит вроде?

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

>
>> В принципе конечно можно делать updates, но какими-то другими средствами.
>>
> стоит подумать над этим %)
>
>>> > , более консервативные бранчи/стеки
>>> это как? можно как-то раскрыть эту фразу? почему в альте этого нет?-)
>>
>> Ну например могут быть правила что в стабильных бранчах нельзя
>> переименовывать пакеты нельзя менять сонеймы нельзя менять версии.
>> То есть ограничив изменения, мы можем обезопасить себя от их
>> последствий.  Но автоматически ограничить изменения очень сложно.
>>

Я, конечно понимаю, что это сложно, но можно ли как-то, без "ну
например", предложить набор правил, исходя из опыта и понимания работы
APT? Думаю, что не посвящённому придётся долго ходить по граблям
предполагая живым то, что уже известно, как не рабочее.

>
> В альте нет чего-то типа branch policy? какой смысл тогда, без наличия

К сожалению, политика такова, что branch policy нужен тем, кто держит
бранчи. Поддержка сторонних держателей бранчей не предусмотрена.
Скорее наоборот, Регулярно высказывается мнение, что это задача
сложна, а может быть даже и неразрешима.

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

Вообще понятно, что для работы, пока придуманы и внедрены механизмы с
одним репозиторем. Мне хотелось бы уточнить один момент.
Я хочу перечислить варианты использования бранчей с расщирениями и,
если получиться, понять применимость этих вариантов на практике
сегодня (с текущим аптом) и завтра (с аптом, который можно довести до
ума):
1. Бранч + расширения в виде приложений и собственных библиотек, не
пересекающихся по сонеймам. Это задача для дистрибьютора стороннего
софта.
2. Бранч + обновления отдельных пакетов и библиотек, не ломающих ABI.
Это задача для разработчиков саттелитных дистрибутивов.
3. Бранч + обновления отдельных пакетов и библиотек, ломающих ABI и
вводящих новые сонеймы. Это задача для разработчиков дистрибутивов на
базе текущего бранча.

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

Расширение может стать проблемой когда, по недоумению или недознанию,
один из первых двух вариантов превращается в третий. Так вот это уметь
распознать и, для этого, стоит иметь инструменты, чтобы помочь
сторонним разработчикам вовремя заметить потенциальную проблему. Жаль,
если эта задача не формализуема... Хотя вот проблемы апта всё-таки
ведь вполне формально выявляются...

Здесь было бы неплохо получить нормальный API для работы с аптом. Меня
вот bash как-то совсем для таких задач не устраивает. Починить стоит
хотя бы связку с питоном...

PS: хочу сообщить, что меня эта тема интересует ещё и потому, что я
недавно реализовал механизм пресловутых карманов на git.etersoft.

Расширения girar следующие:
- добавлена команда pocket
$ ssh git.eter help|grep pocket
pocket--help|create|delete|show|list| ...
можно создавать репозитории, которые будут являться расширениями к базовому:
$ ssh git.eter pocket create --help|grep pocket
usage: girar-pocket create <pocket_name> [<binary_repository_name>]
- при сборке в карман указывается параметр '-p':
$ ssh git.eter task new -p <имя_кармана>
или сразу сборка:
$ ssh git.eter build -p <имя_кармана> <gear_repo> <gear_tag> ...

Осталось завершить вопрос с ACL... И далее думать об autorebuild...

PPS: Кстати, у меня не работают проверки в girar-builder. Вероятно
из-за того, что они рассчитаны на один большой репозиторий без
расширений. Есть ли возможность применить средства проверки для стека
репозиториев? Для анметов, я так понимаю, проблема обозначилась
принципиальная, но есть ещё elf'ы...

-- 
Sin (Sinelnikov Evgeny)