[devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm

[Alexey Tourbin]

On Mon, Apr 09, 2007 at 10:06:52PM +0400, Eugene Prokopiev wrote:
> Мне удобнее всего вести разработку в 2-х бранчах:
> 
> 1) dbmail_2_2 - импортируется из upstream scm, причем только тот бранч,
> который соответствует версии нашего пакета
> 2) srpms - все, что необходимо для сборки пакета

Вооще-то бранч srpms по идее предназначен для импорта утилитой
gear-srpmimport.  Можно делать гораздо проще: всё необходимое для сборки
rpm пакета, в том числе и дерево исходников, просто деражть в бранче
master.

> Затем необходимо импортировать содержимое последнего пакета (можно не
> только последнего) в в бранч srpms репозитария с помощью gear-srpmimport
> --import-only, перейти в бранч rpms с помощью git-checkout и удалить
> распакованные исходники (git-rm -r -f dbmail), т.к. мы будем 

Можно не удалять.  Точнее, можно делать pull из scm бранча, с которым
происходит синхронизация.  Другими словами, состояние master бранча
может быть максимально приближенным к тому, что получается после rpm -bp.
Я так делаю в большинстве своих пакетов и не вижу серьезных недостатоков
у этого подхода.

>     * для git:  git-fetch [url] [remote tag]:[local tag] - в нашем
> случае команда будет выглядеть так:
> 
> git-fetch http://nfg3.nfgs.net/git/dbmail.git dbmail_2_2:dbmail_2_2
> 
>     * для svn: ?

git-svnimport или git-svn

>     * для cvs: ?

git-cvsimport, то это бывает глюковато на сложных cvs репозитариях.
Я собрал parsecvs, он менее глюкав, но его использование требует некоего
проникновенного понимания. :(

> После импорта необходимо перейти в новый бранч (git-checkout dbmail_2_2) 
> найти таг, на основе которого будет генерироваться тарболл, или создать 
> его с помощью git-tag, указав идентификатор коммита или имя бранча - в 
> этом случае будет взят последний на момент создания тага коммит в 
> бранче. Дерево git удобнее всего изучать с помощью gitk --all, список 
> тагов - с помощью git-show-ref. В нашем случае команда создания тага 
> будет выглядеть так:
> 
> git-tag -a -m 'new dbmail 2.2.4 09.04.2007 21:40' 
> dbmail/2.2.4.200704092140 a42aa96f31a555c2b20d600cdd6e961c0d9cfb67
> 
> Соданный таким образом новый или уже существующий коммит необходимо 
> подшить к бранчу srpms (предварительно перейдя в него - git-checkout 
> srpms), чтобы он был доступен при генерации тарболла:
> 
> git-merge -s ours 'Using upstream branch' HEAD dbmail/2.2.4.200704092140
> 
> Затем необходимо обновить .gear-tags с помощью gear-update-tag -a

Вообще-то можно не scm бранч подшивать к srpms бранчу, а прямо сами
src.rpm пакеты подшивать куда надо в scm бранч.  Это тоже требует
некоего проникновенного понимания производимых действий.  Но мне удалось
уже полуавтоматически импортировать несколько пакетов именно так.

В общем, первый раз было очень сложно всё это понять, а теперь как-то
само стало получаться. :)

Вот небольшой пример того, как я ипортировал src.rpm пакеты к
оригинальному дереву libxml2, которое импортировал сначала из cvs,
а теперь продолжаю импортировать из svn.  (Приложил рисунок.)

.gear-tags использовать, по крайней мере сейчас, не обязательно.
.gear-tags, по идее, удобно использовать, когда все релизы привязаны к
определенной версии, или даже к определенному тарболлу.  Тогда с помощью
.gear-tags можно легко сгенерировать кумулятивный патч к тарболу.  Если
же релизы постоянно перебазируются на всё более свежий snapshot, тогда
для каждого snapshot'а делать отдельный gear-tag, по-моему, смысла нет.
Можно делать просто %name-%version-%release.tar.

gear-srpmimport создает каталог для тарболла, что неудобно при импорте
и подшивании к оригинальному scm дереву.  Можно слегка модифицировать
gear-srpmimport (на свой страх и риск), чтобы он не создавал
подкаталога (после этого всё равно должно собираться с оригинальным
тарболлом, хотя уже будет создаваться тарболл со спекфайлом и
.gear-rules).  Вот мой наспех модифицированный .gear-rules.

--- /usr/bin/gear-srpmimport	2007-03-20 22:00:01 +0000
+++ /home/at/tmp/gear-srpmimport	2007-04-03 20:04:38 +0000
@@ -295,11 +295,18 @@ import_tree()
 	[ "$arch_basename" = "$base" ] ||
 		rule_base=" base=$base"
 
-	printf '%s: %s%s%s%s\n' "$method_pack" "$dir_name" "$rule_name" "$rule_base" "$rule_suffix" |
-		sed "s/${quoted:- на version@}/@version@/g" >>"$gear_rules"
-
 	git ls-files -z --others --modified -- "$dir_name" |
 		git update-index --add ${verbose:+--verbose} -z --stdin
+	find ./"$dir_name" -not -type d |while IFS= read -r f; do
+		dest=./${f#./$dir_name/}
+		mkdir -p "$(dirname "$dest")"
+		git mv -f "$f" "$dest"
+	done
+
+	rule_name=" name=$dir_name-$spec_version"
+	dir_name=.
+	printf '%s: %s%s%s%s\n' "$method_pack" "$dir_name" "$rule_name" "$rule_base" "$rule_suffix" |
+		sed "s/${quoted:- на version@}/@version@/g" >>"$gear_rules"
 }
 
 import_file()

> Для выгрузки необходимо создать файл .git/remotes/origin с таким содержимым:

Я последнее время стал вносить это дело в .git/config, напр.:

[remote "git.alt"]
	url = git.alt:/people/at/packages/libixp.git

Соответственно потом можно делать типа

$ git-push git.alt master 0.3-alt0.1
и т.п.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : libxml2-git.png
Тип     : image/png
Размер  : 12998 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20070409/8ca76c74/attachment-0001.png>
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20070409/8ca76c74/attachment-0001.bin>