Quando usar arch vs noarch ao construir RPMs?

3

Prefácio

Ao construir RPMs, não quero dizer compilar a partir do código-fonte. Significo puramente pegar um arquivo tar ou 'zip' com código-fonte ou binários e reempacotá-lo como um RPM.

Estou criando RPMs do código-fonte há algum tempo como noarch RPMs. Recentemente eu tive que construir RPMs que contêm binários, o que levantou algumas preocupações:

  1. Existe uma prática recomendada na determinação de facters entre arch e noarch RPMs? Especialmente no caso de criar o RPM a partir de arquivos binários. Eu entendo que para o código-fonte puro onde não há compilação e apenas a extração de arquivos na instalação do RPM, noarch é aceitável, como mencionado acima, eu tenho algumas dúvidas quando se trata de pacotes binários.
  2. São arch RPMs compatíveis com diferentes versões do sistema operacional? (Isso está no contexto do prefácio acima) Apenas para elaborar posso construir um arch RPM no RedHat 6 e instalá-lo no RedHat 5 e vice-versa?
por kaizenCoder 21.05.2015 / 13:31

1 resposta

6

Na prática, não importa se você o constrói a partir do código-fonte ou empacota algum arquivo pré-existente.

noarch RPMs devem ser neutros em arquitetura, ou seja, eles não devem conter binários (nativos). Se o pacote é composto por scripts interpretados (Bash, Python, etc.), documentação, cabeçalhos, arquivos de mídia, etc., até mesmo classes Java compiladas, então ele pode ser noarch . O mesmo pacote funcionará em qualquer arquitetura de hardware, pois não contém código criado especificamente para uma determinada arquitetura.

Por outro lado, se o pacote contiver binários compilados para código de máquina nativo (por exemplo, programas escritos em C, C ++, Pascal, etc.), não importa o que eles contenham, eles devem estar ligados a uma arquitetura. Um programa compilado para x86_64 não pode ser executado em um sistema operacional host ppc , por exemplo.

Quanto a ser compatível com diferentes versões do sistema operacional, elas variam de acordo com as dependências e não podem ser generalizadas facilmente. Por exemplo, se um pacote depende de uma versão mínima de uma determinada biblioteca, obviamente não será garantido que ele funcione em sistemas com versões mais antigas dessa biblioteca (ou sistemas que não possuem essa biblioteca). Se não tiver dependências ou muito genéricas, é provável que funcione.
Além disso, estritamente falando, isso se aplica aos pacotes arch e noarch .

    
por 22.05.2015 / 05:57