Makepkg (Português)

Cada pacote é marcado com metadados identificando, entre outros, também o empacotador. Por padrão, os pacotes compilados pelo usuário são marcados com . Se vários usuários estiverem compilando pacotes em um sistema, ou de outra forma distribuindo seus pacotes para outros usuários, é conveniente fornecer contato real. Isso pode ser feito configurando a variável PACKAGER em .

Para verificar isso em um pacote instalado:

Para automaticamente produzir pacotes assinados, defina também a variável em .

Por padrão, makepkg cria os tarballs de pacote no diretório atual de trabalho e baixa os dados fonte diretamente para o diretório . Caminhos personalizados podem ser configurados, por exemplo, para manter todos os pacotes compilados em ~/build/pacotes/ e todos os fontes em .

Configure as seguintes variáveis do , se necessário:

• – diretório para armazenar pacotes resultantes
• – diretório para armazenar dados fonte (links simbólicos serão colocados em se ele aponta para outro lugar)
• – diretório para armazenar os pacotes fontes (compilado com makepkg -S)

Se um arquivo de assinatura na forma de .sig ou .asc é parte do vetor fonte do PKGBUILD, o makepkg tenta automaticamente verificá-la. No caso do chaveiro do usuário não contém a chave pública necessária para verificação de assinatura, o makepkg vai abortar a instalação com uma mensagem de que a chave PGP não pôde ser verificada.

Se uma chave pública necessária para um pacote está faltando, o PKGBUILD muito provavelmente vai conter uma entrada validpgpkeys com os IDs de chaves necessárias. Você pode importá-la manualmente ou você pode localizá-la em um servidor de chaves e importá-la de lá.

Faça uso de , especialmente ao compilar pacotes VCS, para economizar tempo ao adquirir e desempacotar fontes em recompilações subsequentes.

Uma melhoria de desempenho do software empacotado pode ser conseguida ao habilitar otimizações do compilador para a máquina host. A desvantagem é que os binários compilados para uma arquitetura de processador específica não serão executados corretamente em outras máquinas. Nas máquinas x86_64, raramente existem ganhos de desempenho reais significativos que justificariam investir o tempo para reconstruir pacotes oficiais.

No entanto, é muito fácil reduzir o desempenho usando flags de compilação "não padronizadas". Muitas otimizações de compilação só são úteis em certas situações e não devem ser aplicadas indiscriminadamente em cada pacote. A menos que você possa verificar/avaliar que algo é mais rápido, há uma chance muito boa de não ser! Os artigos wiki otimização do GCC e CFLAGS seguras do Gentoo (ambos em inglês) fornecem mais informações detalhadas sobre a otimização do compilador.

As opções passadas para um compilador C/C++ (ex.: ou clang) são controladas pelas variáveis de ambiente , e. Para usar o sistema de compilação do Arch, o makepkg expõe essas variáveis de ambiente como opções de configuração no . Os valores padrão são configurados para produzir binários genéricos que podem ser instalados em uma ampla gama de máquinas.

O GCC pode detectar e habilitar automaticamente otimizações seguras específicas para cada arquitetura. Para usar esse recurso, primeiro remova os sinalizadores e -mtune, então adicione . Por exemplo:

Para ver quais sinalizadores isso habilita em sua máquina, execute:

$ gcc -march=native -v -Q --help=target

A partir do pacman versão 5.2.2, também inclui substituições para a variável de ambiente , para sinalizadores fornecidos ao compilador Rust. O compilador Rust também pode detectar e habilitar otimizações específicas de arquitetura para sua CPU, adicionando ao valor fornecido:

Para ver quais recursos de CPU isso vai habilitar, execute:

$ rustc -C target-cpu=native --print cfg

Executar sem irá imprimir a configuração padrão. O parâmetro pode ser alterado para , ou z conforme desejado. Consulte a documentação do compilador Rust para obter detalhes.

O sistema de compilação do usa a variável de ambiente para especificar opções adicionais para o make. A variável também pode ser definida no arquivo .

Os usuários com sistemas multi-core/multiprocessados podem especificar o número de trabalhos a serem executados simultaneamente. Isso pode ser realizado com o uso de nproc para determinar o número de processadores disponíveis, ex. . Alguns PKGBUILD substituem especificamente isso com , devido a condições de corrida em certas versões ou simplesmente porque não é suportado em primeiro lugar. Os pacotes que não conseguem ser compilados devido a isso devem ser relatados no rastreador de erros (ou no caso dos pacotes do AUR, ao mantenedor do pacote) depois de ter certeza de que o erro está sendo realmente causado pelo seu .

Veja para uma lista completa de opções disponíveis.

Como a compilação requer muitas operações de E/S e lidar com arquivos pequenos, mover o diretório de trabalhos para um tmpfs pode trazer melhorias em tempos de compilação.

A variável BUILDDIR pode ser temporariamente exportada para makepkg para definir o diretório de compilação para um tmpfs existente. Por exemplo:

$ BUILDDIR=/tmp/makepkg makepkg

Uma configuração persistente pode ser feita no descomentando a opção BUILDDIR, que é encontrada no fim da seção no arquivo padrão . Definir esses valores para, por exemplo, fará uso do sistema de arquivos temporário padrão do Arch.

O uso de ccache pode melhorar os tempos de compilação ao armazenar em cache os resultados de compilações para uso sucessivo.

Instale e execute o seguinte comando no mesmo diretório que o arquivo PKGBUILD para gerar novas somas de verificação (checksums):

$ updpkgsums

usa  para gerar as somas de verificação. Veja esta discussão de fórum para obter mais detalhes.

As somas de verificação também podem ser obtidos com, por exemplo, e adicionados ao vetor manualmente.

Para acelerar o empacotamento e a instalação, com a consequência de ter arquivos de pacotes maiores, você pode alterar PKGEXT.

Por exemplo, o seguinte pula a compressão do arquivo de pacote, o qual vai, por sua vez, não ter a necessidade de descompressão na instalação:

$ PKGEXT='.pkg.tar' makepkg

Um outro exemplo abaixo mostra o uso do algoritmo lzop, com o pacote necessário:

$ PKGEXT='.pkg.tar.lzo' makepkg

Para fazer uma dessas configurações permanentes, configure PKGEXT em .

O oferece suporte a multiprocessamento simétrico (SMP) por meio do sinalizador para acelerar a compressão. Por exemplo, para deixar o makepkg usar quantos núcleos de CPU for possível para comprimir os pacotes, edite o vetor em :

COMPRESSXZ=(xz -c -z - --threads=0)

O é uma implementação paralela para o que, por padrão, usa todos os núcleos disponíveis na CPU (o sinalizador pode ser usado para empregar menos núcleos):

COMPRESSGZ=(pigz -c -f -n)

é um drop-in, implementação paralela para bzip2 que também usa todos os núcleos de CPU disponíveis por padrão. A opção  pode ser usado para empregar menos núcleos (note: nenhum espaço entre o  e número de núcleos).

COMPRESSBZ2 =(pbzip2 -c -f)

possui suporte a multiprocessamento simétrico (SMP) por meio do sinalizador  para acelerar compressão. Por exemplo, para deixar o makepkg usar o máximo possível de núcleos de CPU para comprimir pacotes, edite o vetor COMPRESSZST em :

COMPRESSZST=(zstd -c -z -q - --threads=0)

é um utilitário de extração de base de dados do pacman. Este comando mostra todos os pacotes instalados no sistema com o empacotador chamado nome-empacotador:

$ expac "%n %p" | grep "nome-empacotador" | column -t

Isso mostra todos os pacotes instalados no sistema com o empacotador definido na variável PACKAGER do . Isso mostra apenas pacotes que estão em um repositório definido em .

$ . /etc/makepkg.conf; grep -xvFf <(pacman -Qqm) <(expac "%n\t%p" | grep "$PACKAGER$" | cut -f1)

Primeiro, habilite o repositório multilib e instale .

Então, crie um arquivo de configuração 32 bits

e chame o makepkg assim

$ linux32 makepkg --config ~/.makepkg.i686.conf

O makefile gerado pelo qmake usa a variável de ambiente INSTALL_ROOT para especificar onde o programa deve ser instalado. Então, essa função package deve funcionar:

Note que o qmake também tem que ser configurado adequadamente. Por exemplo, coloque isso em seu arquivo .pro:

De alguma forma, as strings literais contidas nas variáveis ou acabaram em um dos arquivos instalados no seu pacote.

Para identificar quais arquivos, execute o seguinte do diretório de compilação makepkg:

$ grep -R "$PWD/src" pkg/

Uma causa possível seria pelo uso da macro __FILE__ no código C/C++ com caminho completo passado para o compilador.

Quando o makepkg chama dependências, ele chama o pacman para instalar os pacotes, o que requer privilégios administrativos via sudo. No entanto, o sudo não passa nenhuma variável de ambiente para o ambiente privilegiado, e inclui as variáveis relacionadas ao proxy , , e .

Para que ter o makepkg funcionando por trás de um proxy, você tem que fazer um dos seguintes métodos.

O XferCommand pode ser definido para usar a URL de proxy desejada no . Adicione ou descomente a linha a seguir em seu :

Alternativamente, pode-se usar a opção do sudoers, a qual permite preservar as variáveis de ambiente dadas no ambiente privilegiado. Veja sudo#Variáveis de ambiente para mais informações.

Se algo compilar manualmente usando make, mas falhar através do makepkg, é quase certo que seja porque o define uma variável de compilação para algo razoável que normalmente funcione, mas que seja incompatível com o que você esteja compilando. Tente adicionar esses sinalizadores ao array options do PKGBUILD:

, para evitar seu , , e padrão.

, para evitar seu padrão, caso você tenha editado para habilitar compilações paralelas.

, para evitar seu e padrão, no caso de seu pacote ser uma compilação de depuração.

Se qualquer um deles resolver o problema, isso pode indicar que você pode relatar um erro no envio de dados, se você isolar exatamente qual sinalizador está causando o problema.