Makepkg (Português)
makepkg é um script usado para automatizar a compilação de pacotes. Os requisitos para usar o script são uma plataforma tipo Unix capaz de compilar e um PKGBUILD.
O makepkg é fornecido pelo pacote pacman.
Configuração
Veja makepkg.conf(5) para detalhes sobre as opções de configuração do makepkg.
A configuração do sistema está disponível em /etc/makepkg.conf, mas alterações específicas para cada usu[ario podem ser feitas em $XDG_CONFIG_HOME/pacman/makepkg.conf ou ~/.makepkg.conf. É recomendado revisar a configuração antes de compilar pacotes.
Informação do empacotador
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 Empacotador desconhecido. 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 makepkg.conf.
Para verificar isso em um pacote instalado:
$ pacman -Qi pacote
... Empacotador : John Doe <[email protected]> ...
Para automaticamente produzir pacotes assinados, defina também a variável GPGKEY em makepkg.conf.
Saída de pacote
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 src/. Caminhos personalizados podem ser configurados, por exemplo, para manter todos os pacotes compilados em ~/build/pacotes/ e todos os fontes em ~/build/fontes/.
Configure as seguintes variáveis do makepkg.conf, se necessário:
-
PKGDEST– diretório para armazenar pacotes resultantes -
SRCDEST– diretório para armazenar dados fonte (links simbólicos serão colocados emsrc/se ele aponta para outro lugar) -
SRCPKGDEST– diretório para armazenar os pacotes fontes (compilado commakepkg -S)
PKGDEST pode ser limpado com, p. ex., paccache -c ~/build/pacotes/ como descrito em pacman (Português)#Limpando o cache de pacotes.Verificação de assinatura
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á.
Uso
Antes de continuar, instale o grupo base-devel. Os pacotes que pertencem a este grupo não são exigidos na lista de dependência de compilação (makedepends) nos arquivos PKGBUILD.
- Certifique-se de que o sudo está configurado corretamente para comandos passados para o pacman.
- Executar makepkg em si como root não é permitido.[2] Além disso, como um
PKGBUILDpode conter comandos arbitrários, compilar como root geralmente é considerado inseguro.[3] Usuários que não possuem acesso a uma conta de usuário comum devem executar o makepkg como o usuário nobody.
Para compilar um pacote, deve-se primeiro criar um PKGBUILD, ou um script de compilação, como descrito em Criando pacotes. Scripts existentes estão disponíveis na árvore do Arch Build System (ABS) ou do AUR. Uma vez em posse de um PKGBUILD, altere o diretório no qual está salvo e execute o seguinte comando para compilar o pacote:
$ makepkg
Se estiverem faltando dependências necessárias, o makepkg emitirá um aviso antes de falhar. Para compilar o pacote e instalar as dependências necessárias, adicione a opção -s/--syncdeps:
$ makepkg --syncdeps
Adicionar as opções -r/--rmdeps faz com que o makepkg remova as dependências de compilação logo em seguida, já que não são mais necessárias. Se estiver compilando pacotes constantemente, considere usar Pacman/Dicas e truques#Removendo pacotes não usados (órfãos) de vez em quando.
- Essas dependências devem estar disponíveis nos repositórios configurados; veja pacman (Português)#Repositórios e espelhos para detalhes. Alternativamente, pode-se instalar manualmente as dependências antes de compilar (
pacman -S --asdeps dep1 dep2). - Apenas valores globais são usados ao instalar dependências, ou seja, qualquer sobrescrita feita em uma função de empacotamento de pacotes divididos não serão sadas.
Uma vez que todas as dependências estejam satisfeitas e os pacotes compilados com sucesso, um arquivo de pacote (pkgname-pkgver.pkg.tar.zst) será criado no diretório. Para instalar, use -i/--install (o mesmo que pacman -U pkgname-pkgver.pkg.tar.zst):
# pacman --install
Para limpar arquivos e pastas restantes, tais como arquivos extraídos para $$srcdir, adicione a opção -c/--clean. Isso é útil para várias compilações do mesmo pacote ou ao atualizar a versão do pacote, enquanto usa a mesma pasta de compilação. Isso evita arquivos obsoletos e remanescentes de serem carregados para novas compilações:
$ makepkg --clean
Para mais informações, veja makepkg(8).
Dicas e truques
Reduzir tempos de download e extração de fontes
Faça uso de SRCDEST, especialmente ao compilar pacotes VCS, para economizar tempo ao adquirir e desempacotar fontes em recompilações subsequentes.
Compilando binários otimizados
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.: gcc ou clang) são controladas pelas variáveis de ambiente CFLAGS, CXXFLAGS eCPPFLAGS. 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 makepkg.conf. Os valores padrão são configurados para produzir binários genéricos que podem ser instalados em uma ampla gama de máquinas.
makepkg.conf. Por exemplo, cmake ignora a variável de ambiente das opções de pré-processador, CPPFLAGS. Consequentemente, muitos PKGBUILD contêm soluções alternativas com opções específicas para o sistema de compilação usado pelo software empacotado.
- A configuração fornecida com o código fonte no
Makefileou em um argumento específico na linha de comando de compilação tem a preferência e pode potencialmente sobrescrever aquela nomakepkg.conf.
O GCC pode detectar e habilitar automaticamente otimizações seguras específicas para cada arquitetura. Para usar esse recurso, primeiro remova os sinalizadores -march e -mtune, então adicione -march = native. Por exemplo:
/etc/makepkg.conf
CFLAGS="-march=native -O2 -pipe -fno-plt"
CXXFLAGS="${CFLAGS}"
Para ver quais sinalizadores isso habilita em sua máquina, execute:
$ gcc -march=native -v -Q --help=target
-march=native, então -Q --help=target não vai funcionar como esperado.[4] Você precisa passar por uma fase de compilação para descobrir quais opções estão realmente habilitadas. Veja Gentoo:Safe CFLAGS#Manual para instruções.A partir do pacman versão 5.2.2, makepkg.conf também inclui substituições para a variável de ambiente RUSTFLAGS, 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 -C target-cpu=native ao valor RUSTFLAGS fornecido:
/etc/makepkg.conf
RUSTFLAGS="-C opt-level=2 -C target-cpu=native"
Para ver quais recursos de CPU isso vai habilitar, execute:
$ rustc -C target-cpu=native --print cfg
Executar --print cfg sem -C target-cpu=native irá imprimir a configuração padrão. O parâmetro opt-level pode ser alterado para 3, s ou z conforme desejado. Consulte a documentação do compilador Rust para obter detalhes.
Melhorando os tempos de compilação
Compilação paralela
O sistema de compilação do make usa a variável de ambiente MAKEFLAGS para especificar opções adicionais para o make. A variável também pode ser definida no arquivo makepkg.conf.
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. MAKEFLAGS="-j$(nproc)". Alguns PKGBUILD substituem especificamente isso com -j1, 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 MAKEFLAGS.
Veja make(1) para uma lista completa de opções disponíveis.
Compilando de arquivos na memória
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 makepkg.conf descomentando a opção BUILDDIR, que é encontrada no fim da seção BUILD ENVIRONMENT no arquivo padrão /etc/makepkg.conf. Definir esses valores para, por exemplo, BUILDDIR=/tmp/makepkg fará uso do sistema de arquivos temporário /tmp padrão do Arch.
- Evite compilar pacotes grandes no tmpfs para evitar ficar sem memória.
- A pasta tmpfs deve ser montada sem a opção
noexec; do contrário, ela vai impedir que binários sejam executados. - Tenha em mente que pacotes compilados no tmpfs não persistirá após reinicialização. Considere configurar a opção PKGDEST apropriadamente para mover o pacote compilado automaticamente para um diretório persistente.
Usando cache de compilação
O uso de ccache pode melhorar os tempos de compilação ao armazenar em cache os resultados de compilações para uso sucessivo.
Gerar novos checksums
Instale pacman-contrib e execute o seguinte comando no mesmo diretório que o arquivo PKGBUILD para gerar novas somas de verificação (checksums):
$ updpkgsums
updpkgsums usa makepkg --geninteg 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, sha256sum e adicionados ao vetor sha256sums manualmente.
Usar outros algoritmos de compressão
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 lzop necessário:
$ PKGEXT='.pkg.tar.lzo' makepkg
Para fazer uma dessas configurações permanentes, configure PKGEXT em /etc/makepkg.conf.
Usando vários núcleos na compressão
O xz oferece suporte a multiprocessamento simétrico (SMP) por meio do sinalizador --threads 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 COMPRESSXZ em /etc/makepkg.conf:
COMPRESSXZ=(xz -c -z - --threads=0)
O pigz é uma implementação paralela para o gzip que, por padrão, usa todos os núcleos disponíveis na CPU (o sinalizador -p/--processes pode ser usado para empregar menos núcleos):
COMPRESSGZ=(pigz -c -f -n)
pbzip2 é 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 -p# pode ser usado para empregar menos núcleos (note: nenhum espaço entre o -p e número de núcleos).
COMPRESSBZ2 =(pbzip2 -c -f)
zstd possui suporte a multiprocessamento simétrico (SMP) por meio do sinalizador --threads 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 /etc/makepkg.conf:
COMPRESSZST=(zstd -c -z -q - --threads=0)
Mostrar pacotes com um empacotador específico
expac é 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 /etc/makepkg. Isso mostra apenas pacotes que estão em um repositório definido em /etc/pacman.conf.
$ . /etc/makepkg.conf; grep -xvFf <(pacman -Qqm) <(expac "%n\t%p" | grep "$PACKAGER$" | cut -f1)
Compilar pacotes 32 bits em um sistema 64 bits
Primeiro, habilite o repositório multilib e instale multilib-devel.
Então, crie um arquivo de configuração 32 bits
~/.makepkg.i686.conf
CARCH="i686"
CHOST="i686-unknown-linux-gnu"
CFLAGS="-m32 -march=i686 -mtune=generic -O2 -pipe"
CXXFLAGS="${CFLAGS}"
LDFLAGS="-m32 -Wl,-O1,--sort-common,--as-needed,-z,relro"
e chame o makepkg assim
$ linux32 makepkg --config ~/.makepkg.i686.conf
Solução de problemas
Especificando diretório de instalação para pacotes baseados em QMAKE
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:
PKGBUILD
...
package() {
cd "$srcdir/${pkgname%-git}"
make INSTALL_ROOT="$pkgdir" install
}
...
Note que o qmake também tem que ser configurado adequadamente. Por exemplo, coloque isso em seu arquivo .pro:
SeuProjeto.pro
... target.path = /usr/local/bin INSTALLS += target ...
AVISO: O pacote contém referência para $srcdir
De alguma forma, as strings literais contidas nas variáveis $srcdir ou $pkgdir 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.
Makepkg falha em baixar dependências quando por trás de um proxy
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 ftp_proxy, http_proxy, https_proxy e no_proxy.
Para que ter o makepkg funcionando por trás de um proxy, você tem que fazer um dos seguintes métodos.
Habilitar proxy definindo sua URL no XferCommand
O XferCommand pode ser definido para usar a URL de proxy desejada no /etc/pacman.conf. Adicione ou descomente a linha a seguir em seu pacman.conf[5]:
/etc/pacman.conf
... XferCommand = /usr/bin/curl -x http://usuário:[email protected]:80 -L -C - -f -o %o %u ...
Habilitar proxy via env_keep do sudoers
Alternativamente, pode-se usar a opção env_keep 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.
Makepkg falha, mas make obtém sucesso
Se algo compilar manualmente usando make, mas falhar através do makepkg, é quase certo que seja porque o /etc/makepkg.conf 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:
!buildflags, para evitar seu CPPFLAGS, CFLAGS, CXXFLAGS e LDFLAGS padrão.
!makeflags, para evitar seu MAKEFLAGS padrão, caso você tenha editado /etc/makepkg.conf para habilitar compilações paralelas.
!debug, para evitar seu DEBUG_CFLAGS e DEBUG_CXXFLAGS 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.