Semver обратно не совместим с нашим версионированием.

(In reply to Anton Farygin from comment #0)
> Было бы неплохо начать поддерживать стандарт semver в rpm-build (в rpmvercmp
> поддержка ~ есть)

А какую задачу ты пытаешься этим решить ?

> '/usr/bin/hsh-buildreq-filter' -> 'chroot/.host/hsh-buildreq-filter'
> error: line 2: Invalid symbol '~' (0x7e) in: Version: 2.0~rc1
> hsh-rebuild: pkg.tar: failed to fetch build dependencies.
> 
> https://semver.org/

По указанной ссылке я не нашёл ничего про использование символа '~'.

(In reply to Anton Farygin from comment #0)
> (в rpmvercmp поддержка ~ есть)

Какая? Я не видел.

(In reply to Alexey Gladkov from comment #2)
> (In reply to Anton Farygin from comment #0)
[...]
> > https://semver.org/
> 
> По указанной ссылке я не нашёл ничего про использование символа '~'.

Наверное, имеется ввиду пункт 9:

A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version.

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

А вот что-то типа дебиановской тильды ('~') было бы удобно, но не уверен, что стоит того.

(Ответ для Alexey Gladkov на комментарий #2)
> (In reply to Anton Farygin from comment #0)
> > Было бы неплохо начать поддерживать стандарт semver в rpm-build (в rpmvercmp
> > поддержка ~ есть)
> 
> А какую задачу ты пытаешься этим решить ?

поддержка prerelease

> 
> > '/usr/bin/hsh-buildreq-filter' -> 'chroot/.host/hsh-buildreq-filter'
> > error: line 2: Invalid symbol '~' (0x7e) in: Version: 2.0~rc1
> > hsh-rebuild: pkg.tar: failed to fetch build dependencies.
> > 
> > https://semver.org/
> 
> По указанной ссылке я не нашёл ничего про использование символа '~'.

Пункт 9. В Debian и Redhat реализован как 1.0~pre1

(Ответ для Ivan A. Melnikov на комментарий #4)
> (In reply to Alexey Gladkov from comment #2)
> > (In reply to Anton Farygin from comment #0)
> [...]
> > > https://semver.org/
> > 
> > По указанной ссылке я не нашёл ничего про использование символа '~'.
> 
> Наверное, имеется ввиду пункт 9:
> 
> A pre-release version MAY be denoted by appending a hyphen and a series of
> dot separated identifiers immediately following the patch version.
> 
> Сейчас в версии и релизе использовать '-' нельзя, и пожалуйста, путь дальше
> так оно и будет, очень много чего сломается.
> 
> А вот что-то типа дебиановской тильды ('~') было бы удобно, но не уверен,
> что стоит того.

Хорошо, давайте пойдём по пути добавления ~, как сделано в Debian и RedHat.
Кстати, вот наш код в rpmvercmp, который разбирает сепаратор отдельно. Но он явно неполный.
https://git.altlinux.org/gears/r/rpm.git?p=rpm.git;a=blob;f=lib/rpmvercmp.c;h=93bb4ff644e92460b331d57bd06d5a368d9b1eb6;hb=6c89c4112caf5491c4510def4ec2d2689b748c65#l42

> А вот что-то типа дебиановской тильды ('~') было бы удобно, но не уверен, что стоит того.

Сравнение версий между разными дистрибутивам не учитывает то, что мы по нашим правилам prerelease выносим в тэг release. Собирая пакеты  и ставя им невышешдшую версию мы сильно усложняем жизнь тем, кто хоть как-то сравнивает версии пакетов с чем-то, что не наше - например, это может касаться поиска CVE или ресурсов вроде https://repology.org

Пример использования тильды для отделения prerelease, собственно с которого и возникло предложение добавить к нам такое же поведение:
https://repology.org/project/libcupsfilters/versions

(In reply to Anton Farygin from comment #6)
> Кстати, вот наш код в rpmvercmp, который разбирает сепаратор отдельно. Но он
> явно неполный.
> https://git.altlinux.org/gears/r/rpm.git?p=rpm.git;a=blob;f=lib/rpmvercmp.c;
> h=93bb4ff644e92460b331d57bd06d5a368d9b1eb6;
> hb=6c89c4112caf5491c4510def4ec2d2689b748c65#l42

А что там не полного? Вроде все ок.

(Ответ для Vitaly Chikunov на комментарий #9)
> (In reply to Anton Farygin from comment #6)
> > Кстати, вот наш код в rpmvercmp, который разбирает сепаратор отдельно. Но он
> > явно неполный.
> > https://git.altlinux.org/gears/r/rpm.git?p=rpm.git;a=blob;f=lib/rpmvercmp.c;
> > h=93bb4ff644e92460b331d57bd06d5a368d9b1eb6;
> > hb=6c89c4112caf5491c4510def4ec2d2689b748c65#l42
> 
> А что там не полного? Вроде все ок.

Да, сейчас пересмотрел - вроде как действительно всё ок.
Т.е. - фактически надо разрешить его использование.

Поддержка тильды в Fedora rpm c 2012, а с 2016 ещё поддерживается карет.

В gnulib дебиановский алгоритм с 2008 (filevercmp, он же используется в `sort -V`) - тильда там есть, а карета нет.

  $ sort -V < a
  1.0~p1
  1.0-p1
  1.0.0-p1
  1.0^p1

https://git.altlinux.org/tasks/323684/

Предлагаю еще такое изменение в rpmvercmp:

https://git.altlinux.org/people/vt/packages/?p=rpm.git;a=commitdiff;h=2479d45000a84fe5ff8a2dd27bc150d8d40a329c

- Поддерживает evr:disttag@buildtime по опции --evr.
- Может сортировать stdin (аналог sort -V) по --sort.
- Может сортировать вывод rpm -qa, apt-cache pkgnames (то есть с префиксом имени пакета перед версией), по --names, --pkgnames, --separator=#.

*** Bug 46707 has been marked as a duplicate of this bug. ***

rpm-build-4.0.4.192-alt1 -> sisyphus:

 Sun Sep 10 2023 Vitaly Chikunov <vt@altlinux> 4.0.4.192-alt1
 - Backport support of tilde in version & release (ALT#46585).

Спасибо. А можете ещё это же изменение бэкпортировать во все поддерживаемые бранчи ?
Что бы не было проблем со сборкой пакетов из sisyphus для, например, p9 или p10

(In reply to Anton Farygin from comment #16)
> Спасибо. А можете ещё это же изменение бэкпортировать во все поддерживаемые
> бранчи ?
> Что бы не было проблем со сборкой пакетов из sisyphus для, например, p9 или
> p10
Я так понимаю, что это пока что скорее задел на будущее -- сборочница сейчас такую версию не должна пропустить.

Мы выясняли с ldv что нельзя только в p8 (там слишком старый rpm). А можно ли в p9 я не знаю. В p10 rpm-build копировался недавно так что наверное технически можно и туда добавить. В любом случае ещё кто-то должен внести правку в sisyphus_check и check/101-check-policydeps.

(In reply to Gleb F-Malinovskiy from comment #17)
> (In reply to Anton Farygin from comment #16)
> > Спасибо. А можете ещё это же изменение бэкпортировать во все поддерживаемые
> > бранчи ?
> > Что бы не было проблем со сборкой пакетов из sisyphus для, например, p9 или
> > p10
> Я так понимаю, что это пока что скорее задел на будущее -- сборочница сейчас
> такую версию не должна пропустить.

На четвёртый день индеец Зоркий Глаз в лице меня обнаружил, что у сарая нет стены: выходят релизы пакетов[1], которые собираются только пререлизным[2] clang, и это всё не просто собирается "в карман", а попадает в Sisyphus.
[1] https://git.altlinux.org/gears/y/yuzu.git?p=yuzu.git;a=commitdiff;h=d40f8e53daa659741e4e3a9b6bd06f6e0fc3ebea
[2] https://git.altlinux.org/gears/l/llvm17.0.git?p=llvm17.0.git;a=shortlog;h=727c542f89160731ff8a1894f1629dd1508a17af

Поэтому до этого инцидента я склонялся не торопиться и не настаивать на разрешении тильд в sisyphus-check к выходу p11, а теперь прихожу к выводу, что надо их там разрешить.

Завёл отдельную багу на sisyphus-check.

(Ответ для Arseny Maslennikov на комментарий #19)
...
> Завёл отдельную багу на sisyphus-check.
https://bugzilla.altlinux.org/47589

Мы ставим версию-релиз в тэгах, а тильда спецсимвол для git.

(In reply to Vitaly Chikunov from comment #21)
> Мы ставим версию-релиз в тэгах, а тильда спецсимвол для git.
Т. е. надо придумать какую-то подстроку вместо тильды, которая попадёт в git tag. Главное, чтобы gear-create-tag автоматически работал.

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

(In reply to Vitaly Chikunov from comment #23)
> Думаю, это невозможно придумать. А если где-то есть проверки на наличие
> версии в тэге, то все они
...уже бы давали отрицательный ответ: как минимум в тег не попадает Epoch.
Сортировкой заглавий git-тегов тоже никто не занимается, они не для этого.

> Так что можно откатывать поддержку
> тильды отовсюду, это была тупиковая идея.
Не могу согласиться.

(In reply to Arseny Maslennikov from comment #24)
> (In reply to Vitaly Chikunov from comment #23)
> > Думаю, это невозможно придумать. А если где-то есть проверки на наличие
> > версии в тэге, то все они
> ...уже бы давали отрицательный ответ: как минимум в тег не попадает Epoch.

ЕСЛИ заменить в %version-%release хоть 1 символ, ТО сравнение уже не выполнится.

Арсений прав в смысле epoch и если вся проблема в gear-create-tag, мы могли бы мапить ~ во что-то имя.

А мы хоть где-то сравниваем версии между пакетом и тегом?  Если нет, то обратно мапить его на самом деле не нужно.

есть готовые маппинги для версий с тильдами в гит у debin. Эпоху, кстати, тоже маппят. 
Не вижу в этом вообще никаких проблем