Bug 32674 - unhandy referring to commits with @release@ tags in .gear/rules
: unhandy referring to commits with @release@ tags in .gear/rules
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/xen)
: unstable
: all Linux
: P3 enhancement
Assigned To:
:
: http://git.altlinux.org/people/shadri...
:
:
:
  Show dependency tree
 
Reported: 2016-10-27 18:56 by
Modified: 2016-11-16 09:35 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2016-10-27 18:56:42
xen-4.7.0-alt3

Добрый день!

Увидел, что в пакете xen в (.gear/rules)[1] используется переменная @release@  
ради ссылок на избранные коммиты (посредством тегов). Я сталкивался на практике
с тем, что такие правила очень неудобны, даже если всего один такой тег
упомянут в .gear/rules: при каждом релизе пакета в Sisyphus придётся создавать
эти теги, а потом запускать gear-update-tag -a, а потом делать коммит и тег для
сборки.

[1]:
http://git.altlinux.org/people/shadrinov/packages/?p=xen.git;a=blob;f=.gear/rules;h=72aa9a17d4997f277ef121b4b7213b580f9cd449;hb=616640bb17ba53037ab35bf4b9da47105d5a6bad

Я думаю, гораздо удобнее так:

ссылаться на тег сборки с помощью ".", а на другие важные коммиты с исходниками
с помощью ссылки (лучше бранч, а не тег) с неизменным именем, отражающим смысл,
без переменной @release@;

когда нужно начать использовать другие исходники, передвигать эту ссылку
(бранч), и запускать gear-update-tag -a, делать коммит.

Так gear-update-tag -a будет обновлять записи о том, какие коммиты
использовать, только когда коммиты реально поменялись (а не всякий раз), что
удобнее для восприятия и для работы роботов. (Можно даже избранные сохранять, а
не все.)

(Робот пришёл, поправил спек, например, в changelog добавил запись "rebuild"
или т.п. и хочет собрать всё ровно из тех же исходников, что и предыдущий
релиз. Он не может знать, как расставить новые теги и что нужно запустить
gear-update-tag -a и что старые сохранённые .gear/tags/ недействительны.)

Вот такой совет.
------- Comment #1 From 2016-10-27 19:25:25 -------
Понял, переделаю.
А как лучше поступать, если исходники, взятые из стабильного upstream, не
собираются с самого последнего коммита, как в данном случае получилось с
mini-os, приходится откатиться на пару-тройку коммитов назад... как лучше
поступить в таком случае?
Правильно ли я понимаю, что нет смысла сохранять все тэги - достаточно того,
что сохранилось в .gear/tags?
------- Comment #2 From 2016-10-27 20:07:44 -------
Поправка: Более правильное и понятное название для gear-update-tag --
gear-store-tags. Лучше к нему привыкать.

(In reply to comment #1)
> Понял, переделаю.

Спасибо заранее!

> А как лучше поступать, если исходники, взятые из стабильного upstream, не
> собираются с самого последнего коммита, как в данном случае получилось с
> mini-os, приходится откатиться на пару-тройку коммитов назад... как лучше
> поступить в таком случае?

(Я не знаком толком с историей сборки.) Мне кажется, в таком случае можно
завести свою ветку со своим названием, которая будет указывать на те исходники,
которые собираются. И её имя записать в .gear/rules. Название может быть просто
upstream (или что-то ещё по вкусу).

Мне кажется, я бы делал fetch, получал remote-tracking branches вида
some-upstream-name/master и т.п. Мог бы для работы с ними сделать из них
checkout в локальные ветки вида some-upstream/master и т.п. или просто master.
А для сборки брал бы исходники из специально заведённой для этого ветки,
скажем, upstream. Тут важно только, чтобы её имя не мешало всей остальной
работе. Например, иметь одновременно upstream/master и upstream не получится. В
какие-то моменты upstream может совпадать с some-upstream/master...

Т.е. в описанной ситуации команды были бы такими примерно:

git fetch some-upstream
git checkout -b upstream some-upstream/master
# откатываемся:
git reset --hard HEAD^^

# Готовим сборку (скажем, в  ветке alt или master):
git checkout alt
# можно подцепить сразу всю историю апстрима, если хочется
git merge -s ours some-upstream/master

# Готовимся к очередному релизу:
# в .gear/rules написано про upstream, поэтому:
gear-store-tags -a
# редактируем .spec для очередного релиза:
git commit -a # или почти то же самое: gear-commit -a
gear-create-tag

> Правильно ли я понимаю, что нет смысла сохранять все тэги - достаточно того,
> что сохранилось в .gear/tags?

Не понял вопроса. Для чего "достаточно"? Кроме тега, который даётся сборочнице
-- все остальные теги в Git только для Вас. Так что как Вам удобно.

Соответствие между именами, использованными в .gear/rules, и номерами коммитов
сохраняется в .gear/tags (или куда-то там) при помощи gear-store-tags -a в тот
момент, когда Вы хотите его зафиксировать. (Оно нужно, чтобы из коммитов по
правилам .gear/rules во время сборки были бы сделаны tarball-ы и diff-ы.)
------- Comment #3 From 2016-10-27 20:13:10 -------
(In reply to comment #2)

> (Я не знаком толком с историей сборки.) Мне кажется, в таком случае можно
> завести свою ветку со своим названием, которая будет указывать на те исходники,
> которые собираются. И её имя записать в .gear/rules. Название может быть просто
> upstream (или что-то ещё по вкусу).

Потом, для сборки новой версии, имя ветки останется неизменным, но будет
указывать на другой коммит, который будет собираться. Как-то так:

git fetch some-upstream
git checkout upstream
git merge --ff-only some-upstream/master
# или:
git reset --hard some-upstream/master

# Готовим очередную сборку (так же, как в прошлый; но с обновлённым upstream):
git checkout alt
git merge -s ours upstream
gear-store-tags -a
# редактируем .spec
gear-commit -a
gear-create-tag
------- Comment #4 From 2016-10-27 20:21:15 -------
Да, пока все именно так и делал... только не удалял из истории commit'ы (reset
HEAD~2), а вешал на нужный commit соответствующий tag, пробую сейчас привести
все в рекомендуемое состояния, но пока застопорился на том, что не могу найти
как в .gear/rules сослаться на branch (на голову) без tag..
------- Comment #5 From 2016-10-27 20:34:23 -------
(In reply to comment #4)
> Да, пока все именно так и делал... только не удалял из истории commit'ы (reset
> HEAD~2), а вешал на нужный commit соответствующий tag, пробую сейчас привести

Совсем "удалять" необязательно, если не хочется. Можно смёрджить в сборочный
тег всю историю.

> все в рекомендуемое состояния, но пока застопорился на том, что не могу найти
> как в .gear/rules сослаться на branch (на голову) без tag..

Так же. Просто имя бранча. Нет разницы между тегами и бранчами.

Кажется, это не очень ясно документировано в gear. Сам поначалу недоумевал...
------- Comment #6 From 2016-10-27 20:40:51 -------
Получается так:
[shadrinov@builder xen]$ git branch
  alt/4.4
  alt/4.7
* master
  mini-os/4.7
...

.gear/rules:
tar.bz2: RELEASE-@version@:. name=@name@-@version@
diff: RELEASE-@version@:. alt/4.7:.
...

[shadrinov@builder xen]$ gear-hsh -v -- -v
mkdir: создан каталог «/tmp/.private/shadrinov/gear.2pRCSGC8/out»
gear: Extracted archive: xen-4.7.0.tar
gear: Compressed file `xen-4.7.0.tar' using `bzip2 -9'
gear: .gear/rules line 2: Name "alt/4.7" not found in tag list
gear: .gear/rules line 2: Invalid new tree: 
...

.gear/rules:
tar.bz2: RELEASE-@version@:. name=@name@-@version@
diff: RELEASE-@version@:. alt/4.7
...

[shadrinov@builder xen]$ gear-hsh -v -- -v
mkdir: создан каталог «/tmp/.private/shadrinov/gear.0uakheMi/out»
gear: Extracted archive: xen-4.7.0.tar
gear: Compressed file `xen-4.7.0.tar' using `bzip2 -9'
gear: .gear/rules line 2: tree "alt/4.7" not found in "HEAD"
...
------- Comment #7 From 2016-10-27 20:53:37 -------
(In reply to comment #5)

> > но пока застопорился на том, что не могу найти
> > как в .gear/rules сослаться на branch (на голову) без tag..
> 
> Так же. Просто имя бранча. Нет разницы между тегами и бранчами.
> 
> Кажется, это не очень ясно документировано в gear. Сам поначалу недоумевал...

Ага, перечитал man gear-rules и понял, что это вообще не совсем его дело это
документировать. Там всё довольно точно написано. Просто gear ведь имеет дело с
уже сохранённым состоянием внутри дерева (внтури коммита  сборочного тега),
поэтому он берёт имена и значения из своего сохранённого списка; они называются
там "a name  of a tag  listed in  the tag list":


     The base_tree part can be in one of the following forms:
         A single  period character "." specifies  the main tree.
         In most cases just  omitting the "base_tree:" part gives
         the same effect; adding ".:" explicitly is required only
         if  the  path_in_tree  part   itself  contains  the  ":"
         character.
         A full SHA-1 object name of a commit (40 hex characters)
         specifies the  root tree of that  commit.  The specified
         commit must be an ancestor of the main commit.
         A name  of a tag  listed in  the tag list  specifies the
         root tree of the commit  pointed to by the specified tag
         (directly or indirectly through a chain of tag objects).
         The specified  commit must  be an  ancestor of  the main
         commit, and all tag objects  in the chain must be stored
         in the tag directory.

Это уже особенность gear-store-tags, что она, когда готовит этот tag list для
gear, учитывает и бранчи, и теги, найденные по искомым именам. А там
документация скудная.

Может, нужна более явная отсылка из мана по gear-rules к gear-store-tags, а в
мане по gear-store-tags более подробное разъяснение всех возможностей...
------- Comment #8 From 2016-10-27 20:54:49 -------
Понял, просто забыл про gear-store-tag... Прошу прощения... Теперь вроде ничего
не мешает поправить все...
------- Comment #9 From 2016-10-27 20:56:55 -------
(In reply to comment #8)
> Понял, просто забыл про gear-store-tag... Прошу прощения... Теперь вроде ничего
> не мешает поправить все...

Ага, как раз хотел спросить про gear-store-tags -a.

Во-втором варианте rules было неправильно, двоеточия не хватало.
------- Comment #10 From 2016-11-16 09:35:28 -------
Рекомендации применены, спасибо