[devel] rpmbph with git branches

[devel] rpmbph with git branches

[Eugene Prokopiev]

>  Пакеты в бранчи я собираю такой командой:
>  $ rpmbph -n -M50 -u global.spec
>  Пока не представляю, как это сделать на основе git, поскольку
>  пока не готов изобретать правила для хранения в репозитории
>  разных веток (или они уже где-то опубликованы).
>  Если Вы считаете, что автоматическое создание ветки в git для
>  бранча имеет смысл, я готов рассмотреть пример репозитория с
>  правильной структурой и адаптировать rpmbph к сборке из git.

Как минимум для меня некоторая автоматика для управления ветками в git
имеет смысл, только сделать никак не соберусь :( В качестве примера
структуры репозитория предлагаю взглянуть на
http://www.altlinux.org/Git/SomeDestReposViaBranches

-- 
С уважением,
Прокопьев Евгений

Re: [devel] rpmbph with git branches

[Max Ivanov]

>>  Пакеты в бранчи я собираю такой командой:
>>  $ rpmbph -n -M50 -u global.spec
>>  Пока не представляю, как это сделать на основе git, поскольку
>>  пока не готов изобретать правила для хранения в репозитории
>>  разных веток (или они уже где-то опубликованы).
>>  Если Вы считаете, что автоматическое создание ветки в git для
>>  бранча имеет смысл, я готов рассмотреть пример репозитория с
>>  правильной структурой и адаптировать rpmbph к сборке из git.
>
> Как минимум для меня некоторая автоматика для управления ветками в git
> имеет смысл, только сделать никак не соберусь :( В качестве примера
> структуры репозитория предлагаю взглянуть на
> http://www.altlinux.org/Git/SomeDestReposViaBranches

+1 тоже заинтересован в стандартном расположении git веток, а значит в
наличии всяких полезных утилит.

Для себя выработал пока такую (теоретическу, т.к. никуда еще ничего не
бекпортил) структуру:
master, master50,master41 и  т.д. это ветки со spec файлами,
README.ALT , инит скриптами и прочим богатством созданными
мейнтенером.
upstream  - голая ветка с исходниками
upstream-feature (или name-feature), какая-то крупная фича, требующая
отдельной ветки.
upstream-feature2 , еще одна крупная ветка, в нее мержится featureN-1
upstream-altpatched , в нее вливаются последняя feature, а в ней самой
находятся мелкие правки мейнтенера

upstream-altpatched вливается в соотв. master через merge -s ours
если для какого-то бранча нужен другой набор патчей, то создается
upstream-altpatched40 (как пример).

Впринципе, если я правильно понимаю смысл rpmbph, то достаточно
стандарта на ветки со спек файлами, всё остальное можно узнать из
.gear/rules и .gear/merge

Re: [devel] rpmbph with git branches

[Alexey I. Froloff]

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

* Max Ivanov <ivanov.maxim@> [090518 18:52]:
> +1 тоже заинтересован в стандартном расположении git веток, а
> значит в наличии всяких полезных утилит.
Мне неудобен этот стандарт и никто не имеет права мне его
навязывать.

-- 
Regards,
Sir Raorn.

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

Re: [devel] rpmbph with git branches

[Afanasov Dmitry]

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

On Mon, May 18, 2009 at 07:00:42PM +0400, Alexey I. Froloff wrote:
> * Max Ivanov <ivanov.maxim@> [090518 18:52]:
> > +1 тоже заинтересован в стандартном расположении git веток, а
> > значит в наличии всяких полезных утилит.
> Мне неудобен этот стандарт и никто не имеет права мне его
> навязывать.
много кому будет неудобен любой стандарт. уж жутко мало ограничений в git
:)

а значит, кто как себе заскриптует, такой у него стандарт и будет.

/me например не переваривает -s ours. у меня несварение мозгов от него :)

-- 
С уважением
Афанасов Дмитрий

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

Re: [devel] rpmbph with git branches

[Max Ivanov]

Для целей rpmbph важно только как назвать новый бранч со спеком для
бекпорта. Т.е. алгоритм вижу такой:

1) git checkout -b <name> HEAD
2) исправить спек как привыкли править
3) коммит.


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

Re: [devel] rpmbph with git branches

[Anton Farygin]

Eugene Prokopiev пишет:
>>  Пакеты в бранчи я собираю такой командой:
>>  $ rpmbph -n -M50 -u global.spec
>>  Пока не представляю, как это сделать на основе git, поскольку
>>  пока не готов изобретать правила для хранения в репозитории
>>  разных веток (или они уже где-то опубликованы).
>>  Если Вы считаете, что автоматическое создание ветки в git для
>>  бранча имеет смысл, я готов рассмотреть пример репозитория с
>>  правильной структурой и адаптировать rpmbph к сборке из git.
> 
> Как минимум для меня некоторая автоматика для управления ветками в git
> имеет смысл, только сделать никак не соберусь :( В качестве примера
> структуры репозитория предлагаю взглянуть на
> http://www.altlinux.org/Git/SomeDestReposViaBranches
> 

Скажу вам по секрету, только никому не говорите - при сборке пакетов 
ветки не имеют никакого значения, важны только тэги.

Re: [devel] rpmbph with git branches

[Eugene Prokopiev]

18.05.09, Anton Farygin<rider@altlinux.com> написал(а):
> Eugene Prokopiev пишет:
>
>
> >
> > >  Пакеты в бранчи я собираю такой командой:
> > >  $ rpmbph -n -M50 -u global.spec
> > >  Пока не представляю, как это сделать на основе git, поскольку
> > >  пока не готов изобретать правила для хранения в репозитории
> > >  разных веток (или они уже где-то опубликованы).
> > >  Если Вы считаете, что автоматическое создание ветки в git для
> > >  бранча имеет смысл, я готов рассмотреть пример репозитория с
> > >  правильной структурой и адаптировать rpmbph к сборке из git.
> > >
> >
> > Как минимум для меня некоторая автоматика для управления ветками в git
> > имеет смысл, только сделать никак не соберусь :( В качестве примера
> > структуры репозитория предлагаю взглянуть на
> > http://www.altlinux.org/Git/SomeDestReposViaBranches
> >
> >
>
>  Скажу вам по секрету, только никому не говорите - при сборке пакетов ветки
> не имеют никакого значения, важны только тэги.

А можно развить эту мысль дальше?

Мне было показалось, что вы хотели предложить собирать в разные
репозитории из одной ветки, но я не смог понять как быть с Release и
changelog ...

-- 
С уважением,
Прокопьев Евгений

Re: [devel] rpmbph with git branches

[Eugene Prokopiev]

18.05.09, Alexey I. Froloff<raorn@altlinux.org> написал(а):
> * Max Ivanov <ivanov.maxim@> [090518 18:52]:
>
> > +1 тоже заинтересован в стандартном расположении git веток, а
>  > значит в наличии всяких полезных утилит.
>
> Мне неудобен этот стандарт и никто не имеет права мне его
> навязывать.

Ну так навяжите или предложите свой вариант.

Вот интересно, возможен ли стандарт (или несколько стадартов на разные
случаи), который удовлетворит всех?

-- 
С уважением,
Прокопьев Евгений

Re: [devel] rpmbph with git branches

[Alexey I. Froloff]

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

* Eugene Prokopiev <enp@> [090518 20:55]:
> > Мне неудобен этот стандарт и никто не имеет права мне его
> > навязывать.
> Ну так навяжите или предложите свой вариант.
Все мои варианты лежат на гитальте.  Их больше одного и gear
прекрасно с ними всеми справляется.

> Вот интересно, возможен ли стандарт (или несколько стадартов на разные
> случаи), который удовлетворит всех?
Зачем он нужен?

-- 
Regards,
Sir Raorn.

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

Re: [devel] rpmbph with git branches

[Igor Vlasenko]

On Mon, May 18, 2009 at 08:53:41PM +0400, Eugene Prokopiev wrote:
> 18.05.09, Alexey I. Froloff<raorn@altlinux.org> написал(а):
> > * Max Ivanov <ivanov.maxim@> [090518 18:52]:
> >
> > > +1 тоже заинтересован в стандартном расположении git веток, а
> >  > значит в наличии всяких полезных утилит.
> >
> > Мне неудобен этот стандарт и никто не имеет права мне его
> > навязывать.
> 
> Вот интересно, возможен ли стандарт (или несколько стадартов на разные
> случаи), который удовлетворит всех?

вряд ли. тут может помочь конфиг, что-то вроде
.gear/backport-rules

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] rpmbph with git branches

[Led]

On Monday 18 May 2009 19:53:41 Eugene Prokopiev wrote:
> 18.05.09, Alexey I. Froloff<raorn@altlinux.org> написал(а):
> > * Max Ivanov <ivanov.maxim@> [090518 18:52]:
> > > +1 тоже заинтересован в стандартном расположении git веток, а
> > >
> >  > значит в наличии всяких полезных утилит.
> >
> > Мне неудобен этот стандарт и никто не имеет права мне его
> > навязывать.
>
> Ну так навяжите или предложите свой вариант.
>
> Вот интересно, возможен ли стандарт (или несколько стадартов на разные
> случаи), который удовлетворит всех?

Возможен. Он предполагает наличие .gear/rules

-- 
Led

Re: [devel] rpmbph with git branches

[Anton Farygin]

Eugene Prokopiev пишет:
> 18.05.09, Anton Farygin<rider@altlinux.com> написал(а):
>> Eugene Prokopiev пишет:
>>
>>
>>>>  Пакеты в бранчи я собираю такой командой:
>>>>  $ rpmbph -n -M50 -u global.spec
>>>>  Пока не представляю, как это сделать на основе git, поскольку
>>>>  пока не готов изобретать правила для хранения в репозитории
>>>>  разных веток (или они уже где-то опубликованы).
>>>>  Если Вы считаете, что автоматическое создание ветки в git для
>>>>  бранча имеет смысл, я готов рассмотреть пример репозитория с
>>>>  правильной структурой и адаптировать rpmbph к сборке из git.
>>>>
>>> Как минимум для меня некоторая автоматика для управления ветками в git
>>> имеет смысл, только сделать никак не соберусь :( В качестве примера
>>> структуры репозитория предлагаю взглянуть на
>>> http://www.altlinux.org/Git/SomeDestReposViaBranches
>>>
>>>
>>  Скажу вам по секрету, только никому не говорите - при сборке пакетов ветки
>> не имеют никакого значения, важны только тэги.
> 
> А можно развить эту мысль дальше?
> 
> Мне было показалось, что вы хотели предложить собирать в разные
> репозитории из одной ветки, но я не смог понять как быть с Release и
> changelog ...

А дальше - вы пишете скрипт, который будет из master делать тэги с 
нужными изменениями (через временный бранч). Release и changelog надо 
будет править.

Кстати, почему-то у нас в Release: не получается использовать макросы, 
определённые в /etc/rpm/macros.d/ ? Они вообще должны работать ?

а так можно было бы release вычислять на основании какого-нить %branchver

Re: [devel] rpmbph with git branches

[Aleksey Avdeev]

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

Anton Farygin пишет:
> Eugene Prokopiev пишет:
>> 18.05.09, Anton Farygin<rider@altlinux.com> написал(а):
>>> Eugene Prokopiev пишет:
>>>
>>>
>>>>>  Пакеты в бранчи я собираю такой командой:
>>>>>  $ rpmbph -n -M50 -u global.spec
>>>>>  Пока не представляю, как это сделать на основе git, поскольку
>>>>>  пока не готов изобретать правила для хранения в репозитории
>>>>>  разных веток (или они уже где-то опубликованы).
>>>>>  Если Вы считаете, что автоматическое создание ветки в git для
>>>>>  бранча имеет смысл, я готов рассмотреть пример репозитория с
>>>>>  правильной структурой и адаптировать rpmbph к сборке из git.
>>>>>
>>>> Как минимум для меня некоторая автоматика для управления ветками в git
>>>> имеет смысл, только сделать никак не соберусь :( В качестве примера
>>>> структуры репозитория предлагаю взглянуть на
>>>> http://www.altlinux.org/Git/SomeDestReposViaBranches
>>>>
>>>>
>>>  Скажу вам по секрету, только никому не говорите - при сборке пакетов 
>>> ветки
>>> не имеют никакого значения, важны только тэги.
>>
>> А можно развить эту мысль дальше?
>>
>> Мне было показалось, что вы хотели предложить собирать в разные
>> репозитории из одной ветки, но я не смог понять как быть с Release и
>> changelog ...
> 
> А дальше - вы пишете скрипт, который будет из master делать тэги с 
> нужными изменениями (через временный бранч). Release и changelog надо 
> будет править.
> 
> Кстати, почему-то у нас в Release: не получается использовать макросы, 
> определённые в /etc/rpm/macros.d/ ? Они вообще должны работать ?

   Можно, и оно работает. См. 
<http://git.altlinux.org/people/solo/packages/?p=apache2.git;a=blob;f=apache2.spec;h=2d4284a637889841f6dba3f089bcfc55372a0e21;hb=ALT/apache2/spec>:
часть макросов, на основе которых вычисляется Release (%distr_switch, в 
частности) определена в другом пакете (в rpm-macros-apache2). Для 
данного пакета требуется использовать BuildRequires(pre).

> а так можно было бы release вычислять на основании какого-нить %branchver

   Я давно этим (вычислением нужного Release, в зависимости от 
дистрибутива/бранча, через макросы) пользуюсь (и как-то сюда писал об этом).

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 552 bytes --]

Re: [devel] rpmbph with git branches

[Anton Farygin]

Aleksey Avdeev пишет:
> Anton Farygin пишет:
>> Eugene Prokopiev пишет:
>>> 18.05.09, Anton 
>>> Farygin<rider-u2l5PoMzF/VWk0Htik3J/w@public.gmane.org> написал(а):
>>>> Eugene Prokopiev пишет:
>>>>
>>>>
>>>>>>  Пакеты в бранчи я собираю такой командой:
>>>>>>  $ rpmbph -n -M50 -u global.spec
>>>>>>  Пока не представляю, как это сделать на основе git, поскольку
>>>>>>  пока не готов изобретать правила для хранения в репозитории
>>>>>>  разных веток (или они уже где-то опубликованы).
>>>>>>  Если Вы считаете, что автоматическое создание ветки в git для
>>>>>>  бранча имеет смысл, я готов рассмотреть пример репозитория с
>>>>>>  правильной структурой и адаптировать rpmbph к сборке из git.
>>>>>>
>>>>> Как минимум для меня некоторая автоматика для управления ветками в git
>>>>> имеет смысл, только сделать никак не соберусь :( В качестве примера
>>>>> структуры репозитория предлагаю взглянуть на
>>>>> http://www.altlinux.org/Git/SomeDestReposViaBranches
>>>>>
>>>>>
>>>>  Скажу вам по секрету, только никому не говорите - при сборке 
>>>> пакетов ветки
>>>> не имеют никакого значения, важны только тэги.
>>>
>>> А можно развить эту мысль дальше?
>>>
>>> Мне было показалось, что вы хотели предложить собирать в разные
>>> репозитории из одной ветки, но я не смог понять как быть с Release и
>>> changelog ...
>>
>> А дальше - вы пишете скрипт, который будет из master делать тэги с 
>> нужными изменениями (через временный бранч). Release и changelog надо 
>> будет править.
>>
>> Кстати, почему-то у нас в Release: не получается использовать макросы, 
>> определённые в /etc/rpm/macros.d/ ? Они вообще должны работать ?
> 
>   Можно, и оно работает. См. 
> <http://git.altlinux.org/people/solo/packages/?p=apache2.git;a=blob;f=apache2.spec;h=2d4284a637889841f6dba3f089bcfc55372a0e21;hb=ALT/apache2/spec>: 
> 
> часть макросов, на основе которых вычисляется Release (%distr_switch, в 
> частности) определена в другом пакете (в rpm-macros-apache2). Для 
> данного пакета требуется использовать BuildRequires(pre).

Интересно было бы полностью вычислить Release в /etc/rpm/macros.d/

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

Т.е. - в итоге должно получиться что-то вроде

%_altrelease 1
Release: %alt_release

> 
>> а так можно было бы release вычислять на основании какого-нить %branchver
> 
>   Я давно этим (вычислением нужного Release, в зависимости от 
> дистрибутива/бранча, через макросы) пользуюсь (и как-то сюда писал об 
> этом).

что-то у тебя в спеке страшно всё очень. Вынести бы это в отдельную 
функцию...

Re: [devel] rpmbph with git branches

[Aleksey Avdeev]

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

Anton Farygin пишет:
> Aleksey Avdeev пишет:
>> Anton Farygin пишет:
>>> Eugene Prokopiev пишет:
>>>> 18.05.09, Anton 
>>>> Farygin<rider-u2l5PoMzF/VWk0Htik3J/w@public.gmane.org> написал(а):
>>>>> Eugene Prokopiev пишет:
>>>>>
>>>>>
>>>>>>>  Пакеты в бранчи я собираю такой командой:
>>>>>>>  $ rpmbph -n -M50 -u global.spec
>>>>>>>  Пока не представляю, как это сделать на основе git, поскольку
>>>>>>>  пока не готов изобретать правила для хранения в репозитории
>>>>>>>  разных веток (или они уже где-то опубликованы).
>>>>>>>  Если Вы считаете, что автоматическое создание ветки в git для
>>>>>>>  бранча имеет смысл, я готов рассмотреть пример репозитория с
>>>>>>>  правильной структурой и адаптировать rpmbph к сборке из git.
>>>>>>>
>>>>>> Как минимум для меня некоторая автоматика для управления ветками в 
>>>>>> git
>>>>>> имеет смысл, только сделать никак не соберусь :( В качестве примера
>>>>>> структуры репозитория предлагаю взглянуть на
>>>>>> http://www.altlinux.org/Git/SomeDestReposViaBranches
>>>>>>
>>>>>>
>>>>>  Скажу вам по секрету, только никому не говорите - при сборке 
>>>>> пакетов ветки
>>>>> не имеют никакого значения, важны только тэги.
>>>>
>>>> А можно развить эту мысль дальше?
>>>>
>>>> Мне было показалось, что вы хотели предложить собирать в разные
>>>> репозитории из одной ветки, но я не смог понять как быть с Release и
>>>> changelog ...
>>>
>>> А дальше - вы пишете скрипт, который будет из master делать тэги с 
>>> нужными изменениями (через временный бранч). Release и changelog надо 
>>> будет править.
>>>
>>> Кстати, почему-то у нас в Release: не получается использовать 
>>> макросы, определённые в /etc/rpm/macros.d/ ? Они вообще должны 
>>> работать ?
>>
>>   Можно, и оно работает. См. 
>> <http://git.altlinux.org/people/solo/packages/?p=apache2.git;a=blob;f=apache2.spec;h=2d4284a637889841f6dba3f089bcfc55372a0e21;hb=ALT/apache2/spec>: 
>>
>> часть макросов, на основе которых вычисляется Release (%distr_switch, 
>> в частности) определена в другом пакете (в rpm-macros-apache2). Для 
>> данного пакета требуется использовать BuildRequires(pre).
> 
> Интересно было бы полностью вычислить Release в /etc/rpm/macros.d/
> 
> Всё, что еу нужно передавать - это номер релиза - циферку.
> 
> Т.е. - в итоге должно получиться что-то вроде
> 
> %_altrelease 1
> Release: %alt_release

   Примерно так и сделано, только я использую 2 цифры в формате х{,.у}, где:

%release_base_num -- обязательный x;

%release_base_num2 -- не обязательный y (если он %nil, то в релизе одна 
цифра).

   Всё остальное -- вычисляется на базе констант, тоже определённых в спеке.

> 
>>
>>> а так можно было бы release вычислять на основании какого-нить 
>>> %branchver
>>
>>   Я давно этим (вычислением нужного Release, в зависимости от 
>> дистрибутива/бранча, через макросы) пользуюсь (и как-то сюда писал об 
>> этом).
> 
> что-то у тебя в спеке страшно всё очень. Вынести бы это в отдельную 
> функцию...

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

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 552 bytes --]

Re: [devel] rpmbph with git branches

[Aleksey Avdeev]

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

Vitaly Lipatov пишет:
> On 18 мая 2009, Aleksey Avdeev wrote:
> ...
>>    Я давно этим (вычислением нужного Release, в зависимости от
>> дистрибутива/бранча, через макросы) пользуюсь (и как-то сюда
>> писал об этом).
> И я даже уже выступал против того, чтобы превращать спек в 
> нечитаемое нечто.

   Я помню, это.

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 552 bytes --]

Re: [devel] rpmbph with git branches

[Vitaly Lipatov]

On 18 мая 2009, Aleksey Avdeev wrote:
...
>    Я давно этим (вычислением нужного Release, в зависимости от
> дистрибутива/бранча, через макросы) пользуюсь (и как-то сюда
> писал об этом).
И я даже уже выступал против того, чтобы превращать спек в 
нечитаемое нечто.


-- 
С уважением,
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [devel] rpmbph with git branches

[Eugene Prokopiev]

> > >  Скажу вам по секрету, только никому не говорите - при сборке пакетов
> ветки
> > > не имеют никакого значения, важны только тэги.
> > >
> >
> > А можно развить эту мысль дальше?
> >
> > Мне было показалось, что вы хотели предложить собирать в разные
> > репозитории из одной ветки, но я не смог понять как быть с Release и
> > changelog ...
> >
>
>  А дальше - вы пишете скрипт, который будет из master делать тэги с нужными
> изменениями (через временный бранч). Release и changelog надо будет править.

Т.е. все-таки дополнительная ветка на репозиторий (пусть и временная)?
;) И почему временная? Вы предлагаете откатывать коммит, на основе
которого выполнялась сборка?

Кстати, по времена incoming нечто в этом духе я и использовал

-- 
С уважением,
Прокопьев Евгений

Re: [devel] rpmbph with git branches

[Eugene Prokopiev]

18.05.09, Alexey I. Froloff<raorn@altlinux.org> написал(а):
> * Eugene Prokopiev <enp@> [090518 20:55]:
>
> > > Мне неудобен этот стандарт и никто не имеет права мне его
>  > > навязывать.
>  > Ну так навяжите или предложите свой вариант.
>
> Все мои варианты лежат на гитальте.  Их больше одного и gear
>  прекрасно с ними всеми справляется.
>
>
>  > Вот интересно, возможен ли стандарт (или несколько стадартов на разные
>  > случаи), который удовлетворит всех?
>
> Зачем он нужен?

Сразу видно майнтейнера, которому не интересны бранчи ;)

-- 
С уважением,
Прокопьев Евгений

Re: [devel] rpmbph with git branches

[Vitaly Lipatov]

On 19 мая 2009, Eugene Prokopiev wrote:
...
> >  А дальше - вы пишете скрипт, который будет из master делать
> > тэги с нужными изменениями (через временный бранч). Release
> > и changelog надо будет править.
>
> Т.е. все-таки дополнительная ветка на репозиторий (пусть и
> временная)? ;) И почему временная? Вы предлагаете откатывать
> коммит, на основе которого выполнялась сборка?
Нет, конечно же ветка должна быть постоянной, поскольку в один 
прекрасный момент автоматическое back-портирование может стать 
невозможным, и потребуется вручную собирать для бранча.


-- 
С уважением,
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [devel] rpmbph with git branches

[Anton Farygin]

Eugene Prokopiev пишет:
>>>>  Скажу вам по секрету, только никому не говорите - при сборке пакетов
>> ветки
>>>> не имеют никакого значения, важны только тэги.
>>>>
>>> А можно развить эту мысль дальше?
>>>
>>> Мне было показалось, что вы хотели предложить собирать в разные
>>> репозитории из одной ветки, но я не смог понять как быть с Release и
>>> changelog ...
>>>
>>  А дальше - вы пишете скрипт, который будет из master делать тэги с нужными
>> изменениями (через временный бранч). Release и changelog надо будет править.
> 
> Т.е. все-таки дополнительная ветка на репозиторий (пусть и временная)?
> ;) И почему временная? Вы предлагаете откатывать коммит, на основе
> которого выполнялась сборка?

Зачем откатывать коммит ? merge надо проводить с тэгом, а не с веткой.

В каждый новый тэг будет подшиваться история предыдущего (через -s 
ours). Иначе через некоторое время вы столкнётесь с проблемой - 
невозможно будет собрать версию из sisyphus для 5.0, не спортировав туда 
всю его историю.

В этом случае нам нет никакой необходимости вести бранчи. Собственно, 
бранчи необходимы только для локальной разработки. Если мы публикуем 
тэг, из которого идёт сборка - то в бранчах необходимость исчезает 
(точнее - при необходимости они создаются на основании тэгов).

Мы же говорим про бэкпорты, верно ?

> 
> Кстати, по времена incoming нечто в этом духе я и использовал
> 

Re: [devel] rpmbph with git branches

[Anton Farygin]

Vitaly Lipatov пишет:
> On 19 мая 2009, Eugene Prokopiev wrote:
> ...
>>>  А дальше - вы пишете скрипт, который будет из master делать
>>> тэги с нужными изменениями (через временный бранч). Release
>>> и changelog надо будет править.
>> Т.е. все-таки дополнительная ветка на репозиторий (пусть и
>> временная)? ;) И почему временная? Вы предлагаете откатывать
>> коммит, на основе которого выполнялась сборка?
> Нет, конечно же ветка должна быть постоянной, поскольку в один 
> прекрасный момент автоматическое back-портирование может стать 
> невозможным, и потребуется вручную собирать для бранча.

И зачем для этого нужна именно ветка ?

Re: [devel] rpmbph with git branches

[Eugene Prokopiev]

> > > >  А дальше - вы пишете скрипт, который будет из master делать
> > > > тэги с нужными изменениями (через временный бранч). Release
> > > > и changelog надо будет править.
> > > >
> > > Т.е. все-таки дополнительная ветка на репозиторий (пусть и
> > > временная)? ;) И почему временная? Вы предлагаете откатывать
> > > коммит, на основе которого выполнялась сборка?
> > >
> > Нет, конечно же ветка должна быть постоянной, поскольку в один прекрасный
> момент автоматическое back-портирование может стать невозможным, и
> потребуется вручную собирать для бранча.
> >
>
>  И зачем для этого нужна именно ветка ?

Ну снова загадки :) Можете последовательно изложить процедуру
поддержки пакета для нескольких репозитариев без применения веток? Я
такую придумать не смог ...

-- 
С уважением,
Прокопьев Евгений

Re: [devel] rpmbph with git branches

[Anton Farygin]

Eugene Prokopiev пишет:
>>>>>  А дальше - вы пишете скрипт, который будет из master делать
>>>>> тэги с нужными изменениями (через временный бранч). Release
>>>>> и changelog надо будет править.
>>>>>
>>>> Т.е. все-таки дополнительная ветка на репозиторий (пусть и
>>>> временная)? ;) И почему временная? Вы предлагаете откатывать
>>>> коммит, на основе которого выполнялась сборка?
>>>>
>>> Нет, конечно же ветка должна быть постоянной, поскольку в один прекрасный
>> момент автоматическое back-портирование может стать невозможным, и
>> потребуется вручную собирать для бранча.
>>  И зачем для этого нужна именно ветка ?
> 
> Ну снова загадки :) Можете последовательно изложить процедуру
> поддержки пакета для нескольких репозитариев без применения веток? Я
> такую придумать не смог ...

git checkout -b tmpbr master
git merge -s ours <тэг с предыдущей версией/релизом>
патчим <пакет.spec>, изменяем релиз
add_changelog -e "backport to branch X.X" <пакет.spec>
gear-commit -a
gear-create-tag
git push <тэг>
git checkout master
git branch -d tmpbr

ssh git.alt build -b X.X <новый тэг>

Re: [devel] rpmbph with git branches

[Eugene Prokopiev]

> > Можете последовательно изложить процедуру
> > поддержки пакета для нескольких репозитариев без применения веток? Я
> > такую придумать не смог ...
>
>  git checkout -b tmpbr master
>  git merge -s ours <тэг с предыдущей версией/релизом>
>  патчим <пакет.spec>, изменяем релиз
>  add_changelog -e "backport to branch X.X" <пакет.spec>
>  gear-commit -a
>  gear-create-tag
>  git push <тэг>
>  git checkout master
>  git branch -d tmpbr
>
>  ssh git.alt build -b X.X <новый тэг>

Спасибо, попробую при случае

-- 
С уважением,
Прокопьев Евгений

Re: [devel] rpmbph with git branches

[Aleksey Avdeev]

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

Anton Farygin пишет:
...
> 
> В этом случае нам нет никакой необходимости вести бранчи. Собственно, 
> бранчи необходимы только для локальной разработки. Если мы публикуем 
> тэг, из которого идёт сборка - то в бранчах необходимость исчезает 
> (точнее - при необходимости они создаются на основании тэгов).

   И при этом абсолютно неважно, как они (бранчи) обозваны в репозитарии 
мантейнера.

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 552 bytes --]

Re: [devel] rpmbph with git branches

[Anton Farygin]

Aleksey Avdeev пишет:
> Anton Farygin пишет:
> ...
>>
>> В этом случае нам нет никакой необходимости вести бранчи. Собственно, 
>> бранчи необходимы только для локальной разработки. Если мы публикуем 
>> тэг, из которого идёт сборка - то в бранчах необходимость исчезает 
>> (точнее - при необходимости они создаются на основании тэгов).
> 
>   И при этом абсолютно неважно, как они (бранчи) обозваны в репозитарии 
> мантейнера.

Более того - их может не быть совсем. Конечно, выглядит это несколько 
странно.

Вот пример.
http://git.altlinux.org/people/rider/packages/quesoglc.git

Re: [devel] rpmbph with git branches

[Max Ivanov]

> Более того - их может не быть совсем. Конечно, выглядит это несколько
> странно.
>

Конечно, если одна из задач чтобы никто не разобрался, как оно всё
работает. То же и относится к удалению бранча, на который поставлен
тег.

Re: [devel] rpmbph with git branches

[Anton Farygin]

Max Ivanov пишет:
>> Более того - их может не быть совсем. Конечно, выглядит это несколько
>> странно.
>>
> 
> Конечно, если одна из задач чтобы никто не разобрался, как оно всё
> работает. То же и относится к удалению бранча, на который поставлен
> тег.

Не удалению, а не публикации. И при чём тут "не разобрался" ?

Вы думаете, что вот в этом git'е:

http://git.altlinux.org/people/rider/packages/selinux.git

разобраться легче, даже при наличии кучки бранчей ?

Ориентироваться, в первую очередь, надо не на бранчи, а на тэги..

Re: [devel] rpmbph with git branches

[Vitaly Lipatov]

On 19 мая 2009, Anton Farygin wrote:
...
> > Нет, конечно же ветка должна быть постоянной, поскольку в
> > один прекрасный момент автоматическое back-портирование
> > может стать невозможным, и потребуется вручную собирать для
> > бранча.
>
> И зачем для этого нужна именно ветка ?
Чтобы при необходимости в ней производить изменения кода и спека, 
специфичные для бранча. Прикладывать патчи и пр.


-- 
С уважением,
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [devel] rpmbph with git branches

[Michael Shigorin]

On Mon, May 18, 2009 at 08:59:23PM +0400, Alexey I. Froloff wrote:
> > > Мне неудобен этот стандарт и никто не имеет права мне его
> > > навязывать.
> > Ну так навяжите или предложите свой вариант.
> Все мои варианты лежат на гитальте.  Их больше одного и gear
> прекрасно с ними всеми справляется.

Думаю, для понимания даже их подмножества может пригодиться
немалое время желающего понять, а порой -- и твоё понадобиться.

> > Вот интересно, возможен ли стандарт (или несколько стадартов
> > на разные случаи), который удовлетворит всех?
> Зачем он нужен?

Затем, что иначе нет смысла размахивать флагом "коллаборации
в git.alt" -- если понять структуру чужого репо оказывается
не под силу, то желание участвовать в _совместной_ разработке
может попросту закончиться раньше хоть каких-то результатов
по техническим причинам.

Например, мы с mithraen@ занимаемся nginx -- при этом пока Денис
разучивал git+gear, репо получился таким, что обновляет его
руками только он, я же работаю в пределах версии (что меня до сих
пор устраивало -- раз или два, когда нужно было именно обновление
версии, меня устраивало и подождать несколько дней/недель, пока у
него руки дойдут).

Ну и про инструментарий тоже всё правильно сказали -- да, есть
опциональные параметры, но разумных дефолтов это не отменяет.

С другой стороны, на вкус и цвет фломастеры разные и я
действительно не уверен, готовы ли мы пожертвовать иными
эстетическими предпочтениями в пользу (возможно, гипотетических)
других людей.

Возможно, _предложение_ какого-то _рекомендуемого_ набора имён
и следование ему людей, которые уже работают совместно и
заинтересованы в создании соответствующей обвязки -- помогло
бы этому вопросу по возможности естественно и без конфликтов.

У меня предпочтения сейчас примерно (но не жёстко) таковы:

master -- результат моей работы над пакетом
upstream -- "чистые" исходники апстрима
M50/M41/... -- бранчеспецифичные ветки

У Большакова видел и оценил имя "maint" -- как понимаю,
"это должно работать".

PS: бранчи по именам майнтейнеров сейчас обычно называю
соответствующе логину, хотя как рекомендация это чем дальше,
тем больше может приводить к коллизиям (если не придумать
namespace -- хоть начинать с подчёркивания, хоть alt/*).

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] rpmbph with git branches

[Afanasov Dmitry]

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

On Sun, May 24, 2009 at 04:09:57PM +0300, Michael Shigorin wrote:
> On Mon, May 18, 2009 at 08:59:23PM +0400, Alexey I. Froloff wrote:
> > > > Мне неудобен этот стандарт и никто не имеет права мне его
> > > > навязывать.
> > > Ну так навяжите или предложите свой вариант.
> > Все мои варианты лежат на гитальте.  Их больше одного и gear
> > прекрасно с ними всеми справляется.
> 
> Думаю, для понимания даже их подмножества может пригодиться
> немалое время желающего понять, а порой -- и твоё понадобиться.
да-да, сталкивался с таким. самое тяжелое понять - а на кой ляд тут
merge, и откуда он вообще идет? а если впоследствии и branch
переименовали, или мержили откуда-нибудь из git://..., то вообще ахтунг.

больше всего сбивает с мысли - -s ours. этот ousr же в commit message по
умолчанию не отмечается.

> > > Вот интересно, возможен ли стандарт (или несколько стадартов
> > > на разные случаи), который удовлетворит всех?
> > Зачем он нужен?
> 
> Затем, что иначе нет смысла размахивать флагом "коллаборации
> в git.alt" -- если понять структуру чужого репо оказывается
> не под силу, то желание участвовать в _совместной_ разработке
> может попросту закончиться раньше хоть каких-то результатов
> по техническим причинам.
сейчас, чтобы не понимать чужой репо, достаточно понять, откуда растет
cumulative патч, сварганить свой gear из source rpm и навести там свою
структуру. обмен же прекрасно осуществляется через git format-patch.

жаль, gear-srpmimport не очень настраваем, чтобы им пользоваться. вот
скриптам gear-import из srpm, локального/удаленого gear репы, а также
gear-update-svn, gear-update-git я б обрадовался :)

> Возможно, _предложение_ какого-то _рекомендуемого_ набора имён
> и следование ему людей, которые уже работают совместно и
> заинтересованы в создании соответствующей обвязки -- помогло
> бы этому вопросу по возможности естественно и без конфликтов.
> 
> У меня предпочтения сейчас примерно (но не жёстко) таковы:
sources - исходники
master  - для sisyphus
patch/* - ветки с большими патчами, растущими из sources
branch/* - ветки с бранчами.

вот только что делать в такой струтуре, когда для бранчей свои патчи. пока
пришел в мысли делать патчевские ветки <MXX>-patch/*

да, и source теги - sources/*

ну и наконец не забываем, что git очень мало ограничивает в работе, все
его ограничения могут быть только сверху, как проверка на ancestor в gear.
по большому счету каждый git репо - личный репо. и отмечается при мержах
соответсвенно - merge <remote>/<branch>. он может быть общим только если
для каждой пакетины будет один gear, а не десяток.
-- 
 С уважением
 Афанасов Дмитрий

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

Re: [devel] rpmbph with git branches

[Aleksey Avdeev]

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

Michael Shigorin пишет:
> On Mon, May 18, 2009 at 08:59:23PM +0400, Alexey I. Froloff wrote:
...
> 
> У меня предпочтения сейчас примерно (но не жёстко) таковы:
> 
> master -- результат моей работы над пакетом
> upstream -- "чистые" исходники апстрима
> M50/M41/... -- бранчеспецифичные ветки
> 
> У Большакова видел и оценил имя "maint" -- как понимаю,
> "это должно работать".
> 
> PS: бранчи по именам майнтейнеров сейчас обычно называю
> соответствующе логину, хотя как рекомендация это чем дальше,
> тем больше может приводить к коллизиям (если не придумать
> namespace -- хоть начинать с подчёркивания, хоть alt/*).

   Я обзываю бранчи <Team>/{,<диструтив/бранч>/}<имя_пакета>/<компонент> 
(+ бранч для "чистых" исходников апстрима), а тэги -- 
<Team>/<имя_пакета>/{,<компонент>/}<версия>{,-<релиз>}. Это позволяет 
исключить коллизии:

1. Совпадение версий/релизов при сборке нескольких пакетов из одного 
репозитария по тегам (главное!) и бранчам (используя remotes этим можно 
пренебречь).

2. Совпадение версий/релизов у пакетов из разных источников (RH, SUSE и пр.)

   Что в свою очередь -- позволяет достаточно удобно мержить между собой 
части разных пакетов (и/или части пакетов взятых из разных источников).

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 552 bytes --]

Re: [devel] rpmbph with git branches

[Grigory Batalov]

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

On Sun, 24 May 2009 17:36:20 +0400, Afanasov Dmitry wrote:

> > > Все мои варианты лежат на гитальте.  Их больше одного и gear
> > > прекрасно с ними всеми справляется.
> >
> > Думаю, для понимания даже их подмножества может пригодиться
> > немалое время желающего понять, а порой -- и твоё понадобиться.

> да-да, сталкивался с таким. самое тяжелое понять - а на кой ляд тут
> merge, и откуда он вообще идет? а если впоследствии и branch
> переименовали, или мержили откуда-нибудь из git://..., то вообще ахтунг.

gitk не помогает? =)

> больше всего сбивает с мысли - -s ours. этот ousr же в commit message по
> умолчанию не отмечается.

Я у таких коммитов пишу "fake merge".

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

Re: [devel] rpmbph with git branches

[Afanasov Dmitry]

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

On Sun, May 24, 2009 at 08:21:04PM +0400, Grigory Batalov wrote:
> On Sun, 24 May 2009 17:36:20 +0400, Afanasov Dmitry wrote:
> > да-да, сталкивался с таким. самое тяжелое понять - а на кой ляд тут
> > merge, и откуда он вообще идет? а если впоследствии и branch
> > переименовали, или мержили откуда-нибудь из git://..., то вообще ахтунг.
> 
> gitk не помогает? =)
помогает конечно. куда ж без gitk/qgit :) но времени ест не меряно. на
ffmpeg.git два рабочих дня ухлопал, а они не всегда есть в резерве.

излишняя сложность - всегда потеря времени, которого всегда не хватает.
> > больше всего сбивает с мысли - -s ours. этот ousr же в commit message по
> > умолчанию не отмечается.
> 
> Я у таких коммитов пишу "fake merge".
и это здорово. в mplayer.git такого не было :(

-- 
 С уважением
 Афанасов Дмитрий

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

Re: [devel] Автоматические release (was: rpmbph with git branches)

[Aleksey Avdeev]

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

Anton Farygin пишет:
> Aleksey Avdeev пишет:
>> Anton Farygin пишет:
...
>>> Кстати, почему-то у нас в Release: не получается использовать 
>>> макросы, определённые в /etc/rpm/macros.d/ ? Они вообще должны 
>>> работать ?
>>
>>   Можно, и оно работает. См. 
>> <http://git.altlinux.org/people/solo/packages/?p=apache2.git;a=blob;f=apache2.spec;h=2d4284a637889841f6dba3f089bcfc55372a0e21;hb=ALT/apache2/spec>: 
>>
>> часть макросов, на основе которых вычисляется Release (%distr_switch, 
>> в частности) определена в другом пакете (в rpm-macros-apache2). Для 
>> данного пакета требуется использовать BuildRequires(pre).
> 
> Интересно было бы полностью вычислить Release в /etc/rpm/macros.d/
> 
> Всё, что еу нужно передавать - это номер релиза - циферку.
> 
> Т.е. - в итоге должно получиться что-то вроде
> 
> %_altrelease 1
> Release: %alt_release

   Похоже начало вытанцовываться что-то похожее. Если использовать 
прилагаемый макрофайл (см. вложение), то:

Release: %distr_auto_release <prefix><number>[.<suffix>]

   При этом если определён и не пуст макрос %distr_switch, конструкция 
раскроется так (если %distr_num не определён или пуст -- он будет 
считаться "1"):

Release: <prefix><number-1>.%distr_switch.%distr_num[.<suffix>]

   А если %distr_switch не определён или пуст -- так:

Release: <prefix><number>[.<suffix>]

PS: Данный вариант мне нравиться дольше, чем используемый сейчас. Думаю 
запаковать его. Прошу предлагать более внятные названия для макросов 
и/или самого пакета.

-- 

С уважением. Алексей.


[-- Attachment #1.2: auto_distr --]
[-- Type: text/plain, Size: 433 bytes --]

#auto_distr macros

# release format: <prefix><number>[.<suffix>]
%distr_auto_release() %(if [ "%{?distr_switch}" = "" ]; then echo "%1"; else echo "%1"|sed -rn -e 's@^([^[:space:]]+)([0-9]+)(|(\\.[^[:space:]]+))$@\\1/\\2/\\3@p'|awk -v FS='/' -v distr_name='%{?distr_switch}' -v distr_num='%{?distr_num}' 'BEGIN {if (distr_num == "") {num="1"} else {num=distr_num}; suf=("." distr_name "." num) }; {print $1 ($2-1) suf $3}'; fi)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 552 bytes --]

Re: [devel] Автоматические release (was: rpmbph with git branches)

[Michael Shigorin]

On Tue, Aug 04, 2009 at 07:29:54PM +0400, Aleksey Avdeev wrote:
> Похоже начало вытанцовываться что-то похожее. Если использовать
> прилагаемый макрофайл (см. вложение), то:
> 
> Release: %distr_auto_release <prefix><number>[.<suffix>]

IMHO чуточку лучше бы

Release: %distro_release ...

или вообще

Release: %branch_release ...

> PS: Данный вариант мне нравиться дольше, чем используемый
> сейчас. Думаю запаковать его. Прошу предлагать более внятные
> названия для макросов и/или самого пакета.

Да, вполне симпатично.

> #auto_distr macros
> 
> # release format: <prefix><number>[.<suffix>]
> %distr_auto_release() %(if [ "%{?distr_switch}" = "" ]; then echo "%1"; else echo "%1"|sed -rn -e 's@^([^[:space:]]+)([0-9]+)(|(\\.[^[:space:]]+))$@\\1/\\2/\\3@p'|awk -v FS='/' -v distr_name='%{?distr_switch}' -v distr_num='%{?distr_num}' 'BEGIN {if (distr_num == "") {num="1"} else {num=distr_num}; suf=("." distr_name "." num) }; {print $1 ($2-1) suf $3}'; fi)

Что-то подсказывает, что вместо if, echo, sed и awk можно
обойтись просто awk; с другой стороны, так экономится пара
циклов в тривиальном случае... :)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Автоматические release

[Aleksey Avdeev]

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

Michael Shigorin пишет:
> On Tue, Aug 04, 2009 at 07:29:54PM +0400, Aleksey Avdeev wrote:
>> Похоже начало вытанцовываться что-то похожее. Если использовать
>> прилагаемый макрофайл (см. вложение), то:
>>
>> Release: %distr_auto_release <prefix><number>[.<suffix>]
> 
> IMHO чуточку лучше бы
> 
> Release: %distro_release ...
> 
> или вообще
> 
> Release: %branch_release ...

   OK. Тогда и остальные макросы в %branch_switch и %branch_release_num, 
для единообразия.

> 
>> PS: Данный вариант мне нравиться дольше, чем используемый
>> сейчас. Думаю запаковать его. Прошу предлагать более внятные
>> названия для макросов и/или самого пакета.
> 
> Да, вполне симпатично.
> 
>> #auto_distr macros
>>
>> # release format: <prefix><number>[.<suffix>]
>> %distr_auto_release() %(if [ "%{?distr_switch}" = "" ]; then echo "%1"; else echo "%1"|sed -rn -e 's@^([^[:space:]]+)([0-9]+)(|(\\.[^[:space:]]+))$@\\1/\\2/\\3@p'|awk -v FS='/' -v distr_name='%{?distr_switch}' -v distr_num='%{?distr_num}' 'BEGIN {if (distr_num == "") {num="1"} else {num=distr_num}; suf=("." distr_name "." num) }; {print $1 ($2-1) suf $3}'; fi)
> 
> Что-то подсказывает, что вместо if, echo, sed и awk можно
> обойтись просто awk; с другой стороны, так экономится пара
> циклов в тривиальном случае... :)

   Вариант избавится от sed напрашивается. Но я не придумал, как в awk с 
помощью регулярного выражения разрезать строку на 3 переменных: в голову 
приходят только варианты отрезания подстрок по частям... А это 
получается более монстраподобно, чем sed.

   От if можно избавиться с помощью конструкции вида
%{!?distr_switch: %1}%{?distr_switch:  %(...)}, но это потребует 
обработки в awk ситуации, когда "%distr_switch" = "" (когда он определён 
как %nil или ""). if же позволяет отсечь данный случай на раннем этапе, 
до вызова sed/awk.

PS: По хорошему, нужно ещё придумать как поступать когда <number> = 0 и 
когда <number> имеет ведущие 0 (сейчас они теряются).

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 552 bytes --]

Re: [devel] Автоматические release

[Led]

On Tuesday 04 August 2009 20:07:19 Aleksey Avdeev wrote:
> Michael Shigorin пишет:
> > On Tue, Aug 04, 2009 at 07:29:54PM +0400, Aleksey Avdeev wrote:
> >> Похоже начало вытанцовываться что-то похожее. Если использовать
> >> прилагаемый макрофайл (см. вложение), то:
> >>
> >> Release: %distr_auto_release <prefix><number>[.<suffix>]
> >
> > IMHO чуточку лучше бы
> >
> > Release: %distro_release ...
> >
> > или вообще
> >
> > Release: %branch_release ...
>
>    OK. Тогда и остальные макросы в %branch_switch и %branch_release_num,
> для единообразия.
>
> >> PS: Данный вариант мне нравиться дольше, чем используемый
> >> сейчас. Думаю запаковать его. Прошу предлагать более внятные
> >> названия для макросов и/или самого пакета.
> >
> > Да, вполне симпатично.
> >
> >> #auto_distr macros
> >>
> >> # release format: <prefix><number>[.<suffix>]
> >> %distr_auto_release() %(if [ "%{?distr_switch}" = "" ]; then echo "%1";
> >> else echo "%1"|sed -rn -e
> >> 's@^([^[:space:]]+)([0-9]+)(|(\\.[^[:space:]]+))$@\\1/\\2/\\3@p'|awk -v
> >> FS='/' -v distr_name='%{?distr_switch}' -v distr_num='%{?distr_num}'
> >> 'BEGIN {if (distr_num == "") {num="1"} else {num=distr_num}; suf=("."
> >> distr_name "." num) }; {print $1 ($2-1) suf $3}'; fi)
> >
> > Что-то подсказывает, что вместо if, echo, sed и awk можно
> > обойтись просто awk; с другой стороны, так экономится пара
> > циклов в тривиальном случае... :)
>
>    Вариант избавится от sed напрашивается. Но я не придумал, как в awk с
> помощью регулярного выражения разрезать строку на 3 переменных:

split()

> в голову 
> приходят только варианты отрезания подстрок по частям... А это
> получается более монстраподобно, чем sed.
>
>    От if можно избавиться с помощью конструкции вида
> %{!?distr_switch: %1}%{?distr_switch:  %(...)}, но это потребует
> обработки в awk ситуации, когда "%distr_switch" = "" (когда он определён
> как %nil или ""). if же позволяет отсечь данный случай на раннем этапе,
> до вызова sed/awk.
>
> PS: По хорошему, нужно ещё придумать как поступать когда <number> = 0 и
> когда <number> имеет ведущие 0 (сейчас они теряются).



-- 
Led

Re: [devel] Автоматические release

[Aleksey Avdeev]

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

Led пишет:
> On Tuesday 04 August 2009 20:07:19 Aleksey Avdeev wrote:
>> Michael Shigorin пишет:
>>> On Tue, Aug 04, 2009 at 07:29:54PM +0400, Aleksey Avdeev wrote:
>>>> Похоже начало вытанцовываться что-то похожее. Если использовать
>>>> прилагаемый макрофайл (см. вложение), то:
>>>>
>>>> Release: %distr_auto_release <prefix><number>[.<suffix>]
>>> IMHO чуточку лучше бы
>>>
>>> Release: %distro_release ...
>>>
>>> или вообще
>>>
>>> Release: %branch_release ...
>>    OK. Тогда и остальные макросы в %branch_switch и %branch_release_num,
>> для единообразия.
>>
>>>> PS: Данный вариант мне нравиться дольше, чем используемый
>>>> сейчас. Думаю запаковать его. Прошу предлагать более внятные
>>>> названия для макросов и/или самого пакета.
>>> Да, вполне симпатично.
>>>
>>>> #auto_distr macros
>>>>
>>>> # release format: <prefix><number>[.<suffix>]
>>>> %distr_auto_release() %(if [ "%{?distr_switch}" = "" ]; then echo "%1";
>>>> else echo "%1"|sed -rn -e
>>>> 's@^([^[:space:]]+)([0-9]+)(|(\\.[^[:space:]]+))$@\\1/\\2/\\3@p'|awk -v
>>>> FS='/' -v distr_name='%{?distr_switch}' -v distr_num='%{?distr_num}'
>>>> 'BEGIN {if (distr_num == "") {num="1"} else {num=distr_num}; suf=("."
>>>> distr_name "." num) }; {print $1 ($2-1) suf $3}'; fi)
>>> Что-то подсказывает, что вместо if, echo, sed и awk можно
>>> обойтись просто awk; с другой стороны, так экономится пара
>>> циклов в тривиальном случае... :)
>>    Вариант избавится от sed напрашивается. Но я не придумал, как в awk с
>> помощью регулярного выражения разрезать строку на 3 переменных:
> 
> split()

   Не понял как применить со сложным регекспом. То что придумал:

$ echo alt2|awk '{split($0, a, 
"^([^[:space:]]+)([0-9]+)(|(\\.[^[:space:]]+))$");print "a[1]=" a[1] " 
a[2]=" a[2] " a[3]=" a[3]}'

возвращает:

a[1]= a[2]= a[3]=

   А мне нужно (при alt2 на входе) получить на выходе:

a[1]=alt a[2]=2 a[3]=

   Кой для этого нужен регексп для split?

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 552 bytes --]

Re: [devel] Автоматические release (was: rpmbph with git branches)

[Eugene Prokopiev]

> Данный вариант мне нравиться дольше, чем используемый сейчас

Как это будет работать в случае git.alt? На один коммит ставим
несколько тегов для разных бранчей и собираем для этих бранчей - при
этом разные Release формируются автомагически?

PS: я этих целей использую srpmbackport из

-- 
С уважением,
Прокопьев Евгений

Re: [devel] Автоматические release (was: rpmbph with git branches)

[Eugene Prokopiev]

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

>> Данный вариант мне нравиться дольше, чем используемый сейчас
>
> Как это будет работать в случае git.alt? Просто ставим тэг и собираем в разные бранчи?
>
> PS: я этих целей использую srpmbackport из

... из perl-RPM-Source-Editor - там тоже получается несложная для
пользователя (т.е. меня) автоматика (думаю, мой shell-код ужасен, но
все-таки приложу), однако это разные спеки в фейковых бранчах
git-репозитария - предложенная схема выглядит действительно проще.

Да, и Release - это совсем не циферка, там много чего может быть, см.
https://bugzilla.altlinux.org/buglist.cgi?component=perl-RPM-Source-Editor&product=Sisyphus.
Может использовать общий код для вычисления Release?

-- 
С уважением,
Прокопьев Евгений

[-- Attachment #2: pkg-backport.sh --]
[-- Type: application/x-sh, Size: 524 bytes --]

Re: [devel] Автоматические release

[Aleksey Avdeev]

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

Eugene Prokopiev пишет:
>>> Данный вариант мне нравиться дольше, чем используемый сейчас
>> Как это будет работать в случае git.alt? Просто ставим тэг и собираем в разные бранчи?
>>
>> PS: я этих целей использую srpmbackport из
> 
> ... из perl-RPM-Source-Editor - там тоже получается несложная для
> пользователя (т.е. меня) автоматика (думаю, мой shell-код ужасен, но
> все-таки приложу), однако это разные спеки в фейковых бранчах
> git-репозитария - предложенная схема выглядит действительно проще.
> 
> Да, и Release - это совсем не циферка, там много чего может быть, см.
> https://bugzilla.altlinux.org/buglist.cgi?component=perl-RPM-Source-Editor&product=Sisyphus.

   Оба случая учтены (см. вложение): все вычисления проводятся над 
последним числовым полем. Последним числовым полем считается поле 
состоящие только из цифр, и ограниченное слева любым не числом, а с 
права -- концом строки либо точкой и полем оканчивающимся не на цифру.

   Т. е.:

<префикс><n> --> <префикс><n-1>.<бранч>.1

<префикс><n>.<m> --> <префикс><n>.<m-1>.<бранч>.1

<префикс><n>.<суффикс> --> <префикс><n-1>.<бранч>.1.<суффикс>

<префикс><n>.<m><суффикс> --> <префикс><n-1>.<бранч>.1.<m><суффикс>

<префикс><n><суффикс> --> вызовет ошибку

где:

<префикс> -- группа любых не пробельных символов оканчивающаяся не 
цифрой с последующим цифровым полем. (Если релиз оканчивается цифрами, 
<префикс> -- всё что ранее.)

<суффикс> -- группа любых не пробельных символов оканчивающаяся не 
цифрой и отделённая от числового поля точкой.

> Может использовать общий код для вычисления Release?

-- 

С уважением. Алексей.


[-- Attachment #1.2: auto_distr --]
[-- Type: text/plain, Size: 491 bytes --]

#rpm-macros-branch macros

# Release: %branch_release <prefix><number>[.<suffix>]
%branch_release() %(if [ "%{?branch_switch}" = "" ]; then echo "%1"; else echo "%1"|sed -rn -e 's@^([^[:space:]]+[^0-9])([0-9]+)(|(\\.[^[:space:]]+))$@\\1/\\2/\\3@p'|awk -v FS='/' -v branch_name='%{?branch_switch}' -v branch_release_num='%{?branch_release_num}' 'BEGIN {if (branch_release_num == "") {num="1"} else {num=branch_release_num}; suf=("." branch_name "." num) }; {print $1 ($2-1) suf $3}'; fi)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 552 bytes --]

Re: [devel] Автоматические release

[Aleksey Avdeev]

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

Aleksey Avdeev пишет:
> Michael Shigorin пишет:
>> On Tue, Aug 04, 2009 at 07:29:54PM +0400, Aleksey Avdeev wrote:
>>> Похоже начало вытанцовываться что-то похожее. Если использовать
>>> прилагаемый макрофайл (см. вложение), то:
>>>
>>> Release: %distr_auto_release <prefix><number>[.<suffix>]
>>
>> IMHO чуточку лучше бы
>>
>> Release: %distro_release ...
>>
>> или вообще
>>
>> Release: %branch_release ...
> 
>   OK. Тогда и остальные макросы в %branch_switch и %branch_release_num, 
> для единообразия.

   Пакет rpm-macros-branch в Сизифе и бранчах. Применение см. на примере 
FreeAdhocUDF-0.0.0.20090128a-alt1.M41.1 
(<http://sisyphus.ru/en/srpm/Branch41/FreeAdhocUDF/spec>).

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 552 bytes --]

Re: [devel] Автоматические release

[Aleksey Avdeev]

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

Aleksey Avdeev пишет:
> Aleksey Avdeev пишет:
>> Michael Shigorin пишет:
>>> On Tue, Aug 04, 2009 at 07:29:54PM +0400, Aleksey Avdeev wrote:
>>>> Похоже начало вытанцовываться что-то похожее. Если использовать
>>>> прилагаемый макрофайл (см. вложение), то:
>>>>
>>>> Release: %distr_auto_release <prefix><number>[.<suffix>]
>>>
>>> IMHO чуточку лучше бы
>>>
>>> Release: %distro_release ...
>>>
>>> или вообще
>>>
>>> Release: %branch_release ...
>>
>>   OK. Тогда и остальные макросы в %branch_switch и 
>> %branch_release_num, для единообразия.
> 
>   Пакет rpm-macros-branch в Сизифе и бранчах. Применение см. на примере 
> FreeAdhocUDF-0.0.0.20090128a-alt1.M41.1 
> (<http://sisyphus.ru/en/srpm/Branch41/FreeAdhocUDF/spec>).

   Нарвался на неработоспособность buildrec: при использовании 
%branch_release выводится релиз, и buildrec повисает...

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 552 bytes --]

[devel] I: У buildreq проблемы с %(<shell-coms>)? (was: Автоматические release)

[Aleksey Avdeev]

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

Aleksey Avdeev пишет:
> Aleksey Avdeev пишет:
>> Aleksey Avdeev пишет:
>>> Michael Shigorin пишет:
>>>> On Tue, Aug 04, 2009 at 07:29:54PM +0400, Aleksey Avdeev wrote:
>>>>> Похоже начало вытанцовываться что-то похожее. Если использовать
>>>>> прилагаемый макрофайл (см. вложение), то:
>>>>>
>>>>> Release: %distr_auto_release <prefix><number>[.<suffix>]
>>>>
>>>> IMHO чуточку лучше бы
>>>>
>>>> Release: %distro_release ...
>>>>
>>>> или вообще
>>>>
>>>> Release: %branch_release ...
>>>
>>>   OK. Тогда и остальные макросы в %branch_switch и 
>>> %branch_release_num, для единообразия.
>>
>>   Пакет rpm-macros-branch в Сизифе и бранчах. Применение см. на 
>> примере FreeAdhocUDF-0.0.0.20090128a-alt1.M41.1 
>> (<http://sisyphus.ru/en/srpm/Branch41/FreeAdhocUDF/spec>).
> 
>   Нарвался на неработоспособность buildrec: при использовании 
> %branch_release выводится релиз, и buildrec повисает...

   Отправил rpm-macros-branch-0.2-alt1: проблемы с buildrec разрешены 
только для случая сборки для Сизифа (когда %branch_switch _вообще_ не 
определён).

   Похоже нашему buildreq резко плохеет когда в Release: используется 
вызов shell команд. Т. е. если используется конструкция вида:

Release: %(<shell-coms>)

наш buildreq выводит вывод <shell-coms> и повисает... Бага?

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 552 bytes --]

Re: [devel] I: У buildreq проблемы с %(<shell-coms>)? (was: Автоматические release)

[Alexey Tourbin]

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

On Sat, Aug 08, 2009 at 01:12:06PM +0400, Aleksey Avdeev wrote:
> >>  Пакет rpm-macros-branch в Сизифе и бранчах. 
> >>  Применение см. на примере 
> >>FreeAdhocUDF-0.0.0.20090128a-alt1.M41.1 
> >>(<http://sisyphus.ru/en/srpm/Branch41/FreeAdhocUDF/spec>).
> >
> >  Нарвался на неработоспособность buildrec: 
> >  при использовании %branch_release выводится 
> >релиз, и buildrec повисает...
> 
>   Отправил rpm-macros-branch-0.2-alt1: проблемы с buildrec 
>   разрешены только для случая сборки для 
> Сизифа (когда %branch_switch _вообще_ не 
> определён).
> 
>   Похоже нашему buildreq резко плохеет когда 
>   в Release: используется вызов shell команд. Т. е. 
> если используется конструкция вида:
> 
> Release: %(<shell-coms>)
> 
> наш buildreq выводит вывод <shell-coms> и 
> повисает... Бага?

Не воспроизводится.

$ buildreq ~/RPM/SPECS/FreeAdhocUDF.spec
...
packagereq: optimized out: glibc-pthread
packagereq: BuildRequires: firebird-devel
$

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

Re: [devel] I: У buildreq проблемы с %(<shell-coms>)?

[Aleksey Avdeev]

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

Alexey Tourbin пишет:
> On Sat, Aug 08, 2009 at 01:12:06PM +0400, Aleksey Avdeev wrote:
>>>>  Пакет rpm-macros-branch в Сизифе и бранчах. 
>>>>  Применение см. на примере 
>>>> FreeAdhocUDF-0.0.0.20090128a-alt1.M41.1 
>>>> (<http://sisyphus.ru/en/srpm/Branch41/FreeAdhocUDF/spec>).
>>>  Нарвался на неработоспособность buildrec: 
>>>  при использовании %branch_release выводится 
>>> релиз, и buildrec повисает...
>>   Отправил rpm-macros-branch-0.2-alt1: проблемы с buildrec 
>>   разрешены только для случая сборки для 
>> Сизифа (когда %branch_switch _вообще_ не 
>> определён).
>>
>>   Похоже нашему buildreq резко плохеет когда 
>>   в Release: используется вызов shell команд. Т. е. 
>> если используется конструкция вида:
>>
>> Release: %(<shell-coms>)
>>
>> наш buildreq выводит вывод <shell-coms> и 
>> повисает... Бага?
> 
> Не воспроизводится.

   Сейчас -- и у меня тоже.

> 
> $ buildreq ~/RPM/SPECS/FreeAdhocUDF.spec
> ...
> packagereq: optimized out: glibc-pthread
> packagereq: BuildRequires: firebird-devel
> $

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 552 bytes --]