rpm spec file skeleton to real spec file

Question

Цель состоит в том, чтобы иметь скелет spec fun.spec.skel файл, который содержит заполнители для Version, Release и тому подобное.

Для простоты я пытаюсь создать цель сборки, которая обновляет эти переменные таким образом, что я преобразовываю fun.spec.skel в fun.spec, который затем могу выполнить в своем репозитории github. Это делается так, что rpmbuild -ta fun.tar действительно работает хорошо, и никаких ручных модификаций fun.spec.skel не требуется (люди, как правило, забывают опустить версию в spec-файле, но не в buildsystem).

Answer 1

Предполагая, что подразумеваемый вопрос: «Как бы это сделать?», Общий ответ заключается в том, чтобы помещать заполнители в файл, например @@VERSION@@, а затем sed файл, или усложнить его, и сделать это с помощью autotools.

Answer 2

Я нашел два способа:

а) использовать что-то вроде

Version: %(./waf version) 

где version является пользовательскихwaf целевой

def version_fun(ctx): 
    print(VERSION) 


class version(Context): 
    """Printout the version and only the version""" 
    cmd = 'version' 
    fun = 'version_fun' 

это проверяет версию на оборотов в минуту время сборки

---

б) создать цель, которая модифицирует сам файл спецификацию

from waflib.Context import Context 
import re 
def bumprpmver_fun(ctx): 

    spec = ctx.path.find_node('oregano.spec') 
    data = None 
    with open(spec.abspath()) as f: 
     data = f.read() 

    if data: 
     data = (re.sub(r'^(\s*Version\s*:\s*)[\w.]+\s*', r'\1 {0}\n'.format(VERSION), data, flags=re.MULTILINE)) 

     with open(spec.abspath(),'w') as f: 
      f.write(data) 
    else: 
     logs.warn("Didn't find that spec file: '{0}'".format(spec.abspath())) 


class bumprpmver(Context): 
    """Bump version""" 
    cmd = 'bumprpmver' 
    fun = 'bumprpmver_fun' 

Последний используются в моем любимом проекте oregano @ github

Answer 3

мы помещаем файл version.mk в наших каталогах проекта, которые определяют переменные окружения. Пример содержание включает в себя:

RELPKG=foopackage 
RELFULLVERS=1.0.0 

В рамках сценария, который строит RPM, мы можем на этот файл:

#!/bin/bash 
. $(pwd)/Version.mk 
export RELPKG RELFULLVERS 

if [ -z "${RELPKG}" ]; then exit 1; fi 
if [ -z "${RELFULLVERS}" ]; then exit 1; fi 

Это оставляет нам несколько вариантов, чтобы получить доступ к значениям, которые были установлены:

• Мы можем определить макросы в командной строке rpmbuild:

  % rpmbuild -ba --define "relpkg $ {RELPKG}" --define "relfullvers $ {RELFULLVERS}" foopackage.spec

• Мы можем получить доступ к переменным окружения, используя% {getenv: ...} в самом файле spec (хотя это может быть сложнее справиться с ошибками ...):

  % определяют relpkg% {GETENV: RELPKG} % определить relfullvers% {GetEnv: RELFULLVERS}

здесь, вы просто использовать макросы в файле спецификации:

Name: %{relpkg} 
Version: %{relfullvers} 

У нас есть аналогичные значения (предоставляемые переменными среды, включенными через Jenkins), которые предоставляют номер сборки, который подключается к тегу «Release».