xyz> xyz-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.alpha1」、「2.4.0.beta1」、「2.4.0.final」は試してみることができますが、「2.4.0.final」より後と見なされる「リリース候補」を除いて機能します。 」 私が検討した代替案は、RPMバージョン番号の「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パッケージに同じスキームを使用するつもりはありません（そのような同等のものは存在しないと確信しています）。これは単なる参考です。