Por que “dir-or-file-in-usr-local” é um erro em vez de um aviso?

Question

Estou construindo alguns pacotes rpm e verificando padrões e conformidade de estilo usando rpmlint . Os pacotes são específicos para sistemas no meu local de trabalho e não serão enviados para o upstream. Nossos pacotes incluem uma variedade de softwares, incluindo software interno, versões de software dos repositórios e software não disponível nos repositórios oficiais. Instalamos pacotes locais em /usr/local por vários motivos:

• evita conflitos de nomenclatura com pacotes oficiais
• impede que yum update seja danificado em pacotes locais
• permite que os pacotes locais vivam em partições ou discos separados e / ou sejam compartilhados pelo NFS, para que os pacotes e as configurações possam ser compartilhados entre os hosts
• nos permite ter maior controle sobre pacotes que são instalados de fontes externas ao repositório oficial, muitos dos quais não estão em conformidade com os caminhos de instalação padrão ( bin , lib , include , share , etc .)

No entanto, rpmlint fica muito reclamado quando executado em um pacote que instala arquivos em /usr/local . Por exemplo, em uma versão personalizada do GNU Hello World, isso é o que o rpmlint -i tem a dizer:

hello.x86_64: E: dir-or-file-in-usr-local /usr/local/hello-2.8/bin/hello
A file in the package is located in /usr/local. It's not permitted for
packages to install files in this directory.

Conheço o padrão de hierarquia do sistema de arquivos , de acordo com o qual:

The original idea behind '/usr/local' was to have a separate ('local') '/usr' directory on every machine besides '/usr', which might be just mounted read-only from somewhere else. It copies the structure of '/usr'. These days, '/usr/local' is widely regarded as a good place in which to keep self-compiled or third-party programs. The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr. Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr.

Estamos, de fato, seguindo esses padrões e instalando nosso software local em /usr/local apenas por esses motivos, então não vejo por que deveria haver algo errado em usar um gerenciador de pacotes para instalar pacotes em /usr/local . No entanto, eu também gostaria que nossos pacotes fossem compatíveis com os padrões, se não fosse por outra razão que a consistência entre nossos pacotes locais. Então, por que rpmlint envia um erro para arquivos em /usr/local ? Não deveria estar na descrição do empacotador? Posso ignorar esse erro ou pelo menos fazer rpmlint imprimir um aviso?

    

Answer 1

rpmlint é uma ferramenta para verificar os RPMs em relação a algum tipo de política de empacotamento. Sua configuração é tipicamente dependente da distribuição e verifica os pacotes em relação à política de distribuição específica. Verificar seus próprios pacotes é bom, desde que isso seja o que você deseja.

Se sua política for diferente da política de distribuição, você deverá configurar rpmlint de acordo, abster-se de usá-la ou ignorar os erros específicos.

O seguinte deve fazer o truque quando adicionado a /etc/rpmlint/config ou ~/.config/rpmlint (não testado):

addFilter("E: dir-or-file-in-usr-local")

Fontes:

• link

Answer 2

Você não está seguindo o padrão. /usr/local foi projetado para conter arquivos compilados localmente, ou seja, arquivos criados na máquina local.

Quando você cria um pacote, o objetivo é distribuí-lo para outras máquinas.

Se você instalar o pacote em uma máquina e, em seguida, criar o mesmo software a partir da origem na mesma máquina, os arquivos de pacote serão sobrescritos se ambos os destinos forem /usr/local . Este é o conflito que o rpmlint está tentando evitar.

No seu caso, sugiro criar um pacote que instale os arquivos em /opt/hello2.8 . O último diretório não entraria em conflito nem com um pacote upstream nem com arquivos construídos localmente.