[devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 1455 bytes --]

Идея в следующем:

"Апстримные" сорцы лежат в бранче, например upstream, апдейтятся
там некоторым образом (git pull, git svn fetch, git cvsimport -
whatever).  В рабочем бранче лежат мои патченые исходники, спеки
и так далее.  gear пакует бранч upstream в тарбол и делает
git-diff-tree между upstream и некоторым tree-ish.  Почему
tree-ish, а не HEAD?  А потому что я обычно делаю
git-mv -k * .* %name, и вот этот %name мне и надо diff'ать.

Сейчас никто не умеет принимать в качестве аргумента tree-ish,
только путь.  Предлагается следующий синтаксис:

tar: dir name=name base=base branch=branch

diff: dir name=name base=base branch=branch

В первом случае добавляется параметр "branch", в моём примере это
будет выглядеть так:

tar.bz2: . name=@name@-@version@ base=@name@-@version@ branch=upstream-@version@

Где upstream-@version@ это имя тега, который я ставлю по
результатам чекаута (чисто для удобства).

diff: projectname name=@name@-@version@-alt.patch base=. branch=upstream-@version@

projectname - имя каталога с сорцами в рабочем бранче.  По нему
получаем tree_ish_2.  base - имя каталога с сорцами в бранче
upstream.  По нему и по имени бранча получаем tree_ish_1.  Дальше
делается:

git-diff-tree --patch-with-stat $tree_ish_1 $tree_ish_2 > $name.patch


Таким образом получается что у нас "скачет" $tree_id.  Это совсем
бредовая идея или можно начинать готовить патч? ;-)

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Alexey I. Froloff]

[-- Attachment #1.1: Type: text/plain, Size: 477 bytes --]

* Alexey I. Froloff <raorn@> [060620 19:26]:
> Таким образом получается что у нас "скачет" $tree_id.  Это совсем
> бредовая идея или можно начинать готовить патч? ;-)
Патч на tar* оказался тривиальным, но не могу придумать описание
этой опции.  У diff* синтаксис будет аналогичный.

А можно не пользоваться diff*, а периодически сваливать
результаты git-format-patch в отдельный каталог (после
git-rebase) и эти патчи накладывать в спеке.

-- 
Regards,
Sir Raorn.

[-- Attachment #1.2: gear-tar-branch.patch --]
[-- Type: text/plain, Size: 2611 bytes --]

From nobody Mon Sep 17 00:00:00 2001
From: Sir Raorn <raorn@altlinux.ru>
Date: Tue, 20 Jun 2006 20:04:53 +0400
Subject: [PATCH] branch=branch_name parameter for tar command.

With this option it is possible to keep unmodified upstream
sources in another branch with help of git-cvsimport, git-svn,
git-svnimport, git-pull and so on.

Signed-off-by: Sir Raorn <raorn@altlinux.ru>

---

 gear |   15 ++++++++++++---
 1 files changed, 12 insertions(+), 3 deletions(-)

65871a4ac82d1fde66d3d2a724ce460334bf3504
diff --git a/gear b/gear
index b113ce4..063e152 100755
--- a/gear
+++ b/gear
@@ -38,6 +38,7 @@ #    name=archive_name  - tar archive na
 #    base=base_name     - when specified it is added as a leading path
 #                         to the files in the generated tar archive.
 #    spec=path_to_file  - path to specfile which defines keywords;
+#    branch=branch_name - when specified sets [WRITEME]
 #  Valid tar keywords are:
 #    @dir@ - basename(path_to_directory);
 #    @name@, @version@, @release@.
@@ -330,6 +331,8 @@ get_tar_name()
 	# Special non-empty marker.
 	tar_base=' '
 
+	tar_tree="$tree_id"
+
 	local opt quoted spec= spec_name= spec_version= spec_release=
 
 	for opt; do
@@ -341,6 +344,9 @@ get_tar_name()
 				;;
 			base=*) tar_base="${opt#base=}"
 				;;
+			branch=*)
+				tar_tree="${opt#branch=}"
+				;;
 			*) rules_error "Unrecognized option: $opt"
 				;;
 		esac
@@ -359,6 +365,7 @@ get_tar_name()
 	subst_keywords tar_name "$dir" "$spec_name" "$spec_version" "$spec_release"
 	[ -z "$tar_base" -o "$tar_base" = ' ' ] ||
 		subst_keywords tar_base "$dir" "$spec_name" "$spec_version" "$spec_release"
+	subst_keywords tar_tree "$dir" "$spec_name" "$spec_version" "$spec_release"
 }
 
 make_tar()
@@ -374,16 +381,18 @@ make_tar()
 	shift
 	[ "$tar_base" != ' ' ] ||
 		tar_base="$name"
+	tar_tree="$1"
+	shift
 
 	local id
 	if [ "$dir" = . ]; then
-		id="$tree_id"
+		id="$tar_tree"
 	else
 		local dir_name base_name quoted
 		dir_name="$(dirname -- "$dir")"
 		base_name="$(basename -- "$dir")"
 		# modifies $tree
-		traverse_tree "$tree_id" "$dir_name" ||
+		traverse_tree "$tar_tree" "$dir_name" ||
 			return 0
 		quoted="$(quote_sed_regexp "$base_name")"
 		id="$(git-ls-tree "$tree" "$base_name" |
@@ -424,7 +433,7 @@ make_archive()
 	check_path dirname "$dir_name"
 
 	get_tar_name "$(basename -- "$dir_name")" "$@"
-	make_tar "$cmd" "$dir_name" "$tar_name" "$tar_base"
+	make_tar "$cmd" "$dir_name" "$tar_name" "$tar_base" "$tar_tree"
 }
 
 copy_by_pattern()
-- 
1.3.3


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Alexey I. Froloff]

[-- Attachment #1.1: Type: text/plain, Size: 204 bytes --]

* Alexey I. Froloff <raorn@> [060620 20:13]:
> У diff* синтаксис будет аналогичный.
Вот и он.  Изменений много, потому как оно похоже не tar, но есть
маленькие отличия...

-- 
Regards,
Sir Raorn.

[-- Attachment #1.2: gear-diff-command.patch --]
[-- Type: text/plain, Size: 6178 bytes --]

From nobody Mon Sep 17 00:00:00 2001
From: Sir Raorn <raorn@altlinux.ru>
Date: Tue, 20 Jun 2006 20:56:41 +0400
Subject: [PATCH] diff[.gz|.bz2] command.

diff: path_to_dir name=name_of_patch base=dir_in_branch branch=branch_with_sources

Calls git-diff-tree -r --patch-with-stat on $base in $branch
and dir in current branch.  This helps keep unmodified upstream
sources in different branch and make diff against current
working branch for apllying later in specfile.

Signed-off-by: Sir Raorn <raorn@altlinux.ru>

---

 gear |  142 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 141 insertions(+), 1 deletions(-)

13059c9958af7969bda3cfa5c231ecb7a2e23ea2
diff --git a/gear b/gear
index 063e152..99ed79b 100755
--- a/gear
+++ b/gear
@@ -32,6 +32,7 @@ #  (copy|gzip|bzip2): glob_pattern..
 #  (copy|gzip|bzip2)?: glob_pattern..
 #  exclude: glob_pattern..
 #  tar(|.gz|.bz2): path_to_directory [options]
+#  diff(|.gz|.bz2): path_to_directory [options]
 #  
 #  Valid tar options are:
 #    name=archive_name  - tar archive name, may reference to keywords;
@@ -43,6 +44,16 @@ #  Valid tar keywords are:
 #    @dir@ - basename(path_to_directory);
 #    @name@, @version@, @release@.
 #  Default tar archive name is @dir@-@version@.
+#
+#  Valid diff options are:
+#    name=diff_name         - patch name, may reference to keywords;
+#    base=path_to_directory - directory in branch_name, first argunemt
+#                             to git-diff-tree;
+#    spec=path_to_file      - path to specfile which defines keywords;
+#    branch=branch_name     - branch name with "original" source tree;
+#  Valid diff keywords are the save as tar.
+#  Default patch name is @dir@-@version@-@release@.
+#  Default base is ".".
 
 PROG=gear
 
@@ -333,7 +344,7 @@ get_tar_name()
 
 	tar_tree="$tree_id"
 
-	local opt quoted spec= spec_name= spec_version= spec_release=
+	local opt spec= spec_name= spec_version= spec_release=
 
 	for opt; do
 		case "$opt" in
@@ -368,6 +379,48 @@ get_tar_name()
 	subst_keywords tar_tree "$dir" "$spec_name" "$spec_version" "$spec_release"
 }
 
+get_diff_name()
+{
+	local dir="$1"
+	shift
+	diff_name='@name@-@version@-@release@'
+	diff_base='.'
+	diff_tree="$tree_id"
+
+	local opt spec= spec_name= spec_version= spec_release=
+
+	for opt; do
+		case "$opt" in
+			spec=*) spec="${opt#spec=}"
+				check_path specfile "$spec"
+				;;
+			name=*) diff_name="${opt#name=}"
+				;;
+			base=*) diff_base="${opt#base=}"
+				;;
+			branch=*)
+				diff_tree="${opt#branch=}"
+				;;
+			*) rules_error "Unrecognized option: $opt"
+				;;
+		esac
+	done
+
+	if [ -n "$spec" ]; then
+		cat_blob "$tree_id" "$spec" >"$workdir/spec"
+		spec_name="$(sed '/^name:[[:space:]]*/I!d;s///;q' "$workdir/spec")"
+		spec_version="$(sed '/^version:[[:space:]]*/I!d;s///;q' "$workdir/spec")"
+		spec_release="$(sed '/^release:[[:space:]]*/I!d;s///;q' "$workdir/spec")"
+	fi
+	[ -n "$spec_name" ] || spec_name="$pkg_name"
+	[ -n "$spec_version" ] || spec_version="$pkg_version"
+	[ -n "$spec_release" ] || spec_release="$pkg_release"
+
+	subst_keywords diff_name "$dir" "$spec_name" "$spec_version" "$spec_release"
+	subst_keywords diff_base "$dir" "$spec_name" "$spec_version" "$spec_release"
+	subst_keywords diff_tree "$dir" "$spec_name" "$spec_version" "$spec_release"
+}
+
 make_tar()
 {
 	local cmd dir name
@@ -423,6 +476,76 @@ make_tar()
 	esac
 }
 
+make_diff()
+{
+	local cmd dir name
+	cmd="$1"
+	shift
+	dir="$1"
+	shift
+	name="$1"
+	shift
+	diff_base="$1"
+	shift
+	diff_tree="$1"
+	shift
+
+	local tree_id_1 tree_id_2
+
+	if [ "$diff_base" = . ]; then
+		tree_id_1="$diff_tree"
+	else
+		local dir_name base_name quoted
+		dir_name="$(dirname -- "$diff_base")"
+		base_name="$(basename -- "$diff_base")"
+		# modifies $tree
+		traverse_tree "$diff_tree" "$dir_name" ||
+			return 0
+		quoted="$(quote_sed_regexp "$base_name")"
+		tree_id_1="$(git-ls-tree "$tree" "$base_name" |
+			sed -ne 's/^[^[:space:]]\+[[:space:]]\+tree[[:space:]]\+\([^[:space:]]\+\)[[:space:]]\+'"$quoted"'$/\1/p')"
+		if [ -z "$tree_id_1" ]; then
+			if [ "$optional" = 1 ]; then
+				return 0
+			else
+				rules_error "tree $diff_base not found in $tree"
+			fi
+		fi
+	fi
+
+	if [ "$dir" = . ]; then
+		tree_id_2="$tree_id"
+	else
+		local dir_name base_name quoted
+		dir_name="$(dirname -- "$dir")"
+		base_name="$(basename -- "$dir")"
+		# modifies $tree
+		traverse_tree "$tree_id" "$dir_name" ||
+			return 0
+		quoted="$(quote_sed_regexp "$base_name")"
+		tree_id_2="$(git-ls-tree "$tree" "$base_name" |
+			sed -ne 's/^[^[:space:]]\+[[:space:]]\+tree[[:space:]]\+\([^[:space:]]\+\)[[:space:]]\+'"$quoted"'$/\1/p')"
+		if [ -z "$tree_id_2" ]; then
+			if [ "$optional" = 1 ]; then
+				return 0
+			else
+				rules_error "tree $dir not found in $tree"
+			fi
+		fi
+	fi
+
+	git-diff-tree -r --patch-with-stat "$tree_id_1" "$tree_id_2" >"$outdir/$name.patch"
+	verbose "Extracted \"$name.patch\" diff."
+	case "$cmd" in
+		diff.gz)
+			gzip -9 "$outdir/$name.patch"
+			;;
+		diff.bz2)
+			bzip2 -9 "$outdir/$name.patch"
+			;;
+	esac
+}
+
 make_archive()
 {
 	# format: "cmd dirname options.."
@@ -436,6 +559,19 @@ make_archive()
 	make_tar "$cmd" "$dir_name" "$tar_name" "$tar_base" "$tar_tree"
 }
 
+make_patch()
+{
+	# format: "cmd dirname options.."
+	local cmd="$1" dir_name="$2"
+	[ -n "$dir_name" ] ||
+		rules_error "No dirname specified"
+	shift 2
+	check_path dirname "$dir_name"
+
+	get_diff_name "$(basename -- "$dir_name")" "$@"
+	make_diff "$cmd" "$dir_name" "$diff_name" "$diff_base" "$diff_tree"
+}
+
 copy_by_pattern()
 {
 	# format: "cmd pattern.."
@@ -542,6 +678,10 @@ parse_rules()
 				make_archive "$cmd" $options ||
 					rules_error "Failed to make archive"
 				;;
+			diff|diff.gz|diff.bz2)
+				make_patch "$cmd" $options ||
+					rules_error "Failed to make patch"
+				;;
 			copy|gzip|bzip2)
 				copy_by_pattern "$cmd" $options ||
 					rules_error "Failed to copy by pattern"
-- 
1.3.3


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Anton Farygin]

Alexey I. Froloff wrote:
> Идея в следующем:
> 
> "Апстримные" сорцы лежат в бранче, например upstream, апдейтятся
> там некоторым образом (git pull, git svn fetch, git cvsimport -
> whatever).  В рабочем бранче лежат мои патченые исходники, спеки
> и так далее.  gear пакует бранч upstream в тарбол и делает
> git-diff-tree между upstream и некоторым tree-ish.  Почему
> tree-ish, а не HEAD?  А потому что я обычно делаю
> git-mv -k * .* %name, и вот этот %name мне и надо diff'ать.
> 
> Сейчас никто не умеет принимать в качестве аргумента tree-ish,
> только путь.  Предлагается следующий синтаксис:
> 
> tar: dir name=name base=base branch=branch
> 
> diff: dir name=name base=base branch=branch
> 
> В первом случае добавляется параметр "branch", в моём примере это
> будет выглядеть так:
> 
> tar.bz2: . name=@name@-@version@ base=@name@-@version@ branch=upstream-@version@
> 
> Где upstream-@version@ это имя тега, который я ставлю по
> результатам чекаута (чисто для удобства).
> 
> diff: projectname name=@name@-@version@-alt.patch base=. branch=upstream-@version@
> 
> projectname - имя каталога с сорцами в рабочем бранче.  По нему
> получаем tree_ish_2.  base - имя каталога с сорцами в бранче
> upstream.  По нему и по имени бранча получаем tree_ish_1.  Дальше
> делается:
> 
> git-diff-tree --patch-with-stat $tree_ish_1 $tree_ish_2 > $name.patch
> 
> 
> Таким образом получается что у нас "скачет" $tree_id.  Это совсем
> бредовая идея или можно начинать готовить патч? ;-)

Это примерно тоже самое, что месяц назад я писал в этот же список.

Отличная идея ;)

Rgds,
Rider

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2219 bytes --]

Hi,

On Tue, Jun 20, 2006 at 07:19:21PM +0400, Alexey I. Froloff wrote:
> Идея в следующем:
> 
> "Апстримные" сорцы лежат в бранче, например upstream, апдейтятся
> там некоторым образом (git pull, git svn fetch, git cvsimport -
> whatever).  В рабочем бранче лежат мои патченые исходники, спеки
> и так далее.  gear пакует бранч upstream в тарбол и делает
> git-diff-tree между upstream и некоторым tree-ish.  Почему
> tree-ish, а не HEAD?  А потому что я обычно делаю
> git-mv -k * .* %name, и вот этот %name мне и надо diff'ать.

Я хочу понять, почему вам недостаточно положить в srpm тарбол,
зачем всё-таки вы (я слышал как минимум от двоих) хотите паковать в srpm
оригинальный тарбол + кумулятивный патч?

> Сейчас никто не умеет принимать в качестве аргумента tree-ish,
> только путь.  Предлагается следующий синтаксис:
> 
> tar: dir name=name base=base branch=branch
> 
> diff: dir name=name base=base branch=branch
> 
> В первом случае добавляется параметр "branch", в моём примере это
> будет выглядеть так:
> 
> tar.bz2: . name=@name@-@version@ base=@name@-@version@ branch=upstream-@version@
> 
> Где upstream-@version@ это имя тега, который я ставлю по
> результатам чекаута (чисто для удобства).
> 
> diff: projectname name=@name@-@version@-alt.patch base=. branch=upstream-@version@
> 
> projectname - имя каталога с сорцами в рабочем бранче.  По нему
> получаем tree_ish_2.  base - имя каталога с сорцами в бранче
> upstream.  По нему и по имени бранча получаем tree_ish_1.  Дальше
> делается:
> 
> git-diff-tree --patch-with-stat $tree_ish_1 $tree_ish_2 > $name.patch
> 
> Таким образом получается что у нас "скачет" $tree_id.  Это совсем
> бредовая идея или можно начинать готовить патч? ;-)

Патч, кстати, выглядит нормально.  А вот по самой идее у меня есть вопрос.

Первоначально я исходил из идеи воспроизводимости, т.е. из того, что
результат работы "gear --tree-ish=ID" будет одинаковым при одинаковых ID.
Если в правилах для gear можно будет указывать произвольные tree-ish, то
это моё предположение не будет выполнено.

Вопрос: насколько эта воспроизводимость важна?  Можно ли ей пожертвовать в
пользу предлагаемой возможности?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Anton Farygin]

Dmitry V. Levin wrote:
> Hi,
> 
> On Tue, Jun 20, 2006 at 07:19:21PM +0400, Alexey I. Froloff wrote:
>> Идея в следующем:
>>
>> "Апстримные" сорцы лежат в бранче, например upstream, апдейтятся
>> там некоторым образом (git pull, git svn fetch, git cvsimport -
>> whatever).  В рабочем бранче лежат мои патченые исходники, спеки
>> и так далее.  gear пакует бранч upstream в тарбол и делает
>> git-diff-tree между upstream и некоторым tree-ish.  Почему
>> tree-ish, а не HEAD?  А потому что я обычно делаю
>> git-mv -k * .* %name, и вот этот %name мне и надо diff'ать.
> 
> Я хочу понять, почему вам недостаточно положить в srpm тарбол,
> зачем всё-таки вы (я слышал как минимум от двоих) хотите паковать в srpm
> оригинальный тарбол + кумулятивный патч?

Понятно почему - многие мантейнеры оригинальных тарболлов (из 
Mainstream) имеют свойство самостоятельно посещать src.rpm пакеты и 
забирать оттуда патчи.

Я уже несколько раз замечал это за авторами нескольких приложений.

> 
>> Сейчас никто не умеет принимать в качестве аргумента tree-ish,
>> только путь.  Предлагается следующий синтаксис:
>>
>> tar: dir name=name base=base branch=branch
>>
>> diff: dir name=name base=base branch=branch
>>
>> В первом случае добавляется параметр "branch", в моём примере это
>> будет выглядеть так:
>>
>> tar.bz2: . name=@name@-@version@ base=@name@-@version@ branch=upstream-@version@
>>
>> Где upstream-@version@ это имя тега, который я ставлю по
>> результатам чекаута (чисто для удобства).
>>
>> diff: projectname name=@name@-@version@-alt.patch base=. branch=upstream-@version@
>>
>> projectname - имя каталога с сорцами в рабочем бранче.  По нему
>> получаем tree_ish_2.  base - имя каталога с сорцами в бранче
>> upstream.  По нему и по имени бранча получаем tree_ish_1.  Дальше
>> делается:
>>
>> git-diff-tree --patch-with-stat $tree_ish_1 $tree_ish_2 > $name.patch
>>
>> Таким образом получается что у нас "скачет" $tree_id.  Это совсем
>> бредовая идея или можно начинать готовить патч? ;-)
> 
> Патч, кстати, выглядит нормально.  А вот по самой идее у меня есть вопрос.
> 
> Первоначально я исходил из идеи воспроизводимости, т.е. из того, что
> результат работы "gear --tree-ish=ID" будет одинаковым при одинаковых ID.
> Если в правилах для gear можно будет указывать произвольные tree-ish, то
> это моё предположение не будет выполнено.

Почему же ?

Всё равно tree-ish2 будет зависить от содердимого tree_ish1
> 
> Вопрос: насколько эта воспроизводимость важна?  Можно ли ей пожертвовать в
> пользу предлагаемой возможности?


На мой взгляд этого не требуется.

Rgds,
Rider

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1733 bytes --]

On Thu, Jun 22, 2006 at 10:36:30AM +0400, Anton Farygin wrote:
> Dmitry V. Levin wrote:
> > On Tue, Jun 20, 2006 at 07:19:21PM +0400, Alexey I. Froloff wrote:
> >> Идея в следующем:
> >>
> >> "Апстримные" сорцы лежат в бранче, например upstream, апдейтятся
> >> там некоторым образом (git pull, git svn fetch, git cvsimport -
> >> whatever).  В рабочем бранче лежат мои патченые исходники, спеки
> >> и так далее.  gear пакует бранч upstream в тарбол и делает
> >> git-diff-tree между upstream и некоторым tree-ish.  Почему
> >> tree-ish, а не HEAD?  А потому что я обычно делаю
> >> git-mv -k * .* %name, и вот этот %name мне и надо diff'ать.
> > 
> > Я хочу понять, почему вам недостаточно положить в srpm тарбол,
> > зачем всё-таки вы (я слышал как минимум от двоих) хотите паковать в srpm
> > оригинальный тарбол + кумулятивный патч?
> 
> Понятно почему - многие мантейнеры оригинальных тарболлов (из 
> Mainstream) имеют свойство самостоятельно посещать src.rpm пакеты и 
> забирать оттуда патчи.

Вообще говоря, это не совсем правильно, что не мантейнеры пакетов присылают
патчи, а мантейнеры тарболлов ищут их в srpm'ах.

А что будет, когда мы совсем откажемся от хранения srpm'ов?

> > Патч, кстати, выглядит нормально.  А вот по самой идее у меня есть вопрос.
> > 
> > Первоначально я исходил из идеи воспроизводимости, т.е. из того, что
> > результат работы "gear --tree-ish=ID" будет одинаковым при одинаковых ID.
> > Если в правилах для gear можно будет указывать произвольные tree-ish, то
> > это моё предположение не будет выполнено.
> 
> Почему же ?
> 
> Всё равно tree-ish2 будет зависить от содердимого tree_ish1

Поясню: представь себе запись типа branch=origin.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Anton Farygin]

Dmitry V. Levin wrote:
> On Thu, Jun 22, 2006 at 10:36:30AM +0400, Anton Farygin wrote:
>> Dmitry V. Levin wrote:
>>> On Tue, Jun 20, 2006 at 07:19:21PM +0400, Alexey I. Froloff wrote:
>>>> Идея в следующем:
>>>>
>>>> "Апстримные" сорцы лежат в бранче, например upstream, апдейтятся
>>>> там некоторым образом (git pull, git svn fetch, git cvsimport -
>>>> whatever).  В рабочем бранче лежат мои патченые исходники, спеки
>>>> и так далее.  gear пакует бранч upstream в тарбол и делает
>>>> git-diff-tree между upstream и некоторым tree-ish.  Почему
>>>> tree-ish, а не HEAD?  А потому что я обычно делаю
>>>> git-mv -k * .* %name, и вот этот %name мне и надо diff'ать.
>>> Я хочу понять, почему вам недостаточно положить в srpm тарбол,
>>> зачем всё-таки вы (я слышал как минимум от двоих) хотите паковать в srpm
>>> оригинальный тарбол + кумулятивный патч?
>> Понятно почему - многие мантейнеры оригинальных тарболлов (из 
>> Mainstream) имеют свойство самостоятельно посещать src.rpm пакеты и 
>> забирать оттуда патчи.
> 
> Вообще говоря, это не совсем правильно, что не мантейнеры пакетов присылают
> патчи, а мантейнеры тарболлов ищут их в srpm'ах.

Естественно не правильно. Но не всегда получается что-то отправить.

> 
> А что будет, когда мы совсем откажемся от хранения srpm'ов?
> 
>>> Патч, кстати, выглядит нормально.  А вот по самой идее у меня есть вопрос.
>>>
>>> Первоначально я исходил из идеи воспроизводимости, т.е. из того, что
>>> результат работы "gear --tree-ish=ID" будет одинаковым при одинаковых ID.
>>> Если в правилах для gear можно будет указывать произвольные tree-ish, то
>>> это моё предположение не будет выполнено.
>> Почему же ?
>>
>> Всё равно tree-ish2 будет зависить от содердимого tree_ish1
> 
> Поясню: представь себе запись типа branch=origin.

вот это точно не катит.

Лучше кстати не по branch брать, а по тэгу.

Выставить тэг с версией, и брать по нему.

Rgds,
Rider

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1156 bytes --]

On Thu, Jun 22, 2006 at 11:37:37AM +0400, Anton Farygin wrote:
> Dmitry V. Levin wrote:
[...]
> > Вообще говоря, это не совсем правильно, что не мантейнеры пакетов присылают
> > патчи, а мантейнеры тарболлов ищут их в srpm'ах.
> 
> Естественно не правильно. Но не всегда получается что-то отправить.

В фортунки. :)

> >>> Патч, кстати, выглядит нормально.  А вот по самой идее у меня есть вопрос.
> >>>
> >>> Первоначально я исходил из идеи воспроизводимости, т.е. из того, что
> >>> результат работы "gear --tree-ish=ID" будет одинаковым при одинаковых ID.
> >>> Если в правилах для gear можно будет указывать произвольные tree-ish, то
> >>> это моё предположение не будет выполнено.
> >> Почему же ?
> >>
> >> Всё равно tree-ish2 будет зависить от содердимого tree_ish1
> > 
> > Поясню: представь себе запись типа branch=origin.
> 
> вот это точно не катит.
> 
> Лучше кстати не по branch брать, а по тэгу.
> 
> Выставить тэг с версией, и брать по нему.

Т.е. добавить проверку того, что это именно tag object?
Тогда нужно s/branch=/tag=/

Всё равно не идеально (tag object может измениться), но уже лучше.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Anton Farygin]

Dmitry V. Levin wrote:
> On Thu, Jun 22, 2006 at 11:37:37AM +0400, Anton Farygin wrote:
>>>>> Патч, кстати, выглядит нормально.  А вот по самой идее у меня есть вопрос.
>>>>>
>>>>> Первоначально я исходил из идеи воспроизводимости, т.е. из того, что
>>>>> результат работы "gear --tree-ish=ID" будет одинаковым при одинаковых ID.
>>>>> Если в правилах для gear можно будет указывать произвольные tree-ish, то
>>>>> это моё предположение не будет выполнено.
>>>> Почему же ?
>>>>
>>>> Всё равно tree-ish2 будет зависить от содердимого tree_ish1
>>> Поясню: представь себе запись типа branch=origin.
>> вот это точно не катит.
>>
>> Лучше кстати не по branch брать, а по тэгу.
>>
>> Выставить тэг с версией, и брать по нему.
> 
> Т.е. добавить проверку того, что это именно tag object?
> Тогда нужно s/branch=/tag=/
> 
> Всё равно не идеально (tag object может измениться), но уже лучше.

да, давайте tag=

Ну совсем не думаю, что мантейнер будет менять tag на другую версию.. 
хотя конечно бывает разное..

Rgds,
Rider

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 251 bytes --]

* Dmitry V. Levin <ldv@> [060622 10:50]:
> > Всё равно tree-ish2 будет зависить от содердимого tree_ish1
> Поясню: представь себе запись типа branch=origin.
Ну это уже на усмотрение мантейнера.  Также как rm -rf / ;-)

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 420 bytes --]

On Thu, Jun 22, 2006 at 12:16:04PM +0400, Alexey I. Froloff wrote:
> * Dmitry V. Levin <ldv@> [060622 10:50]:
> > > Всё равно tree-ish2 будет зависить от содердимого tree_ish1
> > Поясню: представь себе запись типа branch=origin.
> Ну это уже на усмотрение мантейнера.  Также как rm -rf / ;-)

Не совсем.  Мне важно, чтобы запуск gear приводил к предсказуемым текм,
кто его запускает, результатам.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Anton Gorlov]

Dmitry V. Levin пишет:
> Я хочу понять, почему вам недостаточно положить в srpm тарбол,
> зачем всё-таки вы (я слышал как минимум от двоих) хотите паковать в srpm
> оригинальный тарбол + кумулятивный патч?

так как минимум будет возможность что-то, если понадобится оторвать из 
патчей, если будет необходимость.

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 514 bytes --]

On Thu, Jun 22, 2006 at 11:32:05AM +0400, Anton Gorlov wrote:
> Dmitry V. Levin пишет:
> > Я хочу понять, почему вам недостаточно положить в srpm тарбол,
> > зачем всё-таки вы (я слышал как минимум от двоих) хотите паковать в srpm
> > оригинальный тарбол + кумулятивный патч?
> 
> так как минимум будет возможность что-то, если понадобится оторвать из 
> патчей, если будет необходимость.

Для этого git-репозиторий больше подходит.  Оторвать часть кумулятивного
патча не так уж и просто.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Anton Gorlov]

Dmitry V. Levin пишет:

>> так как минимум будет возможность что-то, если понадобится оторвать из 
>> патчей, если будет необходимость.
> Для этого git-репозиторий больше подходит.  Оторвать часть кумулятивного
> патча не так уж и просто.

Кому как..мне например привычнее\удобнее видеть оригинальный исходник и 
патч к нему, который лежит рядом. Причём наиболее удобно -когла всё не 1 
куском в 1 гигантскомп атче,а кучка отдельных патчей..шде в 1 патче 
исправляется только 1 проблема..ао всех остальных другие. Как-то криво 
сказазал (/me только что проснулся), но думаю общий смысл понятен

Re: [devel] Q: .gear-rules и " апстримные " сорцы в отдельном бранче

[Nick S. Grechukh]

В сообщении от 22 июня 2006 10:45 Anton Gorlov написал(a):
> Dmitry V. Levin пишет:
> >> так как минимум будет возможность что-то, если понадобится оторвать из
> >> патчей, если будет необходимость.
> >
> > Для этого git-репозиторий больше подходит.  Оторвать часть кумулятивного
> > патча не так уж и просто.
>
> Кому как..мне например привычнее\удобнее видеть оригинальный исходник и
> патч к нему, который лежит рядом. Причём наиболее удобно -когла всё не 1
> куском в 1 гигантскомп атче,а кучка отдельных патчей..шде в 1 патче
> исправляется только 1 проблема..ао всех остальных другие. Как-то криво
> сказазал (/me только что проснулся), но думаю общий смысл понятен

он прав. хотя если забить на srpm...

Re: [devel] Q: .gear-rules и " апстримные " сорцы в отдельном бранче

[Anton Gorlov]

Nick S. Grechukh пишет:

> он прав. хотя если забить на srpm...

Да пжалста- в той же генте - патчи отдельно,сырцы отдельно. и никаких srpm.

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Anton Farygin]

Dmitry V. Levin wrote:
> On Thu, Jun 22, 2006 at 11:32:05AM +0400, Anton Gorlov wrote:
>> Dmitry V. Levin пишет:
>>> Я хочу понять, почему вам недостаточно положить в srpm тарбол,
>>> зачем всё-таки вы (я слышал как минимум от двоих) хотите паковать в srpm
>>> оригинальный тарбол + кумулятивный патч?
>> так как минимум будет возможность что-то, если понадобится оторвать из 
>> патчей, если будет необходимость.
> 
> Для этого git-репозиторий больше подходит.  Оторвать часть кумулятивного
> патча не так уж и просто.

Так он в любом случае из GIT генерится.. так что оторвать конечно лучше 
прямо сразу в GIT'е.

Rgds,
Rider

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Kirill A. Shutemov]

[-- Attachment #1: Type: text/plain, Size: 615 bytes --]

On 07:49 Thu 22 Jun, Dmitry V. Levin wrote:
> Я хочу понять, почему вам недостаточно положить в srpm тарбол,
> зачем всё-таки вы (я слышал как минимум от двоих) хотите паковать в srpm
> оригинальный тарбол + кумулятивный патч?

Что бы у того кто смотрит в srpm'ку был простой способ увидеть чем
отличается альтовская сборка от прочих.

-- 
Kirill A. Shutemov				Belarus, Minsk
E-mail:	k.shutemov (AT) sam-solutions.net
JID: kas (AT) altlinux.org
ICQ: 152302675

ps: куплю билеты на матч ldv--rider, т.к. пока изложенные ими
позиции существенно противоречат друг другу ;[
		-- mike in devel-kernel@

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 526 bytes --]

On Thu, Jun 22, 2006 at 10:48:35AM +0300, Kirill A. Shutemov wrote:
> On 07:49 Thu 22 Jun, Dmitry V. Levin wrote:
> > Я хочу понять, почему вам недостаточно положить в srpm тарбол,
> > зачем всё-таки вы (я слышал как минимум от двоих) хотите паковать в srpm
> > оригинальный тарбол + кумулятивный патч?
> 
> Что бы у того кто смотрит в srpm'ку был простой способ увидеть чем
> отличается альтовская сборка от прочих.

Надо смотреть слегка в будущее, когда srpm'ки как форма хранения будут
упразднены.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Anton Gorlov]

Dmitry V. Levin пишет:

> Надо смотреть слегка в будущее, когда srpm'ки как форма хранения будут
> упразднены.
Всё равно хотелось бы видеть волков отдельно от овц..то биш ванильные 
сырцы +внешние патчи.

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Kirill Maslinsky]

[-- Attachment #1: Type: text/plain, Size: 680 bytes --]

> > Надо смотреть слегка в будущее, когда srpm'ки как форма хранения будут
> > упразднены.
> Всё равно хотелось бы видеть волков отдельно от овц..то биш ванильные 
> сырцы +внешние патчи.

И это прекрасно можно обеспечить без всякого srpm'а: просто в том
месте, куда привыкли ходить мантейнеры ванильных тарболлов за патчами, 
будет висеть большое объявление: теперь тут ничего нет, а за патчами
ходите вот тууда (gitweb, что-то ещё более удобное, whatever). 

Поэтому попытка обеспечить такую форму доступа к патчам через srpm 
с помощью gear похожа на преждевременную оптимизацию на благо 
гипотетических лиц.

-- 
Kirill Maslinsky
ALT Linux Documentation Team

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 326 bytes --]

On Thu, Jun 22, 2006 at 12:06:08PM +0400, Anton Gorlov wrote:
> Dmitry V. Levin пишет:
> 
> > Надо смотреть слегка в будущее, когда srpm'ки как форма хранения будут
> > упразднены.
> Всё равно хотелось бы видеть волков отдельно от овц..то биш ванильные 
> сырцы +внешние патчи.

Где хотелось бы видеть?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Anton Gorlov]

Dmitry V. Levin пишет:

>>> Надо смотреть слегка в будущее, когда srpm'ки как форма хранения будут
>>> упразднены.
>> Всё равно хотелось бы видеть волков отдельно от овц..то биш ванильные 
>> сырцы +внешние патчи.
> Где хотелось бы видеть?

на диске в директории с сырцами (то что сейчас SRPMS). В остальных 
случаях фтп\http.

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 794 bytes --]

* Dmitry V. Levin <ldv@> [060622 07:59]:
> Я хочу понять, почему вам недостаточно положить в srpm тарбол,
> зачем всё-таки вы (я слышал как минимум от двоих) хотите паковать в srpm
> оригинальный тарбол + кумулятивный патч?
Ну как-то неаакуратненько класть тарбол с патчеными сорцами.
Сложно посмотреть отличия нашей сборки.

> Первоначально я исходил из идеи воспроизводимости, т.е. из того, что
> результат работы "gear --tree-ish=ID" будет одинаковым при одинаковых ID.
> Если в правилах для gear можно будет указывать произвольные tree-ish, то
> это моё предположение не будет выполнено.
В указанном tree-ish лежит .gear-rules, где "произвольный
tree-ish" задан в виде тега в бранче "upstream".  Так что
воспроизводимость при таком подходе будет.

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1100 bytes --]

On Thu, Jun 22, 2006 at 12:14:07PM +0400, Alexey I. Froloff wrote:
> * Dmitry V. Levin <ldv@> [060622 07:59]:
> > Я хочу понять, почему вам недостаточно положить в srpm тарбол,
> > зачем всё-таки вы (я слышал как минимум от двоих) хотите паковать в srpm
> > оригинальный тарбол + кумулятивный патч?
> Ну как-то неаакуратненько класть тарбол с патчеными сорцами.
> Сложно посмотреть отличия нашей сборки.

Если нет srpm'ов как формы хранения, это что-нибудь даёт?

> > Первоначально я исходил из идеи воспроизводимости, т.е. из того, что
> > результат работы "gear --tree-ish=ID" будет одинаковым при одинаковых ID.
> > Если в правилах для gear можно будет указывать произвольные tree-ish, то
> > это моё предположение не будет выполнено.
> В указанном tree-ish лежит .gear-rules, где "произвольный
> tree-ish" задан в виде тега в бранче "upstream".  Так что
> воспроизводимость при таком подходе будет.

Нет, не будет.  Этот бранч, да и вообще любой tree-ish может измениться
неконтролируемым образом по отношению к тому месту в .gear-rules, где
на него ссылаются.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Kirill A. Shutemov]

[-- Attachment #1: Type: text/plain, Size: 919 bytes --]

On 12:26 Thu 22 Jun, Dmitry V. Levin wrote:
> On Thu, Jun 22, 2006 at 12:14:07PM +0400, Alexey I. Froloff wrote:
> > * Dmitry V. Levin <ldv@> [060622 07:59]:
> > > Я хочу понять, почему вам недостаточно положить в srpm тарбол,
> > > зачем всё-таки вы (я слышал как минимум от двоих) хотите паковать в srpm
> > > оригинальный тарбол + кумулятивный патч?
> > Ну как-то неаакуратненько класть тарбол с патчеными сорцами.
> > Сложно посмотреть отличия нашей сборки.
> 
> Если нет srpm'ов как формы хранения, это что-нибудь даёт?

Есть планы отказа от rpm?


-- 
Kirill A. Shutemov				Belarus, Minsk
E-mail:	k.shutemov (AT) sam-solutions.net
JID: kas (AT) altlinux.org
ICQ: 152302675

> Нет, это sandman его монтирует внутрь через bind, а hasher вычисляет
> список файлов снаружи и копирует их внутрь.
То есть исходники внутри чрута получить никак нельзя?
Это противоречит GPL. :)
		-- at in devel@

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

On Thu, Jun 22, 2006 at 11:53:00AM +0300, Kirill A. Shutemov wrote:
> On 12:26 Thu 22 Jun, Dmitry V. Levin wrote:
> > On Thu, Jun 22, 2006 at 12:14:07PM +0400, Alexey I. Froloff wrote:
> > > * Dmitry V. Levin <ldv@> [060622 07:59]:
> > > > Я хочу понять, почему вам недостаточно положить в srpm тарбол,
> > > > зачем всё-таки вы (я слышал как минимум от двоих) хотите паковать в srpm
> > > > оригинальный тарбол + кумулятивный патч?
> > > Ну как-то неаакуратненько класть тарбол с патчеными сорцами.
> > > Сложно посмотреть отличия нашей сборки.
> > 
> > Если нет srpm'ов как формы хранения, это что-нибудь даёт?
> 
> Есть планы отказа от rpm?

Разве я недостаточно ясно высказывался?  После перехода на git в качестве
способа хранения исходного кода srpm-пакеты будут выполнять лишь
транспортную функцию, и тогда можно будет отказаться от их хранения.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Anton Farygin]

Dmitry V. Levin wrote:
> On Thu, Jun 22, 2006 at 11:53:00AM +0300, Kirill A. Shutemov wrote:
>> On 12:26 Thu 22 Jun, Dmitry V. Levin wrote:
>>> On Thu, Jun 22, 2006 at 12:14:07PM +0400, Alexey I. Froloff wrote:
>>>> * Dmitry V. Levin <ldv@> [060622 07:59]:
>>>>> Я хочу понять, почему вам недостаточно положить в srpm тарбол,
>>>>> зачем всё-таки вы (я слышал как минимум от двоих) хотите паковать в srpm
>>>>> оригинальный тарбол + кумулятивный патч?
>>>> Ну как-то неаакуратненько класть тарбол с патчеными сорцами.
>>>> Сложно посмотреть отличия нашей сборки.
>>> Если нет srpm'ов как формы хранения, это что-нибудь даёт?
>> Есть планы отказа от rpm?
> 
> Разве я недостаточно ясно высказывался?  После перехода на git в качестве
> способа хранения исходного кода srpm-пакеты будут выполнять лишь
> транспортную функцию, и тогда можно будет отказаться от их хранения.

В любом случае SRPMS придётся выкладывать на CDROM/ftp ?

Rgds,
Rider

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 463 bytes --]

* Dmitry V. Levin <ldv@> [060622 12:30]:
> Если нет srpm'ов как формы хранения, это что-нибудь даёт?
Тогда формой чего является sprm?

> Нет, не будет.  Этот бранч, да и вообще любой tree-ish может измениться
> неконтролируемым образом по отношению к тому месту в .gear-rules, где
> на него ссылаются.
Точно также может измениться и сам ID.  Почему он может так
"вдруг" измениться (кроме случая когда указан како-ньдь HEAD)?

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 910 bytes --]

On Thu, Jun 22, 2006 at 01:10:24PM +0400, Alexey I. Froloff wrote:
> * Dmitry V. Levin <ldv@> [060622 12:30]:
> > Если нет srpm'ов как формы хранения, это что-нибудь даёт?
> Тогда формой чего является sprm?

Формой транспортировки и формой обработки.
Короче говоря, внутренней формой.  В перспективе.

> > Нет, не будет.  Этот бранч, да и вообще любой tree-ish может измениться
> > неконтролируемым образом по отношению к тому месту в .gear-rules, где
> > на него ссылаются.
> Точно также может измениться и сам ID.

Который ID?  Тот, что передаётся в качестве параметра утилите gear?
Считается, что запускающий gear контролирует передаваемые параметры,
в отличие от содержимого репозитория.

> Почему он может так
> "вдруг" измениться (кроме случая когда указан како-ньдь HEAD)?

Просто потому что ничего не мешает ему измениться без нарушения
целостности git-репозитория.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 855 bytes --]

* Dmitry V. Levin <ldv@> [060622 15:30]:
> > Точно также может измениться и сам ID.
> Который ID?  Тот, что передаётся в качестве параметра утилите gear?
Он самый.

> Считается, что запускающий gear контролирует передаваемые параметры,
> в отличие от содержимого репозитория.
Каким образом можно контролировать передаваемые параметры,
которые в свою очередь зависят от содержимого репозитария?  Самый
главный вопрос - как проверить что "запускающий gear" это
контролирует?

> > Почему он может так
> > "вдруг" измениться (кроме случая когда указан како-ньдь HEAD)?
> Просто потому что ничего не мешает ему измениться без нарушения
> целостности git-репозитория.
Я всё-таки не понимаю, чем ситуация с одним tree-ish в корне
отличается от ситуации с двумя tree-ish, где второй зависит от
совержимого первого?

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2071 bytes --]

On Thu, Jun 22, 2006 at 06:56:47PM +0400, Alexey I. Froloff wrote:
> * Dmitry V. Levin <ldv@> [060622 15:30]:
> > > Точно также может измениться и сам ID.
> > Который ID?  Тот, что передаётся в качестве параметра утилите gear?
> Он самый.
> 
> > Считается, что запускающий gear контролирует передаваемые параметры,
> > в отличие от содержимого репозитория.
> Каким образом можно контролировать передаваемые параметры,
> которые в свою очередь зависят от содержимого репозитария?

Их можно проверять, полагаясь на целостность предварительно проверенного
репозитория.  Если собирать по тегу, то можно проверить этот тэг с тем,
чтобы точно знать, что собираешь.

> Самый
> главный вопрос - как проверить что "запускающий gear" это
> контролирует?

Это личное дело запускающего, для меня важно предоставить такую
возможность.

> > > Почему он может так
> > > "вдруг" измениться (кроме случая когда указан како-ньдь HEAD)?
> > Просто потому что ничего не мешает ему измениться без нарушения
> > целостности git-репозитория.
> Я всё-таки не понимаю, чем ситуация с одним tree-ish в корне
> отличается от ситуации с двумя tree-ish, где второй зависит от
> совержимого первого?

Это просто:  при нынешней схеме переданный утилите gear tree-ish
(идентификатор, однозначно идентифицирующий объект типа tree) однозначно
определяет результат вне зависимости от того, как настроен репозиторий.
Если разрешить в правилах для gear использовать ссылки на объекты, не
связанные с переданным утилите gear идентификатором (если говорить строго,
я имею в виду такие идентификаторы, изменение которых не нарушает
валидность tree-ish), то эта однозначность не будет гарантирована.

По моему, это очень плохо, если результат сборки архива по одному и тому же
tree-ish, однозначно идентифицирующему объект, может отличаться от запуска
к запуску.  Речь идёт даже не столько о диверсии, сколько об элементарной
операции замены используемого в правилах тэга (git-tag -f).

Не знаю, может и есть способ как-то привязать эти тэги к tree-ish.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 302 bytes --]

* Dmitry V. Levin <ldv@> [060622 22:22]:
> Не знаю, может и есть способ как-то привязать эти тэги к tree-ish.
Значит надо дать возможность использовать tree-ish в .gear-rules
для tar* и diff* с проверкой что это tree object.  Правда пока не
очень понятен синтаксис...

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1681 bytes --]

On Thu, Jun 22, 2006 at 07:49:32AM +0400, Dmitry V. Levin wrote:
> Hi,
> 
> On Tue, Jun 20, 2006 at 07:19:21PM +0400, Alexey I. Froloff wrote:
> > Идея в следующем:
> > 
> > "Апстримные" сорцы лежат в бранче, например upstream, апдейтятся
> > там некоторым образом (git pull, git svn fetch, git cvsimport -
> > whatever).  В рабочем бранче лежат мои патченые исходники, спеки
> > и так далее.  gear пакует бранч upstream в тарбол и делает
> > git-diff-tree между upstream и некоторым tree-ish.  Почему
> > tree-ish, а не HEAD?  А потому что я обычно делаю
> > git-mv -k * .* %name, и вот этот %name мне и надо diff'ать.
> 
> Я хочу понять, почему вам недостаточно положить в srpm тарбол,
> зачем всё-таки вы (я слышал как минимум от двоих) хотите паковать в srpm
> оригинальный тарбол + кумулятивный патч?

Ты предлагаешь отказаться от pristine source внутри src.rpm?
Что тогда делать с GPL 2a?  

    a) You must cause the modified files to carry prominent notices
    stating that you changed the files and the date of any change.

"Патчи отдельно" как раз направлено на выполнение требования GPL 2a.  
Потому что можно определить происхождение патча, список модифицируемых
файлов и дату модификации.  Это требование кажется мне достаточно
разумным: оно обоюдно учитывает права (интересы) автора софта, автора
модификаций и получателя софта.

В таком случае src.rpm официально нельзя распространять.  Тогда
исходники надо распространять как-то ещё, чтобы существовал равно
простой способ получить оригинальную версию и кумулятивный патч
_для данной сборки_ пакета.  Может быть публикацию/распространение
git репозитария можно признать таковым.

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2101 bytes --]

On Sat, Jun 24, 2006 at 08:22:45AM +0400, Alexey Tourbin wrote:
> On Thu, Jun 22, 2006 at 07:49:32AM +0400, Dmitry V. Levin wrote:
> > On Tue, Jun 20, 2006 at 07:19:21PM +0400, Alexey I. Froloff wrote:
> > > Идея в следующем:
> > > 
> > > "Апстримные" сорцы лежат в бранче, например upstream, апдейтятся
> > > там некоторым образом (git pull, git svn fetch, git cvsimport -
> > > whatever).  В рабочем бранче лежат мои патченые исходники, спеки
> > > и так далее.  gear пакует бранч upstream в тарбол и делает
> > > git-diff-tree между upstream и некоторым tree-ish.  Почему
> > > tree-ish, а не HEAD?  А потому что я обычно делаю
> > > git-mv -k * .* %name, и вот этот %name мне и надо diff'ать.
> > 
> > Я хочу понять, почему вам недостаточно положить в srpm тарбол,
> > зачем всё-таки вы (я слышал как минимум от двоих) хотите паковать в srpm
> > оригинальный тарбол + кумулятивный патч?
> 
> Ты предлагаешь отказаться от pristine source внутри src.rpm?

Я предлагаю отказаться от src.rpm.

> Что тогда делать с GPL 2a?  
> 
>     a) You must cause the modified files to carry prominent notices
>     stating that you changed the files and the date of any change.
> 
> "Патчи отдельно" как раз направлено на выполнение требования GPL 2a.  
> Потому что можно определить происхождение патча, список модифицируемых
> файлов и дату модификации.  Это требование кажется мне достаточно
> разумным: оно обоюдно учитывает права (интересы) автора софта, автора
> модификаций и получателя софта.
> 
> В таком случае src.rpm официально нельзя распространять.

Так ведь необходимости в этом не будет.  Зачем распространять то, что не
нужно?

> Тогда
> исходники надо распространять как-то ещё, чтобы существовал равно
> простой способ получить оригинальную версию и кумулятивный патч
> _для данной сборки_ пакета.  Может быть публикацию/распространение
> git репозитария можно признать таковым.

Конечно, можно.  Если бы git-репозиторий не предоставлял той
возможности, о необходимости которой ты говоришь, то в таком репозитории
не было бы смысла.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 650 bytes --]

On Sat, Jun 24, 2006 at 04:40:16PM +0400, Dmitry V. Levin wrote:
> > > Я хочу понять, почему вам недостаточно положить в srpm тарбол,
> > > зачем всё-таки вы (я слышал как минимум от двоих) хотите паковать в srpm
> > > оригинальный тарбол + кумулятивный патч?
> > 
> > Ты предлагаешь отказаться от pristine source внутри src.rpm?
> Я предлагаю отказаться от src.rpm.

Слишком радикально.  Что тогда делать с apt-get source?
И перестанет работать qa-robot packages. :)

Впрочем, я не против.  С развернутыми исходниками работать удобнее.
По крайней мере представляется неудобным класть в SCM патчи и потом
работать с "диффами на патчи".

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1254 bytes --]

On Sun, Jun 25, 2006 at 01:59:46AM +0400, Alexey Tourbin wrote:
> On Sat, Jun 24, 2006 at 04:40:16PM +0400, Dmitry V. Levin wrote:
> > > > Я хочу понять, почему вам недостаточно положить в srpm тарбол,
> > > > зачем всё-таки вы (я слышал как минимум от двоих) хотите паковать в srpm
> > > > оригинальный тарбол + кумулятивный патч?
> > > 
> > > Ты предлагаешь отказаться от pristine source внутри src.rpm?
> > Я предлагаю отказаться от src.rpm.
> 
> Слишком радикально.

Я же не предлагаю сделать это всем прямо сейчас.
Я предлагаю начинать двигаться в направлении перехода от srpm к
git-репозиторию как форме хранения исходного кода.

> Что тогда делать с apt-get source?

А зачем нужен apt-get source, когда есть hasher?

> И перестанет работать qa-robot packages. :)

Думаю, что это поправимо.

> Впрочем, я не против.  С развернутыми исходниками работать удобнее.

Я тоже так думаю.

> По крайней мере представляется неудобным класть в SCM патчи и потом
> работать с "диффами на патчи".

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


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1101 bytes --]

On Sun, Jun 25, 2006 at 02:26:12AM +0400, Dmitry V. Levin wrote:
> > По крайней мере представляется неудобным класть в SCM патчи и потом
> > работать с "диффами на патчи".
> 
> На переходном этапе или в режиме совместимости можно и так, хотя это
> действительно не намного удобнее чем работать с srpm'ами.
> Лично я пока не форсирую перевод своих пакетов в полностью развёрнутую
> форму хранения.

В общем я примерно понял как устроен .git/ но не понял как с ним
работать.  Есть несколько мелких вопросов.

git-srpmimport распаковывает тарболл в отдельный каталог.
Если переходить на полностью развернутую форму хранения, тогда
отдельный каталог не нужен.  Как импортировать всё сразу в одном
каталоге, т.е. развернуть тарболл а потом плюхнуть туда оставшиеся
sources и исходники?

Как работать с апстримом?  Я так понял нужно сделать отдельный бранч
origin и вливать туда pristine source.  А все свои изменения
(более-менее окончательные) держать в бранче master.  После очередного
вливания в origin, как протащить случившиеся там изменения в master?
git rebase origin master?

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]

On Sun, Jun 25, 2006 at 04:57:40AM +0400, Alexey Tourbin wrote:
> On Sun, Jun 25, 2006 at 02:26:12AM +0400, Dmitry V. Levin wrote:
> > > По крайней мере представляется неудобным класть в SCM патчи и потом
> > > работать с "диффами на патчи".
> > 
> > На переходном этапе или в режиме совместимости можно и так, хотя это
> > действительно не намного удобнее чем работать с srpm'ами.
> > Лично я пока не форсирую перевод своих пакетов в полностью развёрнутую
> > форму хранения.
> 
> В общем я примерно понял как устроен .git/ но не понял как с ним
> работать.  Есть несколько мелких вопросов.
> 
> git-srpmimport распаковывает тарболл в отдельный каталог.
> Если переходить на полностью развернутую форму хранения, тогда
> отдельный каталог не нужен.  Как импортировать всё сразу в одном
> каталоге, т.е. развернуть тарболл а потом плюхнуть туда оставшиеся
> sources и исходники?

Не знаю, не пробовал.  RTFS, патчи приветствуются.

> Как работать с апстримом?  Я так понял нужно сделать отдельный бранч
> origin и вливать туда pristine source.  А все свои изменения
> (более-менее окончательные) держать в бранче master.  После очередного
> вливания в origin, как протащить случившиеся там изменения в master?
> git rebase origin master?

Я использую обычный git-pull.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Q: .gear-rules É "ÁÐÓÔÒÉÍÎÙÅ" ÓÏÒÃÙ × ÏÔÄÅÌØÎÏÍ ÂÒÁÎÞÅ

[Andrey Khavryuchenko]

Dmitry,

"DVL" == Dmitry V Levin wrote:

 DVL> On Sun, Jun 25, 2006 at 01:59:46AM +0400, Alexey Tourbin wrote:
 >> Что тогда делать с apt-get source?

 DVL> А зачем нужен apt-get source, когда есть hasher?

Он уже научился работать с ftp-репозиторием?

-- 
Andrey V Khavryuchenko            
Software Development Company http://www.kds.com.ua/

Re: [devel] Q: .gear-rules и "апстримные" сорцы в отдельном бранче

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 459 bytes --]

On Sun, Jun 25, 2006 at 10:16:47AM +0300, Andrey Khavryuchenko wrote:
> "DVL" == Dmitry V Levin wrote:
>  DVL> On Sun, Jun 25, 2006 at 01:59:46AM +0400, Alexey Tourbin wrote:
>  >> Что тогда делать с apt-get source?
> 
>  DVL> А зачем нужен apt-get source, когда есть hasher?
> 
> Он уже научился работать с ftp-репозиторием?

В принципе да.  Говорят, что есть какие-то сложности, но пока я этим
не пользуюсь, ничего сказать не могу.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Q: .gear-rules É "ÁÐÓÔÒÉÍÎÙÅ" ÓÏÒÃÙ × ÏÔÄÅÌØÎÏÍ ÂÒÁÎÞÅ

[Andrey Khavryuchenko]

Dmitry,

"DVL" == Dmitry V Levin wrote:

 DVL> On Sun, Jun 25, 2006 at 10:16:47AM +0300, Andrey Khavryuchenko wrote:
 >> "DVL" == Dmitry V Levin wrote:
 DVL> А зачем нужен apt-get source, когда есть hasher?
 >> 
 >> Он уже научился работать с ftp-репозиторием?

 DVL> В принципе да.  Говорят, что есть какие-то сложности, но пока я этим
 DVL> не пользуюсь, ничего сказать не могу.

Tnx, нужно будет попробовать.

-- 
Andrey V Khavryuchenko            
Software Development Company http://www.kds.com.ua/