2009-04-03 4 views
0

Я только начал работать в первый раз с продуктом, который поставляется через механизм RPM Linux, а не как автономный установщик, и понял, что это делает цикл тестирования/выпуска немного сложнее.Выполнение цикла выпуска с продуктом, который поставляется через RPM

Когда я работал с установщиками, мы просто изменили нумерацию сборки в нашей системе сборки, чтобы пометить сборку как кандидат на тест или выпуск, вместо моментального снимка разработки, и попросить людей установить только сборку кандидатов для тестирования. Проблема с выполнением RPM заключается в том, что если мы изменим систему нумерации, мы сломаем механизм доставки, и установленные машины больше не смогут определить, какая из них является последней версией RPM.

Лучший способ, с помощью которого я решил обойти это, - разместить RPM-кандидатов в полностью отдельном репозитории RPM, но это также усложняется, потому что у нас есть несколько RPM, поступающих из одного и того же репозитория, которые находятся в разных циклах выпуска , поэтому мы будем пытаться вытащить версию кандидата RPM A из нового репозитория, все еще желая получить моментальные копии разработки RPM B из хранилища разработки.

Это должно быть довольно распространенная проблема для программного обеспечения Linux, так может ли кто-нибудь сказать мне лучшую практику? Заранее спасибо .....

ответ

3

Общей методологией в мире Linux является широковещательная конвенция о выпуске номера, которая указывает, является ли сборка разработкой или выпуском. Для самого ядра Linux выпуски нечетных точек (2.5, 2.7) - это разработка, а даже (2.4, 2.6) - выпуски.

Быстрое сканирование RPM guide, по-видимому, указывает на то, что использование такой схемы может быть лучшим выбором.

+0

Ну, следует отметить, что ядро ​​использовало эту схему управления версиями. Это уже не так. – supercheetah