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/ недействительны.) Вот такой совет.
Понял, переделаю. А как лучше поступать, если исходники, взятые из стабильного upstream, не собираются с самого последнего коммита, как в данном случае получилось с mini-os, приходится откатиться на пару-тройку коммитов назад... как лучше поступить в таком случае? Правильно ли я понимаю, что нет смысла сохранять все тэги - достаточно того, что сохранилось в .gear/tags?
Поправка: Более правильное и понятное название для 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-ы.)
(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
Да, пока все именно так и делал... только не удалял из истории commit'ы (reset HEAD~2), а вешал на нужный commit соответствующий tag, пробую сейчас привести все в рекомендуемое состояния, но пока застопорился на том, что не могу найти как в .gear/rules сослаться на branch (на голову) без tag..
(In reply to comment #4) > Да, пока все именно так и делал... только не удалял из истории commit'ы (reset > HEAD~2), а вешал на нужный commit соответствующий tag, пробую сейчас привести Совсем "удалять" необязательно, если не хочется. Можно смёрджить в сборочный тег всю историю. > все в рекомендуемое состояния, но пока застопорился на том, что не могу найти > как в .gear/rules сослаться на branch (на голову) без tag.. Так же. Просто имя бранча. Нет разницы между тегами и бранчами. Кажется, это не очень ясно документировано в gear. Сам поначалу недоумевал...
Получается так: [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" ...
(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 более подробное разъяснение всех возможностей...
Понял, просто забыл про gear-store-tag... Прошу прощения... Теперь вроде ничего не мешает поправить все...
(In reply to comment #8) > Понял, просто забыл про gear-store-tag... Прошу прощения... Теперь вроде ничего > не мешает поправить все... Ага, как раз хотел спросить про gear-store-tags -a. Во-втором варианте rules было неправильно, двоеточия не хватало.
Рекомендации применены, спасибо
