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). > Тем более, что последние обычно называют > --alt-.patch, то есть эти файлы будут > появляться и исчезать при смене . Зачастую при смене старые патчи как раз не перегенерируются, пока окончательно не перестанут прикладываться. В некоторых случаях это приводит к трудновыявляемым проблемам, когда патч вроде бы ложится на новую версию, но какие-то изменения попадают совсем не туда, куда надо. Теоретически алгоритм 3-way merge может быть более устойчив к подобным ошибкам, чем patch, поскольку имеет больше информации (информация об изменениях не ограничена размером контекста, как в случае patch). Хотя при выполнении git-rebase возможность получить такую проблему сохраняется, поскольку по умолчанию (без опции --merge) git-rebase сначала пытается приложить изменение как патч, и только в том случае, если это не удаётся, использует 3-way merge. > Можно было бы просто паковать в SRPM модифицированное дерево > исходников, но тогда как указать на конкретное исправление > пользователям других дистрибутивов? Отсылать в наш git? Отсылать было бы хорошо в gitweb, но его у нас пока нет. С другой стороны, если предполагается упразднение src.rpm, какое-то средство типа gitweb должно появиться раньше этого.