Возрастающая версия RPM-пакета “числа” для x.y.z> x.y.z-бета (или альфа, дистанционное управление, и т.д.)
Я не уверен, что Вы пытаетесь сделать точно, но если Вы просто пытаетесь запустить приложение (такое как командная строка) как тот пользователь, Вы используете runas команда:
runas /user:domain\user cmd
runas /user:user@domain.com iexplore.exe
Это откроет командную строку, работающую как та указанная учетная запись домена. (Обратите внимание, что машина, от которой Вы работаете, должна будет знать, как достигнуть того домена....),
Выполнение cmd может позволить Вам выполнять что-либо (сценарии, другие приложения, окна проводника) как та другая дипломированная учетная запись как тот пользователь - дочерние процессы порождены в соответствии с учетной записью родителя.
(Если это не отвечает на Ваш вопрос, разъясните то, что Вы пытаетесь сделать.)
Официальные руководящие принципы rpm рассказывают, как это сделать, и ссылаются на страницу с примерами . Вот пример того, как вы будете работать с очень распространенной схемой управления версиями, которая использует три уровня предварительного выпуска (a, b, rc) (который, к сожалению, немного усложняет поддержку с помощью rpm):
- 1.0.0a1 -> 1.0.0-0.1.a1
- 1.0.0b1 -> 1.0.0-0.1.b1
- 1.0.0b2 -> 1.0.0-0.1.b2
- 1.0.0b2, второй выпуск (настройка упаковки 1.0.0b2) -> 1.0.0-0.2.b2
- 1.0.0rc1 -> 1.0.0-0.1.rc1
- 1.0.0 -> 1.0.0-1
- 1.0.1a1 -> 1.0 .1-0.1.a1
- 1.0.1 -> 1.0.1-1
В Fedora есть набор рекомендаций по установке номера версии / выпуска предварительных пакетов . Обычно вы используете номер версии того, что будет окончательным выпуском в версии , и начинаете номер выпуска с 0. , увеличивающийся номер, а затем альфа , бета или что угодно. Вы вообще не будете использовать буквенно-цифровой тег final для окончательного выпуска.
Обратите внимание, что вы не можете рассчитывать на то, что RPM поддерживает управление версиями тильды в стиле Debian. В некоторых дистрибутивах эта функция отключена.
Я не сторонник различий между альфа и бета. Есть выпущенный код и невыпущенный код.
Как я это делаю: I like the major.minor.build with a continuous integration system (see JenkinsCI). Build integer is never reset. Minor version number changes are for backwards compatible changes. Major number changes are big deals.
If marketing does not like the "build" to be large integers, you can increment the minor number once for marketing only on builds that are released, and then again when it goes to engineering.
Я столкнулся с аналогичной проблемой, и мне пришлось сравнить версии между пакетами 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
Для Ruby
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, упомянутую в вопросе.