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

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

[Evgeny Sinelnikov]

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

Жаль, что это догадки, жаль, что этим пока никто не занимается... 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)

Re: [devel] Бранчи и расширения

[Dmitry V. Levin]

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

On Wed, Aug 26, 2009 at 01:27:27PM +0400, Evgeny Sinelnikov wrote:
> 26 августа 2009 г. 12:20 пользователь Boris Savelev
> (boris@altlinux.org) написал:
> > 26 августа 2009 г. 12:11 пользователь Alexey Tourbin (at@altlinux.ru) написал:
> >> 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 подразумевает дупы по определению.
> 
> Это забавно, но подразумевает, что сторонние разработчики со своими
> довесками в виде дополнительных репозиториев оказываются "вне закона".

Не "вне закона", а вне инфраструктуры, поскольку они сторонние.  Вряд ли
они сделают стороннюю инфраструктуру, сравнимую со стандартной, поскольку
они там на стороне обычно считают, что им это просто не нужно: genbasedir
работает, и ладно...


-- 
ldv

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

Re: [devel] Бранчи и расширения

[Evgeny Sinelnikov]

26 августа 2009 г. 13:57 пользователь Dmitry V. Levin
(ldv@altlinux.org) написал:
> On Wed, Aug 26, 2009 at 01:27:27PM +0400, Evgeny Sinelnikov wrote:
>> 26 августа 2009 г. 12:20 пользователь Boris Savelev
>> (boris@altlinux.org) написал:
>> > 26 августа 2009 г. 12:11 пользователь Alexey Tourbin (at@altlinux.ru) написал:
>> >> 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 подразумевает дупы по определению.
>>
>> Это забавно, но подразумевает, что сторонние разработчики со своими
>> довесками в виде дополнительных репозиториев оказываются "вне закона".
>
> Не "вне закона", а вне инфраструктуры, поскольку они сторонние.  Вряд ли
> они сделают стороннюю инфраструктуру, сравнимую со стандартной, поскольку
> они там на стороне обычно считают, что им это просто не нужно: genbasedir
> работает, и ладно...
>

Ну, когда всё уже проверено, оно так и есть ;)

А что сторонние разработчики должны учитывать? Это где-то прописано?

Я полагаю дело выглядящим так. Вот есть Desktop 4.1. Сторонние
разработчики могут пожелать:
а) собрать под него сторонний софт, который в силу многих причин не
попал и не попадёт в основной репозиторий, и сделать его доступным для
пользователей дистрибутива. Что, кроме genbasedir, должно заботить
сторонних разработчиков?
б) расширить функционал дистрибутива путём его исправления и
доработки. Тут есть, что предусматривать, но ведь основной репозиторий
это не ломает... Почему бы не предупредить их о проблемах, если вы
таковые видите? Зачем ставить условие, что репозиторий должен быть
только один? Если речь об этом не ведётся, то как объяснить, что
официально признаётся, не надёжность стека репозиториев?

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

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

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


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

-- 
Sin (Sinelnikov Evgeny)