[devel] Еще одно HOWTO про сборку пакета в git.alt и интеграцию с upstream scm
Alexey Tourbin
=?iso-8859-1?q?at_=CE=C1_altlinux=2Eru?=
Вт Апр 10 00:37:55 MSD 2007
On Tue, Apr 10, 2007 at 12:01:51AM +0400, Dmitry V. Levin wrote:
> On Mon, Apr 09, 2007 at 11:52:27PM +0400, Alexey Tourbin wrote:
> > On Mon, Apr 09, 2007 at 10:06:52PM +0400, Eugene Prokopiev wrote:
> > > http://wiki.sisyphus.ru/devel/gear/ImportUpstreamVBranch
> > > http://wiki.sisyphus.ru/devel/gear/ImportSeparateUpstream
> >
> > В общем, я бы не стал делать, как там написано.
>
> Ты имеешь в виду первый рецепт (когда есть upstream scm) или второй рецепт
> (когда есть только upstream tarball)?
У мутта 1.5 вроде тоже есть git.
В случае с тарболлами иногда удобнее деражть содержимое тарболла в
подкаталоге, а патчи держать отдельно; а иногда удобнее прикладывать
патчи к тарболлу, тогда подкаталог не нужен (а spec положить прямо в
каталог, это не криминально).
Ну, если тарболлы выходят достаточно часто, и если изменения в них
не очень большие, тогда есть надежда на достаточно простой merge с
новым тарболлом, и можно патчи прикладывать. Если же в в каждом
очередном тарболле всё переделывают, и в результате мержа получается
много конфилктов, тогда проще держать патчи отдельно. Также это
касается некоторых случаев, когда большинство патчей имортируется
откуда-то ещё, например из федоры.
Я например не знаю, как мне сейчас с netpbm в этом отношении быть.
Всё время откладываю его в долгий ящик. :(
> > Могу подробнее объяснть, как я бы сделал, если не понятно.
> Пока не понятно. ;)
Допустим что есть апстримный project.git, в котором есть таги 1.1, 1.2,
1.3 и основной бранч master, который содержит эти таги. (На самом деле не
важно, git это или git-svnimport или git-cvsimport.)
Допустим, что у нас есть project-1.1.src.rpm и project-1.2.src.rpm.
Мы хотим импортировать эти src.rpm'ы и собрать новый релиз 1.3 (или
прямо origin).
Я бы имортировал вот как. Сначала клонируем апстрим, имеем бранч
origin.
Преподолжим, что в src.rpm'ах есть всего один "большой" тарболл с
подкаталогом, а других тарболлов нет (но, возможно есть патчи).
Тогда можно применить модифицированный gear-srpmimport, который
не создает подкаталога, чтобы избежать перемещения файлов.
Импортируем src.rpm'ы, привязывая их к апстримным тагам.
$ git-checkout -b srpms 1.1
$ gear-srpmimport project-1.1.src.rpm
$ git-branch foo 1.2
$ git-pull --no-commit -s ours . foo && git-branch -D foo
$ gear-srpmimport project-1.2.src.rpm
Здесь происходит merge апстримного тага 1.2 и нашей предыдущей сборки
1.1-alt1. С первого раза этот трюк, наверное, сложно понять. К
сожалению, я не знаю, как это можно предельно понятно объяснить.
Теперь мы стоим на бранче srpms, и на него показывает таг 1.2-alt1.
Перименовываем бранч srpms в бранч master и продолжаем с ним работать
как с основным бранчем для подготовки пакетов.
$ git-branch -D master
$ git-checkout -b master srpms
$ git-branch -D srpms
Нужно проверить, что git-diff 1.2..1.2-alt1 показывает только *.spec и
.gear-rules (кроме, быть может, $Id$ и прочей мишуры).
Теперь можно приложить патчи, если они есть, прямо к дереву исходников.
Если приложили патчи, желательно добавить %release в название тарболла и
в .gear-rules. Также желательно разжать тарболл, чтобы был просто *.tar.
Дальше делаем
$ git-pull . origin
Наша сборка переместилась на origin. Теперь можно сделать
$ gear --rpm -- rpm -bc
Если всё работает, то остается исправить version и release в спеке на
1.3-alt1 (или 1.4-alt0.1) и сделать gear-commit -a.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя : =?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/20070410/b5dee62f/attachment-0001.bin>
Подробная информация о списке рассылки Devel