[devel] Точечные правки для дистрибутивов вне репозитория

[Michael Pozhidaev]

Hello, Aleksey Novodvorsky!

>> один огород потом с Provides можно, но это стрельба из пушки;
>
> Возможно и из пушки, но есть ли лучшие варианты? 

Без пропатченного emacs - только каждому пользователю класть у себя
файлы, отключающие обработку конфигов.

> Оба приведенные Вами примера не есть частные проблемы одного
> дистрибутива. И emacs-speak, и речевой логин, будучи хорошо
> реализованными, понадобились бы широкому кругу пользователей, они
> вовсе не специальны, как может показаться.

Хорошо. Я всё же ниже приведу свои соображения на эту тему. Если
сообщество не заинтересуется, то будем стараться все подобные вещи
делать в репозитории.

> Михаил, полностью с Вами согласен.
> Давайте обсуждать варианты.

Предлагаю принять за априорное знание, что полный форк репозитория
запрещён. Это скорее организационно-политический вопрос, нежели
технический.

1. mithraen@ когда-то толкал идею репозитория, куда можно вливать
изменённые пакеты. Суть была в том, что при обновлении пакета в Сизифе
(или бранче, откуда форк) это обновление проходит также и в
клонированном репозитории, если в нём версия этого пакета такая же, как
в Сизифе (бранче). Тут, очевидно, вылазит множество вопросов с анметами,
которые могут появиться из-за расхождений, но нужно помнить, что мы
говорим всё-таки о точечных правках. Может быть, Денис (mithraen@)
сможет более полно ещё рассказать своё понимание, но рассмотрим такие
правила:

а) при патче пакета запрещаем трогать Provides, Conflicts и
Obsoletes. Также патч пакета не должен приводить и к их изменению при
их автогенерировании;

б) Requires можно только сокращать и добавлять, изменять
нельзя. При добавлении новых можно только указать имя пакета, но нельзя
указывать версию-релиз. Так как множество пакетов в основном репозитории
и в клоне одинаковое (по именам), такие правила покроют большую часть
проблем. BuildRequires играют меньшую роль, поскольку считаем, что
сборка ведётся всегда в основном репо;

в) при обновлении пакета в основном репозитории всегда требовать его
мержа с тем, что лежит в форке. Поскольку у нас сейчас повсеместно git,
а правки, ещё раз обращаю внимание, точечные, то это будет просто
ненавязчиво-рутинной операцией. При мерже, само собой, должны
соблюдаться пункты aа и б. Если rm прозевал такой мерж, то репо
замораживается. При удалении пакета он тоже всегда удаляется.

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

2. определённая машинерия, которая перед запуском mkimage будет собирать
в локальном хешере часть пакетов из git и строить на их основе локальный
форк. Но это должно делаться так, чтобы список этих исключений был бы
где-нибудь публикуем. Например, если mike@ когда-то собрал у себя дистр
таким путём, то я мог бы потом понять, что он делал.

Ещё пара слов, к чему всё это. Суть в том, что в своём списке рассылки
(и не только в нём) получил не то, чтобы очень неожиданный, но достаточный интересный опыт
пожеланий пользователей. Люди не просят сделать редизайн речевого
сервера, а просят поотключать разные message box, которые некстати
вылазят там, где ещё нет речевого вывода, переставить ключи по умолчанию
и пр. Самое сложное, что от этих-то вещей и зависит пользовательское
расположение к продукту. 

-- 
Michael Pozhidaev. Tomsk, Russia. E-mail: msp at altlinux.ru
Russian info page: http://www.marigostra.ru/