[devel] gear и патчи

[Sergey Vlasov]

On Mon, Nov 27, 2006 at 03:48:26PM +0300, Grigory Batalov wrote:
> Можно ли (или можно ли будет) в .gear-rules указывать в качестве патчей
> коммиты из git? Типа <название патча>: <откуда>-<до куда> или даже
> <название патча>: <откуда1>-<до куда1>,<откуда2>-<до куда2>.
> 
> Например:
> foo-0.1-alt-build.patch: f9f580742b3b499e4a0fb298511f42f482a14928:bbab731ee05b4a9211545309d9fdf2954a7e8961

В последней версии gear это может быть записано в виде:

diff: f9f580742b3b499e4a0fb298511f42f482a14928:. bbab731ee05b4a9211545309d9fdf2954a7e8961:. name=foo-0.1-alt-build.patch

(в name=... можно использовать @name@, @version@, @release@,
@old_dir@, @new_dir@).  Можно также написать diff.gz или diff.bz2.
Ограничение - нельзя указывать совсем произвольные sha1, это должны
быть коммиты, предшествующие (непосредственно или через произвольное
количество промежуточных коммитов) тому коммиту, из которого
собирается пакет.

Чтобы не писать sha1 в .gear-rules, можно использовать вместо них
имена тегов, сохранённых с помощью gear-update-tag.  Хотя этот вариант
применим в основном в случае, когда генерируется один общий патч:

diff: v на version@:. .

(по умолчанию name=@new_dir на -@version на -@release на .patch, при указании
"." вместо @new_dir@ используется @name@).  Ограничения на указание
коммитов через имена тегов те же самые.

> Мне кажется, удобнее исправлять исходники непосредственно в git,
> скажем, в бранче devel, а не обновлять от версии к версии файлы
> .patch.

Тогда возникает вопрос, что делать при обновлении до новой версии.
Естественный для git вариант - объединить изменения с новой версией
через git-pull (т.е., merge), но при этом результат в общем случае уже
не представляется в виде набора патчей - можно сделать только один
общий патч от оригинальной версии к модифицированной.  Чтобы получить
какое-то одно изменение в виде патча к текущей версии, придётся
выполнять, например, git-cherry-pick в отдельной временной ветке
(тащить его в историю пакета при таком способе работы бессмысленно -
оно там уже есть, возможно, с исправлениями, внесёнными в ходе
разрешения конфликтов при merge; единственная причина делать это -
необходимость подготовки патча для передачи, например, в upstream).

Кстати, можно завести не один бранч devel, а несколько, куда разносить
изменения, относящиеся к разным по смыслу исправлениям.

Есть другой вариант - git-rebase при переходе на новую версию из
upstream; в этом случае отдельные патчи сохраняются, но теряется связь
с предыдущей историей пакета, что в новой системе сборки недопустимо.
Правда, можно восстановить эту связь через git-pull -s ours, но при
таком способе история будет засоряться многочисленными копиями одних и
тех же изменений для разных версий пакета (впрочем, в этом случае
старую историю можно будет просто отсечь при просмотре изменений,
поскольку она не будет содержать полезной информации - все изменения
относительно upstream после git-rebase будут воспроизведены в новых
коммитах, либо удалены, если они уже вошли в upstream).

> Тем более, что последние обычно называют
> <package>-<version>-alt-<what>.patch, то есть эти файлы будут
> появляться и исчезать при смене <version>.

Зачастую при смене <version> старые патчи как раз не перегенерируются,
пока окончательно не перестанут прикладываться.  В некоторых случаях
это приводит к трудновыявляемым проблемам, когда патч вроде бы ложится
на новую версию, но какие-то изменения попадают совсем не туда, куда
надо.  Теоретически алгоритм 3-way merge может быть более устойчив к
подобным ошибкам, чем patch, поскольку имеет больше информации
(информация об изменениях не ограничена размером контекста, как в
случае patch).  Хотя при выполнении git-rebase возможность получить
такую проблему сохраняется, поскольку по умолчанию (без опции --merge)
git-rebase сначала пытается приложить изменение как патч, и только в
том случае, если это не удаётся, использует 3-way merge.

> Можно было бы просто паковать в SRPM модифицированное дерево
> исходников, но тогда как указать на конкретное исправление
> пользователям других дистрибутивов? Отсылать в наш git?

Отсылать было бы хорошо в gitweb, но его у нас пока нет.  С другой
стороны, если предполагается упразднение src.rpm, какое-то средство
типа gitweb должно появиться раньше этого.
----------- следущая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : отсутствует
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: отсутствует
Url     : http://lists.altlinux.org/pipermail/devel/attachments/20061127/9f74d210/attachment-0001.bin