Problemas comuns do Rpmlint

Esta é uma coleção de informações sobre como lidar com rpmlint. Observe que a primeira coisa que você deve fazer é usar a opção -e do rpmlint para fornecer texto explicativo adicional. Por exemplo:

rpmlint -e description-line-too-long

description-line-too-long:
Your description lines must not exceed 80 characters. If a line is exceeding
this number, cut it to fit in two lines.

As informações aqui fornecidas não são exaustivas. Abrange alguns cenários para os quais são conhecidas soluções rápidas. Também não é uma solução para todos os cenários e deve ser cuidadosamente considerada no contexto da construção do seu RPM. Alguns avisos do rpmlint não devem ser corrigidos para alguns pacotes, por exemplo, avisos sobre grupos ou usuários não padrão, ou sobre executáveis setuid podem ser perfeitamente adequados para alguns pacotes. Você pode ver descrições de vários problemas do rpmlint nos arquivos instalados pelo pacote rpmlint em /usr/lib/python3.12/site-packages/rpmlint/descriptions/.

Para obter mais informações sobre o projeto rpmlint, consulte o projeto Rpmlint no GitHub.

debuginfo-without-sources

rpmlint -e debuginfo-without-sources fornece uma boa visão geral. Consulte também Sinalizadores do compilador. Para corrigir, certifique-se de que os símbolos de depuração sejam criados e que não sejam removidos para que estejam disponíveis para pós-processamento do rpmbuild.

file-not-utf8

Indica que a codificação de texto do arquivo especificado, geralmente um arquivo de documentação, não está em UTF8.

  • Geralmente corrigido executando iconv no arquivo descompactado antes da instalação. Consulte a página man ICONV(1). Por exemplo, para recodificar um arquivo chamado AUTHORS codificado em latin-1, você pode usar:

iconv -f iso8859-1 -t utf-8 AUTHORS > AUTHORS.conv && mv -f AUTHORS.conv AUTHORS

ou verifique o exemplo na página de dicas de empacotamento de Perl e na página de truques genéricos.

hardcoded-library-path

  • Não codifique o caminho no SPEC. Use macros em vez disso.

incorrect-fsf-address

  • Em todos os casos, o upstream deve ser informado sobre isso. Este é o único requisito em relação a este erro.

O arquivo de licença, geralmente COPYING, não deve ser corrigido por motivos legais. Outros arquivos podem ser corrigidos se forem considerados adequados.

incoherent-version-in-changelog

invalid-license

O valor da tag License não foi reconhecido.

invalid-soname

O tratamento deste erro depende do caminho de carregamento do ld.so (o "caminho do vinculador" ou linker) e se ele se refere a uma biblioteca privada ou pública.

O caminho do vinculador é %{_libdir} somado a qualquer caminho listado em /etc/ld.so.conf ou em um arquivo em /etc/ld.so.conf.d.

Bibliotecas públicas são bibliotecas que devem ser usadas por outros pacotes. Outras bibliotecas, por exemplo, plug-ins e funcionalidades internas do pacote, são privadas.

Temos quatro casos:

  • A biblioteca é pública. Informe o upstream sobre o problema e proponha que eles adicionem ou corrijam o controle de versão, possivelmente enviando um patch. Não aplique o patch até que ele seja mesclado no upstream para evitar problemas de atualização.

  • A biblioteca é armazenada fora do caminho do vinculador. Neste caso o erro pode ser ignorado.

  • A biblioteca é privada e armazenada em um diretório incluído no caminho do vinculador. Se possível, mova a biblioteca para outro diretório fora do caminho do vinculador. Isso pode exigir a correção de scripts de construção.

  • A biblioteca é privada, armazenada em um diretório incluído no caminho do vinculador e não pode ser movida. Aqui, a biblioteca deve ter um nome que provavelmente não colida com outras bibliotecas. Considere filtrar o Provides: para garantir que a biblioteca privada não esteja visível.

A maneira padrão de mover uma biblioteca privada é criar um novo diretório em %{_libdir}, por exemplo, /usr/lib/myapp. Não liste-o nos arquivos /etc/ld.so.conf! Em vez disso, use um rpath para permitir que o aplicativo localize a biblioteca.

Veja também:

no-binary

O pacote deve ser da arquitetura noarch porque não contém nenhum binário.

  • Adicione BuildArch: noarch ao arquivo SPEC

no-documentation

Indica que o rpmlint não encontrou nenhum arquivo marcado como %doc. Existem vários casos em que isso é aceitável:

  • O pacote realmente não possui documentação. Isso é raro e, em geral, uma péssima ideia; todo pacote deve ter algum tipo de documentação e pelo menos o texto de sua licença. No entanto, alguns pacotes possuem sistemas de ajuda internos.

  • Toda a documentação foi incluída em um subpacote -doc. Isto seria raro, pois a maioria dos pacotes deveria ter algum texto de licença, um changelog ou outra informação que seja melhor colocada no pacote principal em vez de um subpacote -doc.

  • Este é um subpacote e a documentação relevante foi incluída no pacote principal. Isso geralmente acontece com o subpacote -devel, mas você deve pelo menos verificar novamente para garantir que qualquer documentação do pacote destinada a desenvolvedores esteja incluída no subpacote -devel.

no-soname

Indica que a biblioteca compartilhada especificada não possui um soname (campo DT_SONAME ELF). Se um executável estiver vinculado a um objeto compartilhado que possui um campo DT_SONAME, quando o executável for executado, o vinculador dinâmico tentará carregar o objeto compartilhado especificado pelo campo DT_SONAME em vez de usar o nome de arquivo fornecido ao vinculador. Consulte a página man LD(1).

Veja também:

private-shared-object-provides

W: python-dulwich.x86_64: W: private-shared-object-provides /usr/lib64/python2.6/site-packages/dulwich/_objects.so _objects.so()(64bit)

script-without-shebang

  • Você se esqueceu de remover bits executáveis em arquivos relatados por este erro. Veja também: Add shebang.

spurious-executable-perm

Indica que um arquivo tem o bit executável definido, mas provavelmente não deveria.

  • Remova a definição do bit executável, por exemplo chmod -x README.md na seção %install do seu arquivo de especificações.

standard-dir-owned-by-package

Este pacote possui um diretório que faz parte da hierarquia padrão, o que pode levar à alteração de permissões de diretório padrão ou propriedades para algo fora do padrão.

  • Você não deve fazer com que os diretórios padrão do sistema pertençam ao seu pacote.

unstripped-binary-or-object

  • Certifique-se de que os binários sejam executáveis.

unused-direct-shlib-dependency

Um binário está vinculado a uma biblioteca, mas na verdade não chama nenhuma das funções contidas nela. Isso geralmente acontece ao vincular uma biblioteca que usa pkgconfig; o arquivo pkgconfig não pode saber quais funções específicas seu binário pode precisar chamar, então ele diz para você vincular todas as possibilidades.

Uma correção para pacotes que usam libtool é colocar isto na sua seção %build após a chamada %configure:

sed -i -e 's! -shared ! -Wl,--as-needed\0!g' libtool

Outra correção para pacotes que usam %cmake é colocar isso antes da chamada %cmake:

export CXXFLAGS="%{optflags} -Wl,--as-needed"

wrong-file-end-of-line-encoding

O arquivo possui codificação de fim de linha incorreta, geralmente causada pela criação ou modificação em um sistema não Unix. Isso pode impedir que o arquivo seja exibido corretamente em determinadas circunstâncias. UNIX e Linux usam o caractere Line-Feed, enquanto o Windows e o DOS usam Carriage Return e Line Feed.

  • Remova os Carriage Returns usando perl ou sed, usar dos2unix não é necessário. Consulte a página de manual SED(1)

perl -i -pe 's/\r\n/\n/gs'
sed -i 's/\r$//'

Want to help? Learn how to contribute to Fedora Docs ›