Aby opublikować pakiety RPM kilku różnych wersji niektórych programów, szukam sposobu na określenie „numerów” wersji, które są uważane za „aktualizacje”, i uwzględnienie różnicowania kilku wersji przedpremierowych, takich jak (w kolejności ): „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”, „kandydat do wydania 2.4.0”, „2.4.0 wersja ostateczna”, „2.4.1”, „2.4.2” itd.
Głównym problemem, jaki mam z tym, jest to, że RPM uważa, że „2.4.0” jest wcześniejszy niż „2.4.0.alpha1”, więc nie mogę po prostu dodać sufiksu na końcu ostatecznego numeru wersji.
Mógłbym wypróbować „2.4.0.alpha1”, „2.4.0.beta1”, „2.4.0.final”, które działałyby, z wyjątkiem „kandydata do wydania”, który byłby rozważany później niż „2.4.0.final „.
Alternatywą, którą rozważałem, jest użycie sekcji „epoka:” numeru wersji RPM (przedrostek epoki: rozważany jest przed głównym numerem wersji, tak że „1: 2.4.0” jest faktycznie wcześniejszy niż „2: 1.0.0”) . Umieszczając znacznik czasu w polu epoka:, wszystkie wersje są porządkowane zgodnie z oczekiwaniami RPM, ponieważ ich wersje wydają się rosnąć w czasie. Nie powiedzie się to jednak, gdy zostaną wydane nowe wersje dla kilku głównych wersji jednocześnie (na przykład 2.3.2 jest wydana po wersji 2.4.0, ale ich wersja dla RPM to „20121003: 2.3.2” i „20120928: 2.4. 0 ”i systemy w wersji 2.3.2 nie mogą zostać„ zaktualizowane ”do wersji 2.4.0, ponieważ rpm widzi to jako starszą wersję). W tym przypadku yum / zypper / etc odmawia aktualizacji do wersji 2.4.0, więc mój problem.
Jakich numerów wersji mogę użyć, aby to osiągnąć, i upewnij się, że RPM zawsze uważa, że numery wersji są w porządku. A jeśli nie numery wersji, inny mechanizm w pakiecie RPM?
Uwaga 1: Chciałbym zachować pole „Wydanie:” pliku specyfikacji do jego pierwotnego celu (kilka wydań pakietów, w tym zmiany w pakiecie, dla tej samej wersji pakietu).
Uwaga 2: Powinno to działać w bieżących wersjach głównych dystrybucji, takich jak RHEL / CentOS 6 i SLES 11. Ale interesują mnie rozwiązania, które również nie, o ile nie wymagają ponownej kompilacji rpm!
Uwaga 3: W systemach podobnych do Debiana dpkg używa specjalnego komponentu w numerze wersji, który jest znakiem „~” (tylda). Powoduje to, że dpkg liczy przyrostek jako „ujemny” porządek, tak że „2.4.0 ~ cokolwiek” pojawi się przed „2.4.0”. Następnie po „~” obowiązuje normalne uporządkowanie, więc „2.4.0 ~ alpha1” występuje przed „2.4.0 ~ beta1”, ponieważ „alfa” występuje przed „beta” alfabetycznie. Niekoniecznie chcę używać tego samego schematu dla pakietów RPM (jestem prawie pewien, że nie ma takiego odpowiednika), więc to tylko informacja FYI.