Bug 21905

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

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

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

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

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 для предыдущих серий.

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

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

См.
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 => более новый пакет будет заменён на старый (но из
Сизифа).

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

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

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

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

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

(В ответ на комментарий №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...

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

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

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

(В ответ на комментарий №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...
тогда другое дело: это меня устраивает.
Только наверное удобнее это оформить вторым параметром.

(В ответ на комментарий №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 это и есть второй параметр. Для макроса же --  патчи приветствуются.

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

(В ответ на комментарий №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) пр.;

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

Макрос генерирует правильно:
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
Это уже выглядит много логичнее

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

(В ответ на комментарий №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: Багу закрываю.