Чтобы опубликовать RPM-пакеты для нескольких различных версий некоторого программного обеспечения, я ищу способ указать «номера версий», которые считаются «обновлениями», и включить различение нескольких предварительных версий, таких как (в порядке ): «2.4.0 alpha 1», «2.4.0 alpha 2», «2.4.0 alpha 3», «2.4.0 beta 1», «2.4.0 beta 2», «2.4.0 релиз-кандидат», «2.4.0 финал», «2.4.1», «2.4.2» и т. Д.
Основная проблема, с которой я столкнулся, заключается в том, что RPM считает, что «2.4.0» предшествует «2.4.0.alpha1», поэтому я не могу просто добавить суффикс в конце номера окончательной версии.
Я мог бы попробовать "2.4.0.alpha1", "2.4.0.beta1", "2.4.0.final", которые будут работать, за исключением "релиз-кандидата", который будет рассматриваться позже, чем "2.4.0.final". ".
Альтернативой, которую я рассмотрел, является использование раздела «эпоха:» номера версии RPM (префикс эпохи: считается перед основным номером версии, так что «1: 2.4.0» фактически предшествует «2: 1.0.0») . Если поставить отметку времени в поле epoch :, все версии будут упорядочены, как и ожидалось RPM, потому что их версии увеличиваются во времени. Однако это не удается, когда новые выпуски выпускаются для нескольких основных версий одновременно (например, 2.3.2 выпущен после 2.4.0, но их версия для RPM - «20121003: 2.3.2» и «20120928: 2.4. 0 », а системы на 2.3.2 не могут быть« обновлены »до 2.4.0, потому что rpm считает его более старой версией). В этом случае yum / zypper / etc отказываются обновляться до 2.4.0, поэтому моя проблема.
Какие номера версий я могу использовать для этого и убедиться, что RPM всегда считает номера версий правильными. Или, если не номера версий, другой механизм в упаковке RPM?
Примечание 1: Я хотел бы сохранить поле «Release:» в файле спецификации для его первоначальной цели (несколько выпусков пакетов, включая изменения упаковки, для одной и той же версии упакованного программного обеспечения).
Примечание 2: это должно работать на текущих производственных версиях основных дистрибутивов, таких как RHEL / CentOS 6 и SLES 11. Но меня интересуют решения, которые тоже этого не делают, если они не включают перекомпиляцию rpm!
Примечание 3: В системах, подобных Debian, dpkg использует специальный компонент в номере версии, который представляет собой символ «~» (тильда). Это заставляет dpkg считать суффикс «отрицательным» порядком, так что «2.4.0 ~ something» будет стоять перед «2.4.0». Затем после символа «~» применяется нормальный порядок, поэтому «2.4.0 ~ alpha1» идет перед «2.4.0 ~ beta1», потому что «alpha» идет перед «beta» по алфавиту. Я не обязательно хочу использовать ту же схему для пакетов RPM (я почти уверен, что такого эквивалента не существует), так что это просто к сведению.
Fedora имеет набор рекомендации по установке номера версии / выпуска предварительных пакетов. Обычно вы используете номер версии того, что будет последним выпуском в Version, и запустите Release номер с 0., увеличивающееся число, а затем alpha, beta или что угодно. Вы не будете использовать буквенно-цифровой тег final для финального релиза вообще.
Обратите внимание, что вы не можете рассчитывать на то, что RPM будет поддерживать управление версиями тильды в стиле Debian. В некоторых дистрибутивах эта функция отключена.
В официальные инструкции по оборотам расскажите, как это сделать, и ссылки на страница примеров. Вот пример того, как вы будете работать с очень распространенной схемой управления версиями, которая использует три уровня предварительного выпуска (a, b, rc) (который, к сожалению, немного усложняет поддержку rpm):
Я не поклонник различий между альфа и бета. Есть выпущенный код и невыпущенный код.
Как я это делаю: мне нравится major.minor.build с системой непрерывной интеграции (см. JenkinsCI). Целое число сборки никогда не сбрасывается. Незначительные изменения номера версии предназначены для изменений с обратной совместимостью. Значительные изменения числа - большие дела.
Если маркетингу не нравится, что «сборка» представляет собой большие целые числа, вы можете увеличивать меньшее число один раз для маркетинга только для выпущенных сборок, а затем еще раз, когда дело доходит до разработки.
Я столкнулся с аналогичной проблемой, и мне пришлось сравнить версии пакетов RedHat, Debian, Python и гемов Ruby, чтобы унифицировать номер набора, и это помогло мне оценить «больше» и «меньше» в каждом случае:
Это сравнение 1.3.0.post0.dev20180213210433 с 1.3.0, YMMV
для Red Hat (спасибо https://utcc.utoronto.ca/~cks/space/blog/linux/RPMShellVersionComparison )
docker run -ti centos:7
yum install rpmdevtools.noarch
rpmdev-vercmp "1.3.0" "1.3.0.post0.dev20180213210433"
1.3.0 < 1.3.0.post0.dev20180213210433
Для Debian:
$ dpkg --compare-versions 1.3.0 gt 1.3.0.post0.dev20180213210433 ; echo $?
1 # false
$ dpkg --compare-versions 1.3.0 lt 1.3.0.post0.dev20180213210433 ; echo $?
0 # true
Для Python
>>> from pkg_resources import parse_version
>>> parse_version("1.3.0") > parse_version("1.3.0.post0.dev20180213210433")
False
>>> parse_version("1.3.0") < parse_version("1.3.0.post0.dev20180213210433")
True
Для Руби
irb(main):001:0> Gem::Version.new("1.3.0") > Gem::Version.new("1.3.0.post0.dev20180213210433")
=> true
irb(main):002:0> Gem::Version.new("1.3.0") < Gem::Version.new("1.3.0.post0.dev20180213210433")
=> false
Начиная с версии 4.10.0, RPM официально поддерживает нумерацию тильд в стиле dpkg, упомянутую в вопросе.