web-dev-qa-db-ja.com

x.y.z> x.y.z-beta（またはalpha、rcなど）の増分RPMパッケージバージョン「番号」

一部のソフトウェアのいくつかの異なるバージョンの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 final」、「2.4.1」、「2.4.2」など.

これに関して私が抱えている主な問題は、RPMが「2.4.0」が「2.4.0.alpha1」よりも前に来ると見なしているため、最終バージョン番号の末尾にサフィックスを追加することはできないということです。

「2.4.0.final」より後と見なされる「リリース候補」を除いて機能する「2.4.0.alpha1」、「2.4.0.beta1」、「2.4.0.final」を試すことができます」.

私が検討した代替案は、RPMバージョン番号の「Epoch：」セクションを使用することです（Epoch：プレフィックスはメインバージョン番号の前に考慮されるため、「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上のシステムは、rpmが古いバージョンと見なしているため、2.4.0に「アップグレード」できません。この場合、yum/zypper/etcは2.4.0へのアップグレードを拒否するため、私の問題です。

これを実現するためにどのバージョン番号を使用できますか。また、RPMが常にバージョン番号が正しいと見なすようにしてください。または、バージョン番号でない場合、RPMパッケージの他のメカニズムは？

注1：仕様ファイルの「Release：」フィールドを本来の目的（同じバージョンのパッケージソフトウェアについて、パッケージの変更を含む、パッケージのいくつかのリリース）のために保持したいと思います。

注2：これは、RHEL/CentOS 6やSLES 11などの主要なディストリビューションの現在の製品バージョンで動作するはずです。しかし、rpmの再コンパイルを含まない限り、動作しないソリューションにも興味があります！

注3：Debianのようなシステムでは、dpkgはバージョン番号に「〜」（チルド）文字である特別なコンポーネントを使用します。これにより、dpkgはサフィックスを「負の」順序としてカウントするため、「2.4.0〜anything」は「2.4.0」より前になります。次に、「〜」の後に通常の順序付けが適用されます。したがって、「alpha」は「beta」の前にあるため、「2.4.0〜alpha1」は「2.4.0〜beta1」の前に来ます。私は必ずしもRPMパッケージに同じスキームを使用するつもりはありません（そのような同等のものは存在しないと確信しています）。これは単なる参考です。

package-managementrpmpackaging
10
Jonathan Clarke

公式rpmガイドライン は、これを行う方法を示し、 サンプルページ へのリンクを示します。これは、3つのレベルのプレリリース（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、2番目のリリース（1.0.0b2のパッケージ化Tweak）-> 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
4
stochastic

Fedoraには プレリリースパッケージのバージョン/リリース番号を設定するためのガイドライン のセットがあります。基本的には、Versionでの最終リリースとなるバージョン番号を使用し、Release番号を0.で開始し、その後、alpha 、betaなど。最終リリースでは、英数字タグfinalをまったく使用しません。

RPMがDebianスタイルのチルダバージョン管理をサポートしているとは限りません。いくつかのディストリビューションはこの機能を無効にしています。

6
Michael Hampton

私はアルファ/ベータの区別のファンではありません。リリースされたコードとリリースされていないコードがあります。

方法：継続的インテグレーションシステムを備えたmajor.minor.buildが好きです（JenkinsCIを参照）。ビルド整数はリセットされません。マイナーバージョン番号の変更は、下位互換性のための変更です。大きな数字の変更は大きな問題です。

マーケティングで「ビルド」を大きな整数にしたくない場合は、リリースされたビルドでのみマーケティング用にマイナー番号を1度増やしてから、エンジニアリングに移行するときにもう一度増やすことができます。

2
Will

私は同様の問題にぶつかり、RedHat、Debian、PythonパッケージとRuby gemsのスイート番号を統一するためにgemsのリビジョンを比較する必要がありました。これは私を助けましたそれぞれの場合に「より大きい」と「より小さい」を評価するには：

これは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
0
nicocesar

バージョン4.10.0以降、RPMは質問で言及されているdpkgスタイルのチルド番号付けを正式にサポートしています。

https://rpm.org/wiki/Releases/4.10.

0
Michael Snook