specfile RPM para projeto C / C ++: como eu sei como preencher os campos Requires e BuildRequires?

1

Eu tenho vários projetos C / C ++ com fontes e makefiles e estou tentando empacotá-los em rpms. Definir as dependências para os pacotes criados se tornou um problema para mim. Concretamente, eu preciso descobrir o que colocar nos campos Requer e BuildRequires do specfile.

  1. Supondo que o campo Requer solicita a lista de bibliotecas usadas pelo executável durante o tempo de execução, estou tentando analisar a saída de ldd e passá-la ao rpm -q --whatrequires ( aqui está meu script simples ). Além disso, eu preciso fazer isso de forma recursiva (obter dependências para os pacotes que contêm dependências de primeiro nível) de alguma forma.

  2. Eu posso imaginar que o campo BuildRequires deve conter todos os pacotes * -devel.rpm com cabeçalhos С / С ++ ( apenas? ). Posso verificar vários arquivos de origem manualmente, mas não entendo como analisar as milhares linhas de código ...

A análise de fontes pela palavra-chave #include pode levar à colisão (devido a cabeçalhos com o mesmo nome, mas em diretórios diferentes). É possível forçar o Make script ou o gcc a serem mais detalhados para definir quais cabeçalhos foram usados por padrão? Isso resolveria o segundo problema.

A falta de uma ferramenta tão útil para os desenvolvedores em distros baseadas no RHEL parece estranha para mim.

    
por Vitaly Isaev 30.01.2014 / 19:17

2 respostas

3

As ferramentas RPM do Fedora são bastante inteligentes em descobrir as dependências de tempo de execução por conta própria, a menos que não possam ser deduzidas dos próprios arquivos instaláveis. As dependências para a construção você descobrirá por si mesmo. Talvez o guia RPM do Fedora seja útil (eu sou usuário do Fedora, e isso é o melhor recurso que conheço; talvez sua distribuição tenha mais documentação relevante para seu uso). O Fedora oferece mock(1) , o que cria um ambiente limpo apenas com as ferramentas construídas mencionadas para construir o pacote. É uma dor real ( muito lenta, pois essencialmente cria um sistema completo em um chroot baixando tudo para cada compilação), mas uma verificação final útil.

    
por 30.01.2014 / 20:15
1

Portanto, é assim que obtenho informações para fornecer dependências explícitas para o arquivo de especificação:

por 19.03.2014 / 18:18