#21905 – генерация кривых версий

Bug 21905 - генерация кривых версий

Summary: генерация кривых версий

Status:	CLOSED FIXED

Alias:	None

Product:	Sisyphus
Classification:	Development
Component:	rpm-macros-branch (show other bugs)
Version:	unstable
Hardware:	all Linux

Importance:	P3 normal
Assignee:	Nobody's working on this, feel free to take it
QA Contact:	qa-sisyphus

URL:
Keywords:

Depends on:
Blocks:

Reported:	2009-10-10 16:40 MSD by Dmitry A. Kharitonov
Modified:	2012-03-16 14:01 MSK (History)
CC List:	3 users (show)

See Also:

Attachments
test.case (190 bytes, application/x-shellscript) 2009-10-10 16:40 MSD, Dmitry A. Kharitonov	no flags	Details
Добавлена сортировка (345 bytes, text/plain) 2009-10-11 15:33 MSD, Dmitry A. Kharitonov	no flags	Details
Добавлена сортировка и сравнение по правилам rpm (2.17 KB, text/plain) 2009-10-22 12:06 MSD, Dmitry A. Kharitonov	no flags	Details
Добавлена сортировка и сравнение по правилам rpm (2.18 KB, application/x-shellscript) 2009-10-22 12:28 MSD, Dmitry A. Kharitonov	no flags	Details
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description

Dmitry A. Kharitonov 2009-10-10 16:40:25 MSD

Created attachment 3981 [details]
test.case

Сейчас так:
bash test.sh
alt1.10: alt1.10 alt1.9.M50.1 alt1.9.M41.1 alt1.9.M40.1
хотелось бы видеть так:
alt1.10: alt1.10 alt0.M50.10 alt0.M41.10 alt0.M40.10

Comment 1

Sir Raorn 2009-10-10 19:04:19 MSD

Потрудитесь для начала прочитать Backports Policy.

Comment 2

Michael Shigorin 2009-10-11 14:19:54 MSD

2 raorn: кажется, это недоразумение получило когда-то поддержку в etersoft-build-utils, но вообще подобная нумерация (с включением непосредственно релиза, который бэкпортится) в своё время обсуждалась для какого-то нетривиального случая и вовсе не в качестве правила.

2 kharpost: Лёша правду говорит, всё-таки стоит сперва знакомиться хотя бы при развешивании багов с тем, чтобы сослаться на основание для такого изменения (или обсудить неясность).

Comment 3

Dmitry A. Kharitonov 2009-10-11 15:25:37 MSD

Вы сами-то читали?

http://www.altlinux.org/Spec:
Release 
Для пакетов Sisyphus поле Release должно иметь вид в простых случаях — altN, а в сложных (см. ниже) — altN[суффикс]. 
Релиз пакета используется для указания номера сборки пакета при данной версии upstream-кода, N начинается с 1 для каждой новой upstream-версии и увеличивается на 1 для каждой новой сборки: 
1.0-alt1 
1.0-alt2 
1.0-alt3 
1.1-alt1 
1.2-alt1 
1.2-alt2 
 … 
Два особых случая — это упаковка промежуточных релизов upstream-кода и упаковка бэкпортов. 
[править] Промежуточные upstream-релизы 
При сборке промежуточных релизов upstream-кода (срезов по дате, по системе контроля версий), следует указывать информацию о срезе в поле Release: 
1.0-alt1.r6543 
1.0-alt1.20080101 
1.0-alt1.rc1 
1.0-alt1.rc2 
1.0-alt1.gitda39a3ee 
Если система контроля версий не предоставляет линейной нумерации коммитов, то с каждым новым срезом нужно увеличивать номер релиза: 
1.0-alt1.hg.da39a3ee 
1.0-alt2.hg.0d3255bf 
1.0-alt3.hg.fef95601 
Для линеаризации номера версии в git можно использовать git describe: 
1.0-alt1.git1.5.4-1-g18208b2 
1.0-alt1.git1.5.4-2-93f1595a 
1.0-alt1.git1.5.4-3-8be800af 
При первой сборке финального upstream-релиза следует поднять номер релиза пакета: 
1.0-alt1.gitda39a3ee 
1.0-alt2.gitd06f1866 
1.0-alt3 
Использовать релиз alt0 запрещено — пакет с таким релизом, попав в репозиторий, порождает проблемы с бэкпортами.

http://www.altlinux.org/BackportsPolicy
Правила нумерации релизов 
Релизы нумеруются следующим образом: ADAPTED_RELEASE.DISTRO.BACKPORT_RELEASE. Таким образом, полное наименование пакета будет таким: %name-%version-ADAPTED_RELEASE.DISTRO.BACKPORT_RELEASE 
К примеру, первый бэкпорт пакета foo-1.0-alt1 на branch/4.0 будет выглядеть как foo-1.0-alt0.M40.1. 
Где: 
 ADAPTED_RELEASE — релиз, выбраный таким образом, что ORIG_RELEASE <= ADAPTED_RELEASE < SISYPHUS_RELEASE. 
 Рекомендуемое значение — SISYPHUS_RELEASE - 1. 
 ORIG_RELEASE — строка, описывающая релиз пакета, из которого «растёт» данная ветка (который был переложен в бранч из Сизифа); 
 SISYPHUS_RELEASE — релиз пакета в Сизифе, на базе которого делался backport пакет; 
 BACKPORT_RELEASE — номер релиза пакета внутри репозитория backports. Нумерация начинается с 1. 
 DISTRO — дистрибутив, на который осуществляется портирование.
При обновлении в бэкпортах до новой версии (%version) пакета, BACKPORTS_RELEASE сбрасывается в 1 и ORIG_RELEASE устанавливается в alt0. 
Такая схема версионирования выбрана потому, что новая версия пакета, собираемого в backports, должна иметь номер релиза меньший, чем та же версия в Сизифе, но при этом не меньший, чем та же версия в backports для предыдущих серий.

Ещё была ссылка -- не нашёл -- там показаны были релизы в бэкпорты с указанием подсборок
Таким образом, макрос противоречит документации.

Comment 4

Dmitry A. Kharitonov 2009-10-11 15:33:46 MSD

Created attachment 3982 [details]
Добавлена сортировка

Comment 5

solo 2009-10-11 17:00:48 MSD

См.
http://www.altlinux.org/BackportsPolicy#.D0.9F.D1.80.D0.B0.D0.B2.D0.B8.D0.BB.D0.B0_.D0.BD.D1.83.D0.BC.D0.B5.D1.80.D0.B0.D1.86.D0.B8.D0.B8_.D1.80.D0.B5.D0.BB.D0.B8.D0.B7.D0.BE.D0.B2

<cite>Если необходимо предотвратить возможность обновления с релиза вида
alt0.DISTRO.REVISION до сизифовского alt7 при наличии в Сизифе alt8 (в том
числе в случае серьёзной ошибки, исправленной в alt8), можно сделать релиз вида
alt7.DISTRO.REVISION, при условии что за основу взят именно alt8 а не
alt7.<cite>

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

  По примерам:

 (В ответ на комментарий №0)
> bash test.sh
> alt1.10: alt1.10 alt1.9.M50.1 alt1.9.M41.1 alt1.9.M40.1

  При этом, для apt/rpm: alt1.10 > alt1.9.M50.1 > alt1.9.M41.1 > alt1.9.M40.1

  Тогда для alt1.11 (который > alt1.10) будет так:

alt1.11: alt1.11 > alt1.10.M50.1 > alt1.10.M41.1 > alt1.10.M40.1

  И alt1.10.M50.1 < alt1.10 => новый пакет не будет заменён старым (пусть и из
Сизифа).

 (В ответ на комментарий №0)
> хотелось бы видеть так:
> alt1.10: alt1.10 alt0.M50.10 alt0.M41.10 alt0.M40.10

  Тогда для alt1.11 (который > alt1.10) будет так:

alt1.11: alt1.11 > alt0.M50.11 > alt0.M41.11 > alt0.M40.11

  Но: alt0.M50.11 < alt1.10 => более новый пакет будет заменён на старый (но из
Сизифа).

Comment 6

Dmitry A. Kharitonov 2009-10-11 17:13:32 MSD

> 
>   Тогда для alt1.11 (который > alt1.10) будет так:
> 
> alt1.11: alt1.11 > alt0.M50.11 > alt0.M41.11 > alt0.M40.11
> 
>   Но: alt0.M50.11 < alt1.10 => более новый пакет будет заменён на старый (но из
> Сизифа).
Если переходишь на сизиф -- то будет заменён (но не на старую), а если не переходишь -- почему он должен заменится? По правилам у нас в сизифе не может быть более старой версии.
И зачем тогда бесполезная .1 после М*?

Comment 7

Sir Raorn 2009-10-11 17:27:37 MSD

Рекомендую сначала думать, а потом писать комментарии.  Может тогда и писать ничего не придётся.

Наличие в сизифе пакета с release равным alt1.10 не исключает присутствие в бранче пакета с release равным, например, alt1.4 и пакет с release alt0.M*.1 его не заменит.

"Бесполезная .1 после .M*" нужна для сборки нового пакета только в этот бранч, без заливки ненужного хлама во все репозитарии.

Comment 8

Dmitry A. Kharitonov 2009-10-11 17:51:48 MSD

(В ответ на комментарий №7)
> Рекомендую сначала думать, а потом писать комментарии.  Может тогда и писать
> ничего не придётся.
Перестаньте хамить. 
> Наличие в сизифе пакета с release равным alt1.10 не исключает присутствие в
> бранче пакета с release равным, например, alt1.4 и пакет с release alt0.M*.1
> его не заменит.
Link?
> 
> "Бесполезная .1 после .M*" нужна для сборки нового пакета только в этот бранч,
> без заливки ненужного хлама во все репозитарии.
Тогда вы вероятно знаете как: эту единицу поднять с помощью данного макроса?

Comment 9

solo 2009-10-11 19:48:27 MSD

(В ответ на комментарий №8)
> (В ответ на комментарий №7)
...
> > Наличие в сизифе пакета с release равным alt1.10 не исключает присутствие в
> > бранче пакета с release равным, например, alt1.4 и пакет с release alt0.M*.1
> > его не заменит.
> Link?

  Сходу не укажу, но данная ситуация типична, т. к. основа бранча -- срез Сизифа в некоторый момент времени. Т. е.:

1. В Сизифе -- altN.M

2. Отпочковывается бранч => altN.M переезжает туда.

3. В Сизифе пакет обновился до altN.M+1

4. Пробуем поместить пикет в бранч: Текущий алгоритм (в макросе) сгенирирует altN.M.<бранч>.1, который спокойно обновит пакет в бранче. Твой -- altN-1.<бранч>.M... И как собираешся вытеснять altN.M?

> > 
> > "Бесполезная .1 после .M*" нужна для сборки нового пакета только в этот бранч,
> > без заливки ненужного хлама во все репозитарии.
> Тогда вы вероятно знаете как: эту единицу поднять с помощью данного макроса?

  Определив макрос %branch_release_num...

Comment 10

solo 2009-10-11 19:52:02 MSD

(В ответ на комментарий №3)
...
> 
> Ещё была ссылка -- не нашёл -- там показаны были релизы в бэкпорты с указанием
> подсборок
> Таким образом, макрос противоречит документации.

  Цитирую ещё раз http://www.altlinux.org/BackportsPolicy:

Если необходимо предотвратить возможность обновления с релиза вида
alt0.DISTRO.REVISION до сизифовского alt7 при наличии в Сизифе alt8 (в том
числе в случае серьёзной ошибки, исправленной в alt8), можно сделать релиз вида
alt7.DISTRO.REVISION, при условии что за основу взят именно alt8 а не
alt7.

Comment 11

Dmitry A. Kharitonov 2009-10-11 20:24:01 MSD

(В ответ на комментарий №9)
>   Сходу не укажу, но данная ситуация типична, т. к. основа бранча -- срез
> Сизифа в некоторый момент времени. Т. е.:
> 
> 1. В Сизифе -- altN.M
> 
> 2. Отпочковывается бранч => altN.M переезжает туда.
> 
> 3. В Сизифе пакет обновился до altN.M+1
> 
> 4. Пробуем поместить пикет в бранч: Текущий алгоритм (в макросе) сгенирирует
> altN.M.<бранч>.1, который спокойно обновит пакет в бранче. Твой --
> altN-1.<бранч>.M... И как собираешся вытеснять altN.M?
> 
Очень просто: altN+1. ...
Или есть ограничения на максимальный N?
> > > 
> > > "Бесполезная .1 после .M*" нужна для сборки нового пакета только в этот бранч,
> > > без заливки ненужного хлама во все репозитарии.
> > Тогда вы вероятно знаете как: эту единицу поднять с помощью данного макроса?
> 
>   Определив макрос %branch_release_num...
тогда другое дело: это меня устраивает.
Только наверное удобнее это оформить вторым параметром.

Comment 12

solo 2009-10-11 21:12:48 MSD

(В ответ на комментарий №11)
> (В ответ на комментарий №9)
> >   Сходу не укажу, но данная ситуация типична, т. к. основа бранча -- срез
> > Сизифа в некоторый момент времени. Т. е.:
> > 
> > 1. В Сизифе -- altN.M
> > 
> > 2. Отпочковывается бранч => altN.M переезжает туда.
> > 
> > 3. В Сизифе пакет обновился до altN.M+1
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > 
> > 4. Пробуем поместить пикет в бранч: Текущий алгоритм (в макросе) сгенирирует
> > altN.M.<бранч>.1, который спокойно обновит пакет в бранче. Твой --
> > altN-1.<бранч>.M... И как собираешся вытеснять altN.M?
> > 
> Очень просто: altN+1. ...
> Или есть ограничения на максимальный N?

  Нет. Но по условию задачи -- в Сизифе altN.M+1 (см. выше), и этот altN.M+1 < altN+1... Или собираешся требовать _обязательного_ роста N? Он у нас не всегда возможен.

  В частности см. http://www.altlinux.org/NMU: Если пакет обновлял не мантейнер, то увеличивать N он права не имеет, но может добавить/увеличить M. А это -- как раз тот случай, который я описал выше.

> > > > 
> > > > "Бесполезная .1 после .M*" нужна для сборки нового пакета только в этот бранч,
> > > > без заливки ненужного хлама во все репозитарии.
> > > Тогда вы вероятно знаете как: эту единицу поднять с помощью данного макроса?
> > 
> >   Определив макрос %branch_release_num...
> тогда другое дело: это меня устраивает.
> Только наверное удобнее это оформить вторым параметром.

  Для скрипта branch_release это и есть второй параметр. Для макроса же --  патчи приветствуются.

Comment 13

Dmitry A. Kharitonov 2009-10-11 21:38:05 MSD

>   Нет. Но по условию задачи -- в Сизифе altN.M+1 (см. выше), и этот altN.M+1 <
> altN+1... Или собираешся требовать _обязательного_ роста N? Он у нас не всегда
> возможен.
> 
>   В частности см. http://www.altlinux.org/NMU: Если пакет обновлял не
> мантейнер, то увеличивать N он права не имеет, но может добавить/увеличить M. А
> это -- как раз тот случай, который я описал выше.
> 
Если я правильно понимаю N -- номер сборки в альте. M -- номер подсборки. Номер сборки правильнее менять при каждой сборке (обновлении пакета), а M нужно увеличивать, когда эта сборка не прошла и требуется повторная сборка.
такого подхода требует www.altlinux.org/Spec.

Comment 14

solo 2009-10-11 22:10:33 MSD

(В ответ на комментарий №13)
> >   Нет. Но по условию задачи -- в Сизифе altN.M+1 (см. выше), и этот altN.M+1 <
> > altN+1... Или собираешся требовать _обязательного_ роста N? Он у нас не всегда
> > возможен.
> > 
> >   В частности см. http://www.altlinux.org/NMU: Если пакет обновлял не
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > мантейнер, то увеличивать N он права не имеет, но может добавить/увеличить M. А
> > это -- как раз тот случай, который я описал выше.
> > 
> Если я правильно понимаю N -- номер сборки в альте. M -- номер подсборки. Номер
> сборки правильнее менять при каждой сборке (обновлении пакета), а M нужно
> увеличивать, когда эта сборка не прошла и требуется повторная сборка.
> такого подхода требует www.altlinux.org/Spec.

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

1. В случаи, если сборка не прошла -- для исправленной повышать релиз вообще не требуется: она зальётся и со старым релизом.

2. _Технически_ повышать релиз _необходимо_ только в одном случаи -- когда пакет со старым релизом в репозитории _уже_ есть: система не даст залить пакет, если его релиз <= релизу существующего.

3. Есть достаточно много случаев применения многоцифровых релизов. На вскидку:

a) NMU (см. выделенную ссылку);

b) пересборка роботом;

c) нумерация срезов (в частности то, что ты цитировал);

d) удобство мантейнера (например, я так нумерую тестовые версии);

e) пр.;

Comment 15

Dmitry A. Kharitonov 2009-10-22 12:06:57 MSD

Created attachment 3999 [details]
Добавлена сортировка и сравнение по правилам rpm

Comment 16

Dmitry A. Kharitonov 2009-10-22 12:27:02 MSD

Макрос генерирует правильно:
bash test.sh
alt1.10: alt1.10=alt1.10>alt1.9.M50.2>alt1.9.M50.1>alt1.9.M41.2>alt1.9.M41.1>alt1.9.M40.2>alt1.9.M40.1

alt1.p3: alt1.p3=alt1.p3>alt1.p2.M50.2>alt1.p2.M50.1>alt1.p2.M41.2>alt1.p2.M41.1>alt1.p2.M40.2>alt1.p2.M40.1

alt1.9: alt1.9=alt1.9>alt1.8.M50.2>alt1.8.M50.1>alt1.8.M41.2>alt1.8.M41.1>alt1.8.M40.2>alt1.8.M40.1

alt1.9.1: alt1.9.1=alt1.9.1>alt1.9.0.M50.2>alt1.9.0.M50.1>alt1.9.0.M41.2>alt1.9.0.M41.1>alt1.9.0.M40.2>alt1.9.0.M40.1

alt1.10.1: alt1.10.1=alt1.10.1>alt1.10.0.M50.2>alt1.10.0.M50.1>alt1.10.0.M41.2>alt1.10.0.M41.1>alt1.10.0.M40.2>alt1.10.0.M40.1

alt1.svn20090812: alt1.svn20090812=alt1.svn20090812>alt1.svn20090811.M50.2>alt1.svn20090811.M50.1>alt1.svn20090811.M41.2>alt1.svn20090811.M41.1>alt1.svn20090811.M40.2>alt1.svn20090811.M40.1

alt1.svn20090812.10: alt1.svn20090812.10=alt1.svn20090812.10>alt1.svn20090812.9.M50.2>alt1.svn20090812.9.M50.1>alt1.svn20090812.9.M41.2>alt1.svn20090812.9.M41.1>alt1.svn20090812.9.M40.2>alt1.svn20090812.9.M40.1

alt1.svn20090812.11: alt1.svn20090812.11=alt1.svn20090812.11>alt1.svn20090812.10.M50.2>alt1.svn20090812.10.M50.1>alt1.svn20090812.10.M41.2>alt1.svn20090812.10.M41.1>alt1.svn20090812.10.M40.2>alt1.svn20090812.10.M40.1

alt1.svn20090812.11=alt1.svn20090812.11>alt1.svn20090812.10.M50.2>alt1.svn20090812.10.M50.1>alt1.svn20090812.10.M41.2>alt1.svn20090812.10.M41.1>alt1.svn20090812.10.M40.2>alt1.svn20090812.10.M40.1>alt1.svn20090812.10=alt1.svn20090812.10>alt1.svn20090812.9.M50.2>alt1.svn20090812.9.M50.1>alt1.svn20090812.9.M41.2>alt1.svn20090812.9.M41.1>alt1.svn20090812.9.M40.2>alt1.svn20090812.9.M40.1>alt1.svn20090812=alt1.svn20090812>alt1.svn20090811.M50.2>alt1.svn20090811.M50.1>alt1.svn20090811.M41.2>alt1.svn20090811.M41.1>alt1.svn20090811.M40.2>alt1.svn20090811.M40.1>alt1.p3=alt1.p3>alt1.p2.M50.2>alt1.p2.M50.1>alt1.p2.M41.2>alt1.p2.M41.1>alt1.p2.M40.2>alt1.p2.M40.1>alt1.10.1=alt1.10.1>alt1.10.0.M50.2>alt1.10.0.M50.1>alt1.10.0.M41.2>alt1.10.0.M41.1>alt1.10.0.M40.2>alt1.10.0.M40.1>alt1.10=alt1.10>alt1.9.M50.2>alt1.9.M50.1>alt1.9.M41.2>alt1.9.M41.1>alt1.9.M40.2>alt1.9.M40.1>alt1.9.1=alt1.9.1>alt1.9.0.M50.2>alt1.9.0.M50.1>alt1.9.0.M41.2>alt1.9.0.M41.1>alt1.9.0.M40.2>alt1.9.0.M40.1>alt1.9=alt1.9>alt1.8.M50.2>alt1.8.M50.1>alt1.8.M41.2>alt1.8.M41.1>alt1.8.M40.2>alt1.8.M40.1

alt1.10>alt0.10.M50.2>alt0.10.M50.1>alt0.10.M41.2>alt0.10.M41.1>alt0.10.M40.2>alt0.10.M40.1

Очень смущает насильственное понижение релиза. Единственное, что можно предложить, так это не обязательное введение нового поля
alt1.10.1>alt1.10.0.M50.2>alt1.10.0.M50.1>alt1.10.0.M41.2>alt1.10.0.M41.1>alt1.10.0.M40.2>alt1.10.0.M40.1
Это уже выглядит много логичнее

Comment 17

Dmitry A. Kharitonov 2009-10-22 12:28:13 MSD

Created attachment 4000 [details]
Добавлена сортировка и сравнение по правилам rpm

Comment 18

solo 2009-10-29 15:52:59 MSK

(В ответ на комментарий №16)
> Макрос генерирует правильно:
...
> Очень смущает насильственное понижение релиза. Единственное, что можно
> предложить, так это не обязательное введение нового поля
> alt1.10.1>alt1.10.0.M50.2>alt1.10.0.M50.1>alt1.10.0.M41.2>alt1.10.0.M41.1>alt1.10.0.M40.2>alt1.10.0.M40.1
> Это уже выглядит много логичнее

  Но требует дополнительных ограничений на формат релиза... Не думаю,что оно (ограничение) обосновано.

PS: Багу закрываю.