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

[Evgeny Sinelnikov]

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

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

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

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

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

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

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


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

-- 
Sin (Sinelnikov Evgeny)