[devel] I: http://www.altlinux.org/Gear/gear-uupdate

[devel] I: http://www.altlinux.org/Gear/gear-uupdate

[Igor Vlasenko]

Господа,

Выложил документацию по gear-uupdate на
http://www.altlinux.org/Gear/gear-uupdate

Из наиболее важного, того, что не было в предыдущем письме -
описана логика работы утилит - сначала, не трогая репозитория,
одна утилита (gear-uupdate-prepare) компилирует логику обновления
репозитория в промежуточный код (набор shell скриптов).
Эти скрипты можно просмотреть, проверить и пошагово запустить
самостоятельно либо с помощью другой утилиты,
сохраняя полный контроль над процессом обновления.

=== раздел 3. запуск вручную ===

gear-uupdate(1) -- это обертка над парой утилит gear-uupdate-prepare(1) и gear-uupdate-execute.

Руками gear-uupdate запускают так:

gear-uupdate --upstream-version 6.8.9.3 ImageMagick-6.8.9-3.tar.xz

либо так

gear-uupdate ImageMagick-6.8.9-3.tar.xz 6.8.9.3

При первом запуске лучше не запускать сразу gear-uupdate, а запустить

gear-uupdate-prepare --upstream-version 6.8.9.3 ImageMagick-6.8.9-3.tar.xz

gear-uupdate-prepare сначала выполнит проверки из gear-rules-verify.

Затем, gear-uupdate-prepare (ничего не меняя в репозитории) генерирует набор shell скриптов. Эти скрипты могут быть созданы в корне gear репозитория, если апстрим в подкаталоге в текущей ветке. в остальных случаях скрипты надо прятать от git, поэтому они создаются в папке .git/uupdate/.

После выполнения gear-uupdate-prepare в .git/uupdate/ будет что-то вроде

__~.uupdate-step-001-checkout-and-update-upstream-branch.sh
__~.uupdate-step-002-merge-upstream-to-patch1-branch.sh
...
__~.uupdate-step-006-merge-upstream-to-patch5-branch.sh
__~.uupdate-step-007-merge-upstream-to-master.sh
__~.uupdate-step-008-update-spec-and-tags.sh

Эти скрипты можно просмотреть и убедиться еще раз, что робот понял структуру репозитория правильно. После чего их можно выполнить с помощью gear-uupdate-execute.

Утилита gear-uupdate-execute по очереди выполняет сгенерированные скрипты, удаляя скрипт, если он отработал нормально. Во многих схемах устройства gear репозитория изменения автора и изменения майнтайнера мержатся с помощью git, при чем, возможно, ветвь с оригинальными исходниками необходимо будет мержить в несколько ветвей. Для таких операций достаточно часто возникают конфликты.

Если конфликт при merge произошел, то gear-uupdate-execute остановится на скрипте, который завершился с ошибкой. git при этом будет в той ветви, в которой происходил merge. В таком случае майнтайнеру необходимо будет вручную разрешить конфликт в исходных файлах, и закоммитить изменения в git. При этом скрипт __~.uupdate-step-*, на котором произошел сбой, можно использовать в качестве готового шаблона команд. Затем можно удалить этот скрипт, и опять запустить gear-uupdate-execute, который выполнит оставшиеся скрипты.

Если убедиться, что gear-uupdate-prepare/gear-uupdate-execute отрабатывают нормально, далее уже сразу можно запускать gear-uupdate. 


-- 

I V

Re: [devel] I: http://www.altlinux.org/Gear/gear-uupdate

[Anton Farygin]

On 13.06.2014 00:54, Igor Vlasenko wrote:
> Господа,
>
> Выложил документацию по gear-uupdate на
> http://www.altlinux.org/Gear/gear-uupdate


Игорь, пока не слез с gear-uupdate - вопрос. А может быть заодно 
подумаешь как с помощью тех-же инструментов обновляться из апстримного 
гита в полу-автоматическом режиме ?

Новую версию можно отслеживать, например, по тэгам.

Re: [devel] I: http://www.altlinux.org/Gear/gear-uupdate

[Anton Farygin]

On 13.06.2014 00:54, Igor Vlasenko wrote:
> Господа,
>
> Выложил документацию по gear-uupdate на
> http://www.altlinux.org/Gear/gear-uupdate

$ gear-rules-verify
specfile=wireshark.spec
rules..........OK
spec file......OK

Robot readiness:
Source0 rule ..............yes
no foreign commits ........no
separate upstream branch ..@name@-@version@
merge to master strategy ..default
Diff merge order:
diff: @name@-@version@:wireshark wireshark
Foreign commits found.
Not compatible with tarball update.
Wait until gear support for shared remote origin will be implemented.


Что бы это значило ?

Re: [devel] I: http://www.altlinux.org/Gear/gear-uupdate

[Igor Vlasenko]

On Mon, Jun 16, 2014 at 01:14:31PM +0400, Anton Farygin wrote:
> $ gear-rules-verify
> specfile=wireshark.spec
> rules..........OK
> spec file......OK
> 
> Robot readiness:
> Source0 rule ..............yes
> no foreign commits ........no
> separate upstream branch ..@name@-@version@
> merge to master strategy ..default
> Diff merge order:
> diff: @name@-@version@:wireshark wireshark
> Foreign commits found.

Это робот еще не со всеми членами Тим знаком.
$ git log | grep '^Author:' | egrep -v '(altlinux|hasher).*>?$'
Author: Alexander Bokovoy <ab@samba.org>
Author: Alexander Bokovoy <ab@samba.org>

Робот думал, что это апстримные коммиты.

> Not compatible with tarball update.
и заключил, что git обновлялся из апстрима

> Wait until gear support for shared remote origin will be implemented.
напомнил, что у нас нет стандарта, как запомнить в gear remotes или информацию
из git-svn

В общем, познакомил робота с Александром, выложил
task #121543: added #100: build srpm perl-Gear-Rules-0.12-alt1.src.rpm

Теперь -
wireshark.git $ gear-rules-verify 
specfile=wireshark.spec
rules..........OK
spec file......OK

Robot readiness:
Source0 rule ..............yes
no foreign commits ........yes
separate upstream branch ..@name@-@version@
merge to master strategy ..default
Diff merge order:
diff: @name@-@version@:wireshark wireshark
Ready for tarball update.

:)


-- 

I V

Re: [devel] I: http://www.altlinux.org/Gear/gear-uupdate

[Anton Farygin]

On 16.06.2014 13:42, Igor Vlasenko wrote:

> В общем, познакомил робота с Александром, выложил
> task #121543: added #100: build srpm perl-Gear-Rules-0.12-alt1.src.rpm

Хорошо, спасибо.

Re: [devel] I: http://www.altlinux.org/Gear/gear-uupdate

[Igor Vlasenko]

On Mon, Jun 16, 2014 at 12:48:38PM +0400, Anton Farygin wrote:
> Игорь, пока не слез с gear-uupdate - вопрос. А может быть заодно
> подумаешь как с помощью тех-же инструментов обновляться из
> апстримного гита в полу-автоматическом режиме ?

Эту тему уже поднял робот в своем сообщении,
которое цитировалось в прошлом письме:

> > Wait until gear support for shared remote origin will be implemented.
> напомнил, что у нас нет стандарта, как запомнить в gear remotes
> или информацию из git-svn

Это много лет назад уже обсуждалось, design flaw в gear,
который существенно затрудняет совместную работу над пакетами,
у которых gear репозиторий обновляется из upstream VCS.

В случае gear репозитория, который обновляется из тарбола,
все понятно. Есть канонический апстримный тарбол,
по .gear/rules можно понять, куда его и как распаковать.

Теперь я клонирую чужой gear репозиторий.

git log | grep '^Author:' | egrep -v '(ab@samba\.org|altlinux|hasher).*>?$'
и gitk показывают, что репозиторий обновляется из какого-то VCS.

Сразу возникает ряд вопросов:
1) git это или svn через git-svn или bzr, ...
2) где находится эта VCS, каков ее адрес?
3) какое соответствие между удаленными ветвями и 
ветвями локального gear репозитория?

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

И на это рытье в интернете, угадывание, восстановление
конфигурации тратится непозволительно много времени.
При том, что человеку было бы достаточно той информации,
которая уже есть локально у майнтайнера на его машине,
в .git/config и т.д. , но она теряется при передаче на git.alt:
и нет стандартного способа сохранить ее в .gear.
идеально - еще и в роботочитаемом виде.

В итоге, например, в Сизифе srpm пакеты perl 
обновляются, а gear пакеты perl - протухшие.

> Новую версию можно отслеживать, например, по тэгам.

потерявши апстримные ветви, рано думать о тегах :)

-- 

I V

Re: [devel] I: http://www.altlinux.org/Gear/gear-uupdate

[Anton Farygin]

On 16.06.2014 15:25, Igor Vlasenko wrote:
> On Mon, Jun 16, 2014 at 12:48:38PM +0400, Anton Farygin wrote:
>> Новую версию можно отслеживать, например, по тэгам.
>
> потерявши апстримные ветви, рано думать о тегах :)
>

А зачем нам апстримные ветви ? тэги наше всё.

в watch файле указывать вместо ссылки на тарболл - ссылку на апстримный 
git, на котором можно посмотреть тэги.

Далее всё просто - можно как угодно называть локальную ветку с удалённым 
репозиторием и как-угодно remote. Главное - это тэги, по которым и будут 
идти мержи в локальные бранчи и выставляться тэги в соответствии с rules.

ну, т.е. - remote для uupdate можно и стандартизировать, например 
назвать её gear-uupdate

это же не важно.

Re: [devel] I: http://www.altlinux.org/Gear/gear-uupdate

[Igor Vlasenko]

On Mon, Jun 16, 2014 at 03:38:38PM +0400, Anton Farygin wrote:
> >>Новую версию можно отслеживать, например, по тэгам.
> >потерявши апстримные ветви, рано думать о тегах :)
> А зачем нам апстримные ветви ? тэги наше всё.
 
> в watch файле указывать вместо ссылки на тарболл - ссылку на
> апстримный git, на котором можно посмотреть тэги.
 
Идея разумная. Чисто для git-watch - наблюдения за
апстримными тегами в удаленном репозитории - она сработает.

> Далее всё просто - можно как угодно называть локальную ветку с
> удалённым репозиторием и как-угодно remote. Главное - это тэги, по
> которым и будут идти мержи в локальные бранчи и выставляться тэги в
> соответствии с rules.

не все так просто -

* тегов может и не быть 
  а) - в gear-rules (пример c NMU которое делал неделю назад)
$ cat virt-viewer.git/.gear/rules
tar: upstream:.
  б) в апстриме (некоторые апстримы не всегда вешают таг,
  хоть тарбол выкладывают, и наличие тега, синхронность его
  с тем тарболом, что выложен, и формат тега -
  - зависят, с какой ноги наступило утро.)

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

поэтому желательно иметь указание, в какие ветви что куда должно идти.

но, в принципе, задача решаемая.

Надо будет сначала на кошках потренироваться.

среди пакетов perl-* накопилось много протухших
gear репозиториев, с с согласия владельцев
они могут выступить в роли подопытных кроликов.

-- 

I V

Re: [devel] I: http://www.altlinux.org/Gear/gear-uupdate

[Anton Farygin]

On 16.06.2014 19:53, Igor Vlasenko wrote:
> On Mon, Jun 16, 2014 at 03:38:38PM +0400, Anton Farygin wrote:
>>>> Новую версию можно отслеживать, например, по тэгам.
>>> потерявши апстримные ветви, рано думать о тегах :)
>> А зачем нам апстримные ветви ? тэги наше всё.
>
>> в watch файле указывать вместо ссылки на тарболл - ссылку на
>> апстримный git, на котором можно посмотреть тэги.
>
> Идея разумная. Чисто для git-watch - наблюдения за
> апстримными тегами в удаленном репозитории - она сработает.

да, с этого можно начать ;) я уже в некоторых репозиториях watch файлы 
держу только для слежки за апстримом. хотя через git было бы удобнее.

>
>> Далее всё просто - можно как угодно называть локальную ветку с
>> удалённым репозиторием и как-угодно remote. Главное - это тэги, по
>> которым и будут идти мержи в локальные бранчи и выставляться тэги в
>> соответствии с rules.
>
> не все так просто -
>
> * тегов может и не быть
>    а) - в gear-rules (пример c NMU которое делал неделю назад)
> $ cat virt-viewer.git/.gear/rules
> tar: upstream:.
>    б) в апстриме (некоторые апстримы не всегда вешают таг,
>    хоть тарбол выкладывают, и наличие тега, синхронность его
>    с тем тарболом, что выложен, и формат тега -
>    - зависят, с какой ноги наступило утро.)

Не, ну понятно что если апстрим не вменяем, то пытаться забрать из него 
git - не стоит.

Я то как раз говорю о нормальных апстримах, таких уже довольно много.

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

честно говоря не понял, зачем это ? вижу всё так-же как и в случае с 
тарболлом и исходниками в отдельном бранче. Ну совсем никакой разницы 
-просто вместо gear update будет git pull. остальные этапы точно такие-же.


>
> но, в принципе, задача решаемая.
>
> Надо будет сначала на кошках потренироваться.
>
> среди пакетов perl-* накопилось много протухших
> gear репозиториев, с с согласия владельцев
> они могут выступить в роли подопытных кроликов.

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

Re: [devel] I: http://www.altlinux.org/Gear/gear-uupdate

[Eugene Prokopiev]

16 июня 2014 г., 19:53 Igor Vlasenko написал:

> среди пакетов perl-* накопилось много протухших
> gear репозиториев, с с согласия владельцев
> они могут выступить в роли подопытных кроликов.

Я иногда обновляю starman и perl-Mojolicious, но было бы очень хорошо
делать это автоматически - если владелец позволит это делать не только
мне, но и роботу :)

Апстримы вполне вменяемые, теги ставят.

-- 
WBR,
Eugene Prokopiev

Re: [devel] I: http://www.altlinux.org/Gear/gear-uupdate

[Андрей Черепанов]

16.06.2014 15:25, Igor Vlasenko пишет:
> On Mon, Jun 16, 2014 at 12:48:38PM +0400, Anton Farygin wrote:
>> Игорь, пока не слез с gear-uupdate - вопрос. А может быть заодно
>> подумаешь как с помощью тех-же инструментов обновляться из
>> апстримного гита в полу-автоматическом режиме ?
>
> Эту тему уже поднял робот в своем сообщении,
> которое цитировалось в прошлом письме:
>
>>> Wait until gear support for shared remote origin will be implemented.
>> напомнил, что у нас нет стандарта, как запомнить в gear remotes
>> или информацию из git-svn
>
> Это много лет назад уже обсуждалось, design flaw в gear,
> который существенно затрудняет совместную работу над пакетами,
> у которых gear репозиторий обновляется из upstream VCS.
>
> В случае gear репозитория, который обновляется из тарбола,
> все понятно. Есть канонический апстримный тарбол,
> по .gear/rules можно понять, куда его и как распаковать.
>
> Теперь я клонирую чужой gear репозиторий.
>
> git log | grep '^Author:' | egrep -v '(ab@samba\.org|altlinux|hasher).*>?$'
> и gitk показывают, что репозиторий обновляется из какого-то VCS.
>
> Сразу возникает ряд вопросов:
> 1) git это или svn через git-svn или bzr, ...
> 2) где находится эта VCS, каков ее адрес?
> 3) какое соответствие между удаленными ветвями и
> ветвями локального gear репозитория?
>
> Даже человек может запросто угадать неправильно -
> если майнтайнер сделал нешаблонно -
> не говоря уже о роботе.
>
> И на это рытье в интернете, угадывание, восстановление
> конфигурации тратится непозволительно много времени.
> При том, что человеку было бы достаточно той информации,
> которая уже есть локально у майнтайнера на его машине,
> в .git/config и т.д. , но она теряется при передаче на git.alt:
> и нет стандартного способа сохранить ее в .gear.
> идеально - еще и в роботочитаемом виде.
В Fedora, к примеру, помимо Source: указывается и # VCS: ...
Мне эта практика понравилась и где возможно, я её указываю.

P.S. А формат watch разве нельзя расширить на источник в VCS?

-- 
Андрей Черепанов
ALT Linux
cas@altlinux.org