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
Потрудитесь для начала прочитать 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: Багу закрываю.
