Re: [devel] [#56467] t6 FAILED (try 9) srpm=OpenSceneGraph-3.0.1-alt0.M60T.1.src.rpm ...

Re: [devel] [#56467] t6 FAILED (try 9) srpm=OpenSceneGraph-3.0.1-alt0.M60T.1.src.rpm ...

[Michael Shigorin]

On Sat, Oct 29, 2011 at 03:28:51PM +0400, Girar Builder robot wrote:
> http://git.altlinux.org/tasks/56467/logs/events.9.1.log
> 
>  *** source package version is either the same or older than existing
> meshbuilder-complex	0.2.0-alt1.bzr20110313	0.2.0-alt0.bzr20110620.M60T.1

Вот почему ревизии, даты и прочий SCM-ный хлам в Release: -- зло.

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

Re: [devel] [#56467] t6 FAILED (try 9) srpm=OpenSceneGraph-3.0.1-alt0.M60T.1.src.rpm ...

[Ildar Mulyukov]

On 29.10.2011 17:40:18, Michael Shigorin wrote:
> On Sat, Oct 29, 2011 at 03:28:51PM +0400, Girar Builder robot wrote:
> > http://git.altlinux.org/tasks/56467/logs/events.9.1.log
> >
> >  *** source package version is either the same or older than  
> existing
> > meshbuilder-complex	0.2.0-alt1.bzr20110313	 
> 0.2.0-alt0.bzr20110620.M60T.1
> 
> Вот почему ревизии, даты и прочий SCM-ный хлам в Release: -- зло.

Миша, я, например, пробовал хранить в Version. Мне не понравилось.  
Предлагаешь его "хранить" в changelog?
С уважением,
-- 
Ildar Mulyukov,
   free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
Jabber: ildar.mulyukov@gmail.com
ICQ: 4334029
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [devel] [#56467] t6 FAILED (try 9) srpm=OpenSceneGraph-3.0.1-alt0.M60T.1.src.rpm ...

[Aleksey Avdeev]

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

31.10.2011 09:23, Ildar Mulyukov пишет:
> On 29.10.2011 17:40:18, Michael Shigorin wrote:
>> On Sat, Oct 29, 2011 at 03:28:51PM +0400, Girar Builder robot wrote:
>> > http://git.altlinux.org/tasks/56467/logs/events.9.1.log
>> >
>> >  *** source package version is either the same or older than existing
>> > meshbuilder-complex    0.2.0-alt1.bzr20110313   
>> 0.2.0-alt0.bzr20110620.M60T.1
>>
>> Вот почему ревизии, даты и прочий SCM-ный хлам в Release: -- зло.
> 
> Миша, я, например, пробовал хранить в Version. Мне не понравилось.
> Предлагаешь его "хранить" в changelog?

  В данном случаи, логичный вариант: 0.2.0-alt1.bzr20110313.1 и
0.2.0-alt1.bzr20110620.0.M60T.1

-- 

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



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

Re: [devel] [#56467] t6 FAILED (try 9) srpm=OpenSceneGraph-3.0.1-alt0.M60T.1.src.rpm ...

[Michael Shigorin]

On Mon, Oct 31, 2011 at 01:40:28PM +0400, Aleksey Avdeev wrote:
> В данном случаи, логичный вариант: 0.2.0-alt1.bzr20110313.1 и
> 0.2.0-alt1.bzr20110620.0.M60T.1

Это если его предусмотреть, а можно ведь просто не наступать
на эти грабли. :)

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

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

Re: [devel] [#56467] t6 FAILED (try 9) srpm=OpenSceneGraph-3.0.1-alt0.M60T.1.src.rpm ...

[Michael Shigorin]

On Mon, Oct 31, 2011 at 11:23:24AM +0600, Ildar Mulyukov wrote:
> >> http://git.altlinux.org/tasks/56467/logs/events.9.1.log
> >>  *** source package version is either the same or older than existing
> >> meshbuilder-complex	0.2.0-alt1.bzr20110313	 
> >0.2.0-alt0.bzr20110620.M60T.1
> >
> >Вот почему ревизии, даты и прочий SCM-ный хлам в Release: -- зло.
> Миша, я, например, пробовал хранить в Version. Мне не понравилось.  

Ещё бы.

> Предлагаешь его "хранить" в changelog?

Ага.

PS: где-то на вики водились результаты обсуждения, кажется
-- но когда последний раз пробегал, сходу не нашёл.

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

Re: [devel] [#56467] t6 FAILED (try 9) srpm=OpenSceneGraph-3.0.1-alt0.M60T.1.src.rpm ...

[Gleb Fotengauer-Malinovskiy]

29.10.2011 15:40, Michael Shigorin пишет:
> On Sat, Oct 29, 2011 at 03:28:51PM +0400, Girar Builder robot wrote:
>> http://git.altlinux.org/tasks/56467/logs/events.9.1.log
>>
>>   *** source package version is either the same or older than existing
>> meshbuilder-complex	0.2.0-alt1.bzr20110313	0.2.0-alt0.bzr20110620.M60T.1
>
> Вот почему ревизии, даты и прочий SCM-ный хлам в Release: -- зло.
>

http://www.altlinux.org/Spec#.D0.9F.D1.80.D0.BE.D0.BC.D0.B5.D0.B6.D1.83.D1.82.D0.BE.D1.87.D0.BD.D1.8B.D0.B5_upstream-.D1.80.D0.B5.D0.BB.D0.B8.D0.B7.D1.8B

"Если система контроля версий не предоставляет линейной нумерации 
коммитов, то с каждым новым срезом нужно увеличивать номер релиза"

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

P.S. Я с лёгкостью запутаюсь в разных 0.2.0-alt1.что-то, подразумевающих 
  разные срезы.

--
glebfm

Глеб Фотенгауэр-Малиновский

[devel] [RFC] Release: и информация о коммите

[Michael Shigorin]

On Mon, Oct 31, 2011 at 09:33:21PM +0400, Gleb Fotengauer-Malinovskiy wrote:
> >>  *** source package version is either the same or older than existing
> >>meshbuilder-complex	0.2.0-alt1.bzr20110313	0.2.0-alt0.bzr20110620.M60T.1
> >Вот почему ревизии, даты и прочий SCM-ный хлам в Release: -- зло.
> http://www.altlinux.org/Spec#.D0.9F.D1.80.D0.BE.D0.BC.D0.B5.D0.B6.D1.83.D1.82.D0.BE.D1.87.D0.BD.D1.8B.D0.B5_upstream-.D1.80.D0.B5.D0.BB.D0.B8.D0.B7.D1.8B

Во, благодарю.

> "Если система контроля версий не предоставляет линейной нумерации 
> коммитов, то с каждым новым срезом нужно увеличивать номер релиза"
> Мне кажется, тут нужно убрать разделение и увеличивать номер релиза всегда.

Жду отзывов и если веских доводов против такой _рекомендации_
не будет -- добавляю в секцию:

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

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

Re: [devel] [RFC] Release: и информация о коммите

[Aleksey Avdeev]

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

31.10.2011 21:51, Michael Shigorin пишет:
> On Mon, Oct 31, 2011 at 09:33:21PM +0400, Gleb Fotengauer-Malinovskiy wrote:
>>>>  *** source package version is either the same or older than existing
>>>> meshbuilder-complex	0.2.0-alt1.bzr20110313	0.2.0-alt0.bzr20110620.M60T.1
>>> Вот почему ревизии, даты и прочий SCM-ный хлам в Release: -- зло.
>> http://www.altlinux.org/Spec#.D0.9F.D1.80.D0.BE.D0.BC.D0.B5.D0.B6.D1.83.D1.82.D0.BE.D1.87.D0.BD.D1.8B.D0.B5_upstream-.D1.80.D0.B5.D0.BB.D0.B8.D0.B7.D1.8B
> 
> Во, благодарю.
> 
>> "Если система контроля версий не предоставляет линейной нумерации 
>> коммитов, то с каждым новым срезом нужно увеличивать номер релиза"
>> Мне кажется, тут нужно убрать разделение и увеличивать номер релиза всегда.
> 
> Жду отзывов и если веских доводов против такой _рекомендации_
> не будет -- добавляю в секцию:
> 
> "Если для данного пакета версия снапшота не является важной
> характеристикой (например, как для крайне редко делающего
> нумерованные релизы mplayer) -- может быть лучше не засорять
> излишне низкоуровневой информацией тег Release:, достаточно
> увеличить номер релиза".

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

-- 

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



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

Re: [devel] [jt] [RFC] Release: и информация о коммите

[Dmitry V. Levin]

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

On Tue, Nov 01, 2011 at 01:19:05AM +0400, Aleksey Avdeev wrote:
>   Может лучше добавлять некий .n к версии, и инкриминировать его при
> изменении кода апстримом?

Инкриминировать?  Это, извините, из другой оперы.


-- 
ldv

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

Re: [devel] [jt] [RFC] Release: и информация о коммите

[Aleksey Avdeev]

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

01.11.2011 01:35, Dmitry V. Levin пишет:
> On Tue, Nov 01, 2011 at 01:19:05AM +0400, Aleksey Avdeev wrote:
>>   Может лучше добавлять некий .n к версии, и инкриминировать его при
>> изменении кода апстримом?
> 
> Инкриминировать?  Это, извините, из другой оперы.

  Инкриментировать.

-- 

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



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

Re: [devel] [jt] [RFC] Release: и информация о коммите

[Dmitry V. Levin]

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

On Tue, Nov 01, 2011 at 01:46:43AM +0400, Aleksey Avdeev wrote:
> 01.11.2011 01:35, Dmitry V. Levin пишет:
> > On Tue, Nov 01, 2011 at 01:19:05AM +0400, Aleksey Avdeev wrote:
> >>   Может лучше добавлять некий .n к версии, и инкриминировать его при
> >> изменении кода апстримом?
> > 
> > Инкриминировать?  Это, извините, из другой оперы.
> 
>   Инкриментировать.

Может быть, просто увеличивать?

Инкремент не подойдет потому, что вставлять промежуточные элементы не
очень удобно, разве что применить традиционный способ n.1.1.1.

Множества рациональных чисел должно хватить в любом случае. :)


-- 
ldv

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

Re: [devel] [jt] [RFC] Release: и информация о коммите

[Aleksey Avdeev]

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

01.11.2011 02:00, Dmitry V. Levin пишет:
> On Tue, Nov 01, 2011 at 01:46:43AM +0400, Aleksey Avdeev wrote:
>> 01.11.2011 01:35, Dmitry V. Levin пишет:
>>> On Tue, Nov 01, 2011 at 01:19:05AM +0400, Aleksey Avdeev wrote:
>>>>   Может лучше добавлять некий .n к версии, и инкриминировать его при
>>>> изменении кода апстримом?
>>>
>>> Инкриминировать?  Это, извините, из другой оперы.
>>
>>   Инкриментировать.
> 
> Может быть, просто увеличивать?

  Имею в виду следующее:

1. Пакет foo собираемый из кода соответствующего релизу X.Y.Z апстрима
-- foo-X.Y.Z

2. Некий промежуточный код, следующий за официальным релизом X.Y.Z, но
никак апстримом не отмеченный -- foo-X.Y.Z.1

3. Следующий промежуточный код, следующий за кодом п.2 -- foo-X.Y.Z.2

4. N-ная точка сборки -- foo-X.Y.Z.n

5. N+M-ная -- foo-X.Y.Z.(n+m)

6. Апстрим наконецтаки разродился релизом X.Y.(Z+1) -- собираем X.Y.(Z+1)...

  Или как вариант, для пунктов 1 и 6 собираем foo-X.Y.Z.0 и X.Y.(Z+1).0
соответственно.

> 
> Инкремент не подойдет потому, что вставлять промежуточные элементы не
> очень удобно, разве что применить традиционный способ n.1.1.1.

  Не... Это не выход.

> 
> Множества рациональных чисел должно хватить в любом случае. :)

-- 

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



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

Re: [devel] [RFC] Release: и информация о коммите

[Dmitry V. Levin]

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

On Tue, Nov 01, 2011 at 02:14:03AM +0400, Aleksey Avdeev wrote:
>   Имею в виду следующее:
> 
> 1. Пакет foo собираемый из кода соответствующего релизу X.Y.Z апстрима
> -- foo-X.Y.Z
> 
> 2. Некий промежуточный код, следующий за официальным релизом X.Y.Z, но
> никак апстримом не отмеченный -- foo-X.Y.Z.1
> 
> 3. Следующий промежуточный код, следующий за кодом п.2 -- foo-X.Y.Z.2
> 
> 4. N-ная точка сборки -- foo-X.Y.Z.n
> 
> 5. N+M-ная -- foo-X.Y.Z.(n+m)
> 
> 6. Апстрим наконецтаки разродился релизом X.Y.(Z+1) -- собираем X.Y.(Z+1)...
> 
>   Или как вариант, для пунктов 1 и 6 собираем foo-X.Y.Z.0 и X.Y.(Z+1).0
> соответственно.

Такой подход безопасно применять только тогда, когда у вас есть гарантия
того, что апстрим не выпустит релиз X.Y.Z.1.  В этом случае в конец версии
можно дописывать что угодно, не только последовательные натуральные числа,
но и номера коммитов, timestamp'ы, и т.п. - то, что более подходит для
данного конкретного проекта.  Вот, например, для пакета gnulib я применил
такой подход, сейчас в Сизифе у него версия 0.0.6125.da1717b, где 0.0 это
номер версии самого gnulib, а 6125.da1717b это форма записи коммита
v0.0-6125-gda1717b в виде, пригодном для версии пакета.

В остальных случаях лучше просто увеличивать номер релиза и добавлять
соответствующий комментарий в %changelog.

Если вы знаете, что собираемый снапшот уже существенно ближе к будущей
версии, чем к предыдущей, то вы можете себе позволить выпустить пакет с
версией предстоящего релиза, указывая в качестве Release 0.1, 0.2 и т.п.

Если вы собираете снапшоты, и вам очень хочется отразить эту информацию в
номере версии пакета, но никаких гарантий от апстрима у вас нет, то вы
можете попробовать дать пакету версию X.Y.Z.0.snap, где 0 это ноль,
который апстримы очень редко используют в таком качестве, а snap -
это некая характеристика, монотонно возрастающая с каждым снапшотом.
В случае svn в этом качестве можно использовать его собственный svn id.
В случае git при условии необратимости истории коммитов подойдет
какой-нибудь нормализованный вывод git-describe'а.


-- 
ldv

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

Re: [devel] [RFC] Release: и информация о коммите

[Dmitry V. Levin]

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

On Tue, Nov 01, 2011 at 02:43:54AM +0400, Dmitry V. Levin wrote:
> Если вы собираете снапшоты, и вам очень хочется отразить эту информацию в
> номере версии пакета, но никаких гарантий от апстрима у вас нет, то вы
> можете попробовать дать пакету версию X.Y.Z.0.snap, где 0 это ноль,
> который апстримы очень редко используют в таком качестве,

А также X.Y.Z.0.0.snap, X.Y.Z.0.0.0.snap и т.п., в зависимости от того,
насколько велико ваше стремление застраховаться от превратностей апстрима. :)


-- 
ldv

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

Re: [devel] [RFC] Release: и информация о коммите

[Dmitry V. Levin]

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

On Tue, Nov 01, 2011 at 02:50:09AM +0400, Dmitry V. Levin wrote:
> On Tue, Nov 01, 2011 at 02:43:54AM +0400, Dmitry V. Levin wrote:
> > Если вы собираете снапшоты, и вам очень хочется отразить эту информацию в
> > номере версии пакета, но никаких гарантий от апстрима у вас нет, то вы
> > можете попробовать дать пакету версию X.Y.Z.0.snap, где 0 это ноль,
> > который апстримы очень редко используют в таком качестве,
> 
> А также X.Y.Z.0.0.snap, X.Y.Z.0.0.0.snap и т.п., в зависимости от того,
> насколько велико ваше стремление застраховаться от превратностей апстрима. :)

Шутки шутками, но сейчас в Сизифе 33 пакета с версией вида a.b.c.0, еще 5
пакетов с версией вида a.b.c.d.0, и пока что ни одного с версией вида
a.b.c.d.e.0.  Так что принцип зануления не лишен смысла.


-- 
ldv

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

Re: [devel] [RFC] Release: и информация о коммите

[Aleksey Avdeev]

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

01.11.2011 02:43, Dmitry V. Levin пишет:
> On Tue, Nov 01, 2011 at 02:14:03AM +0400, Aleksey Avdeev wrote:
>>   Имею в виду следующее:
>>
...
> Если вы собираете снапшоты, и вам очень хочется отразить эту информацию в
> номере версии пакета, но никаких гарантий от апстрима у вас нет, то вы
> можете попробовать дать пакету версию X.Y.Z.0.snap, где 0 это ноль,
> который апстримы очень редко используют в таком качестве, а snap -
> это некая характеристика, монотонно возрастающая с каждым снапшотом.

  Да, этот вариант лучше.

-- 

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



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

Re: [devel] [RFC] Release: и информация о коммите

[Mikhail Efremov]

On Mon, 31 Oct 2011 19:51:22 +0200 Michael Shigorin wrote:
> On Mon, Oct 31, 2011 at 09:33:21PM +0400, Gleb Fotengauer-Malinovskiy
> wrote:
> > "Если система контроля версий не предоставляет линейной нумерации 
> > коммитов, то с каждым новым срезом нужно увеличивать номер релиза"
> > Мне кажется, тут нужно убрать разделение и увеличивать номер релиза
> > всегда.
> 
> Жду отзывов и если веских доводов против такой _рекомендации_
> не будет -- добавляю в секцию:
> 
> "Если для данного пакета версия снапшота не является важной
> характеристикой (например, как для крайне редко делающего
> нумерованные релизы mplayer) -- может быть лучше не засорять
> излишне низкоуровневой информацией тег Release:, достаточно
> увеличить номер релиза".

Я считаю информацию о том, что пакет собирается не из честного релиза,
а из девелоперского среза, важной. Хотя бы потому, что код и поведение
программы в релизе и в срезе могут быть сильно разными. И узнавать об
этом удобно просто глядя на %version-%release, в changelog же пакета я
смотрю только если нужна какая-то более подробная информация. Каждый
раз же читать changelog, чтобы узнать, действительно ли это версия
1.2.3 или на самом деле там собрано что-то совсем другое, мягко
выражаясь, неудобно.
Можно просто взять за правило всегда увеличивать номер релиза при
сборке snapshot'а, но при этом добавлять к релизу соответствующую
информацию (о чем, собственно, Глеб и писал), это снимет проблему.

-- 
WBR, Mikhail Efremov