Construindo pacotes no Arch Linux (incluindo o AUR)

• PKGBUILD
• Obtenção de PKGBUILD / ETC
• Atualizando o PKGBUILD / ETC
• Compilando
• Repositório local
• Compile mais rapidamente
• Erro de assinatura PGP
• Pacotes de desenvolvimento do AUR
• Pacotes desatualizados

No Arch Linux, os repositórios oficiais são: core, extra e community. Esses pacotes já estão compilados e são instalados através pacman. Na maioria das vezes, os usuários em geral podem ignorar que esses 3 repositórios oficiais são separados. O Core contém os pacotes mais críticos, como kernel, processo de inicialização, rede, gerenciamento de pacotes, openssh e assim por diante. Ele também possui requisitos mais rigorosos de testes mais completos antes do lançamento de novas versões. Extra contém outros pacotes populares que não são tão críticos, como um servidor X, gerenciadores de janelas ou navegadores da web. Comunidade contém pacotes menos populares. Somente usuários confiáveis ​​(cerca de 60 usuários ativos que foram votados por outros usuários confiáveis) têm acesso para fazer alterações nos repositórios oficiais.

Em 2019, existem cerca de 11.000 pacotes nos repositórios oficiais, em https://www.archlinux.org/packages . Mas existem muitos outros programas disponíveis no Linux. Portanto, o AUR (Arch Linux User Repository) existe para que qualquer usuário do Arch possa adicionar um novo programa e se tornar seu mantenedor ou adotar um pacote "órfão" sem um mantenedor atual. Existem cerca de 55.000 pacotes no AUR, em https://aur.archlinux.org/ .

Existem 3 diferenças críticas com o AUR:

1. Novamente, esses pacotes podem ser produzidos por qualquer usuário, mesmo um novo.
2. O AUR abriga apenas a PKGBUILD, um script de shell para criar automaticamente o pacote, não binários compilados. (Às vezes, também contém pequenos patches de texto ou instalar / atualizar / desinstalar scripts de shell). Isso fez um trabalho tremendo, permitindo que qualquer usuário contribuísse, além de diminuir a chance de alguém poder distribuir código malicioso. A comunidade Arch ainda é bastante útil em relação a problemas com pacotes AUR, mas note-se que o uso deles é por sua conta e risco. Como tudo o que ele fornece é um PKGBUILD, é sua responsabilidade revisar o que PKGBUILDvocê usará. (É verdade que muitos usuários não fazem isso e apenas confiam nos outros para vigiar.)
3. Como pacmannão interage diretamente com o AUR, é sua responsabilidade atualizar os pacotes do AUR. Quando você atualiza periodicamente todo o seu sistema pacman, ele não baixa automaticamente as atualizações dos PKGBUILDarquivos AUR , compila e instala para você.

Embora este artigo se concentre na criação de pacotes a partir do AUR, as mesmas técnicas podem ser usadas para criar pacotes a partir dos repositórios oficiais.

PKGBUILD

Comparado a um .specarquivo que muitas outras distribuições usam, a PKGBUILDé um script de shell curto e simples. Embora alguns pacotes sejam mais complexos, eles podem ser simplesmente semelhantes aos seguintes:

pkgname=NAME
pkgver=VERSION
pkgrel=1
pkgdesc='DESCRIPTION'
url=http://example.com/
arch=('x86_64')
license=('GPL2')
source=(http://example.com/downloads/${pkgname}-${pkgver}.tar.gz)
sha256sums=('f0a90db8694fb34685ecd645d97d728b880a6c15c95e7d0700596028bd8bc0f9')

build() {
   cd "${srcdir}/${pkgname}-${pkgver}"
   ./configure
   make
}

package() {
   cd "${srcdir}/${pkgname}-${pkgver}"
   make install
}

Este documento refere-se a:

• PKGNAME: O nome de um pacote
• PKGVER: A versão de um pacote (quase sempre correspondente ao número da versão do upstream)
• PKGREL: A "versão" do Arch PKGBUILDpara um específico PKGVER(normalmente 1, mas incrementado se forem necessárias alterações em PKGBUILDversões entre os upstream)
• ARCH: As arquiteturas nas quais o pacote pode ser construído (um pouco herdado, pois os repositórios oficiais do Arch Linux suportam apenas "x86_64" (CPUs de 64 bits), mas os pacotes AUR ainda podem suportar "i686" (CPUs de 32 bits) ou "any" designar arquitetura é irrelevante)
• PKGBUILD/ETC: Quaisquer arquivos atualmente no repositório AUR; o PKGBUILDe quaisquer outros pequenos patches de texto ou instalar / atualizar / desinstalar scripts de shell. Não inclui arquivos upstream na sourcematriz.

Embora o AUR tenha provado ser extremamente confiável, é uma boa ideia olhar para a PKGBUILD/ETCpara garantir que está obtendo a fonte de um lugar em que você deseja confiar; (por exemplo, um local oficial do upstream, que pode ser do github - mas não apenas o repositório do github de uma pessoa aleatória que não esteja relacionado ao pacote upstream); e que PKGBUILD/ETCnão contém nenhum código suspeito.

Obtenção PKGBUILD/ETC

Do AUR

Se os repositórios oficiais não contêm um pacote que você deseja instalar, procure-o em https://aur.archlinux.org/ . Felizmente, você encontrará que o que está procurando existe, está atualizado e é mantido.

A melhor maneira de obter PKGBUILD/ETCo AUR é cloná-lo via git.

Instale git, se ainda não estiver:

# pacman -S git

Use o "Git Clone URL" mostrado no site da AUR para esse pacote:

$ git clone https://aur.archlinux.org/fslint.git

Digite o diretório e veja seu conteúdo. (Tudo listado aqui, exceto . .. .gité o PKGBUILD/ETC):

$ cd <PKGNAME>
$ ls -a
.  ..  .git  PKGBUILD  .SRCINFO

Se você examinar PKGBUILD, esperançosamente verá que ele usa o código fonte oficial oficial e executa etapas típicas para criar um pacote, por isso parece confiável. O .SRCINFOjust contém as informações mostradas no site sobre o pacote, portanto não é preocupante. Se houver outros arquivos aqui, eles não são (diretamente) fornecidos pelo upstream, portanto, os arquivos e como eles são usados PKGBUILDdevem ser examinados, para garantir que eles não contenham nada suspeito.

De Repositórios Oficiais

Embora seja necessário com muito menos frequência, você pode criar um pacote já nos repositórios oficiais, para incluir um novo patch, criar uma versão mais recente etc.

Obtenha PKGBUILD/ETCdos repositórios principais e extras:

$ git clone --single-branch --branch "packages/<PKGNAME>" git://git.archlinux.org/svntogit/packages.git "<PKGNAME>"

No repositório da comunidade:

$ git clone --single-branch --branch "packages/<PKGNAME>" git://git.archlinux.org/svntogit/community.git "<PKGNAME>"

Atualizando PKGBUILD/ETC

Se uma atualização PKGBUILD/ETCfor lançada, você poderá voltar a esse diretório criado usando-o git clonee atualizá-los:

$ git pull

Em seguida, recompile e atualize o pacote usando o método de sua escolha, abaixo.

Compilando

Existem várias maneiras de compilar pacotes. Em última análise, tudo usa makepkg. Existem 2 maneiras oficialmente suportadas:

• Para usar diretamente makepkg, consulte https://www.vultr.com/docs/using-makepkg-on-arch-linux .
• Para usar indiretamente makepkgem uma limpeza chroot, consulte https://www.vultr.com/docs/using-devtools-on-arch-linux .

Existem muitos programas AUR ajudante, (como o makepkginvólucro), que não são oficialmente suportados por Arch, tais como aurutils, yayeo recentemente descontinuado aurmane yaourt. Mesmo se você usar um desses outros programas auxiliares, é altamente recomendável que você se familiarize com as formas oficialmente suportadas de ser mais eficaz quando algo der errado.

O restante deste documento será usado YOUR BUILDERpara indicar o método que você escolher.

Repositório local

Você pode configurar um repositório local para ser um local central para todos os pacotes criados.

Coloque o repositório local onde quiser:

# mkdir /archLocalRepo

Execute YOUR BUILDERsem nenhuma opção de instalação automática e copie o pacote no seu repositório local.

# cp <PKGNAME>-<PKGVER>-<PKGREL>-<ARCH>.pkg.tar.xz /archLocalRepo

Adicione o novo pacote ao índice do repositório:

# repo-add /archLocalRepo/archLocalRepo.db.tar.gz /archLocalRepo/<PACKAGE-FILE-NAME>

Para remover um pacote do índice do repositório e do próprio arquivo do pacote:

# repo-remove /archLocalRepo/archLocalRepo.db.tar.gz <PKGNAME>
# rm /archLocalRepo/<PACKAGE-FILE-NAME>

Se você precisar substituir um arquivo de pacote existente, remova separadamente o que está sendo substituído e adicione o novo. Você não pode simplesmente copiar o novo arquivo sobre o antigo.

Configure pacmanpara usar seu repositório local, editando /etc/pacman.confe adicione o seguinte no final:

[archLocalRepo]
SigLevel = Optional TrustAll
Server = file:///archLocalRepo

Você precisa pacmanatualizar seu conhecimento de repositório (incluindo o local), bancos de dados; para ver os pacotes que você adicionou a ele:

# pacman -Sy

Você pode instalar o pacote, de maneira diferente do que se estivesse em um repositório oficial:

# pacman -S <PKGNAME>

Observe que se o pacote é apenas uma dependência de outro pacote que você vai instalar, você não precisa instalá-lo diretamente. Quando você instala este outro pacote, pacmanlocaliza e instala automaticamente os pacotes de dependência no seu repositório local.

Compile mais rapidamente

Por padrão, YOUR BUILDERcompila usando um único thread. Em sistemas com várias CPUs, você pode permitir o uso de vários threads sempre que possível. O sistema de compilação compilará partes do código-fonte em paralelo quando puder. Às vezes, partes do código exigem que outras partes com as quais ele interage já sejam compiladas, portanto, você nem sempre verá o número de threads em uso permitido. Edit /etc/makepkg.conf.

Para permitir o uso de quantos threads você possui núcleos virtuais, adicione o seguinte:

MAKEFLAGS="-j$(nproc)"

Nota: Isso sempre executará o comando nproc, portanto, sempre usará o número atual de núcleos, caso você atualize seu servidor Vultr

Para permitir o uso de vários núcleos virtuais, mas não todos, como reduzir o impacto no desempenho geral do sistema, adicione um número específico. Por exemplo, se você tiver 24 núcleos, poderá permitir que 21 sejam usados:

MAKEFLAGS="-j21"

A especificação de mais threads do que o número de núcleos virtuais que você possui diminuirá o desempenho.

É bastante raro, mas os sistemas de compilação de alguns pacotes têm problemas com a compilação paralela, por não definir adequadamente as dependências entre partes do código. Normalmente, os PKGBUILDarquivos desses pacotes tratam disso para você, invocando make -j1, que substitui o padrão definido. Se precisar disso e estiver ausente, informe-o ao mantenedor do pacote Arch.

Erro de assinatura PGP

Uma PKGBUILDmatriz de origem pode conter .ascou .sigarquivos. Eles geralmente são incluídos usando a expansão do bash brace, portanto, pode ser fácil perder:

source=("http://example.com/downloads/${pkgname}-${pkgver}.tar.gz{,.sig}")

Se um desses formatos de arquivos de assinatura estiver incluído na matriz de origem, YOUR BUILDERtentará verificar automaticamente a assinatura do arquivo de origem. A chave PGP da assinatura deve estar no chaveiro do usuário; caso contrário, será cancelado com o erro:

==> Verifying source file signatures with gpg...
    <SOURCE-FILE> ... FAILED (unknown public key 1234567890ABCDEF)
==> ERROR: One or more PGP signatures could not be verified!

É importante entender que uma chave GPG pode ser mostrada de várias maneiras. Sua impressão digital tem 40 caracteres hexadecimais e é o que você deve sempre usar. Um ID de chave longa tem os últimos 16 dígitos e um ID de tecla curta tem os últimos 8 dígitos. Embora mais curto seja conveniente, ele permite duplicatas, o que anula todo o raciocínio por trás da verificação de assinaturas. Pior, sabe-se que os invasores geram chaves falsas que correspondem a chaves de menor tamanho para desenvolvedores de alto nível.

Obter e verificar a impressão digital da chave PGP

Se você ainda não tentou compilar o pacote, baixe as fontes que incluirão o arquivo de assinatura: (Se você tentou compilar, ele já estará lá)

$ makepkg --nobuild --noextract

Para obter a impressão digital completa:

$ gpg <ASC-OR-SIG-FILENAME>
...
gpg:                using RSA key 155D3FC500C834486D1EEA677FD9FCCB000BEEEE
...

Idealmente, você deve verificar essa impressão digital a montante. Para ser seguro, o upstream deve fornecer as chaves de seus mantenedores em algum lugar do site ou na fonte. Simplesmente procurar a chave em um servidor de chaves não está realmente fazendo nada. Um invasor pode enviar facilmente uma chave falsa, porque os servidores de chave não verificam a autenticidade. As chaves podem ser assinadas por outras chaves; portanto, se você já possui uma chave em que confia, deve estar bastante seguro confiando nas chaves que elas assinaram.

Isso pode ser um pouco trabalhoso, especialmente quando o upstream não publica sua impressão digital ou a coloca em um local fácil de encontrar. O PKGBUILDirá conter uma validpgpkeysmatriz, que foi adicionada pelo mantenedor do Arch. Se o pacote for um repositório oficial, isso significa que um Usuário Confiável o colocou lá, e você deve estar razoavelmente seguro em confiar apenas em qualquer coisa listada na matriz. Se o pacote estiver no AUR, lembre-se de que apenas outro usuário do Arch o colocou lá. Se você está preocupado com a confiança, sempre pode consultar o usuário para ver o que ele fez no passado com o Arch.

Adicione a chave PGP ao seu chaveiro

Para adicionar a impressão digital ao seu chaveiro:

$ gpg --recv-keys <FINGERPRINT>

Agora você pode executar YOUR BUILDERe confiará na impressão digital.

Pacotes de desenvolvimento do AUR

Pacotes do AUR com nomes terminados -git, -svn, -bzrou -hgsão versões de desenvolvimento, que utilizam a montante do mais recente sistema de controle de versão comprometer em vez da montante é mais recente lançamento. Por exemplo, um-gitO pacote usaria a confirmação mais recente do upstream no ramo mestre (ou seu ramo equivalente). Isso é ótimo para executar correções de bugs do upstream e novos recursos que ainda não foram lançados, e ao trabalhar com o upstream em um bug que você está relatando, incluindo se você precisa verificar para eles que não é um bug que foi corrigido por uma confirmação que ainda não está em uma versão. Esses pacotes devem ser considerados potencialmente instáveis. Dito isso, infelizmente, às vezes não há alternativa, porque alguns mantenedores upstream nunca etiquetam lançamentos ou demoram demais entre os lançamentos de etiquetas e esperam que todos usem seu commit mais recente. Dependendo do pacote, você pode ser a primeira pessoa a tentar executar esse commit. Dependendo dos desenvolvedores upstream, seu último commit pode nem ser compilado,

É importante entender um erro comum. Não sinalize um pacote de desenvolvimento do AUR como desatualizado, simplesmente porque ele mostra um número de versão antigo! Os PKGBUILDarquivos do pacote de desenvolvimento contêm uma função adicional pkgver(), que é usada para analisar automaticamente uma atualização PKGVERdo código-fonte do upstream. Um formato comum para um -gitpacote é <TYPICAL-VERSION-NUMBER>.r<COMMITS-SINCE-LAST-RELEASE>.<GIT-COMMIT>-<PKGREL>. Um pacote pode ser listado no AUR como 5.0.0.r102.8d7b42ac21-1, porque é isso que ele PKGBUILDcontém. Porém, quando você criar um pacote, ele YOUR BUILDERserá atualizado automaticamente PKGVERpara refletir o código-fonte recém-baixado. De fato, se muitas novas versões foram lançadas, mas nada mudou no processo de compilação, a PKGBUILDlistagem de uma versão antiga pode acabar criando algo muito mais novo, como9.1.2.r53.2c9a41b723-1. Para esses pacotes, a versão listada no site é simplesmente a versão mais recente no momento em que o mantenedor do AUR teve que atualizar o PKGBUILD.

Os mantenedores do AUR NÃO devem apenas atualizar o PKGVERpara refletir novas versões. Eles devem fazê-lo apenas quando confirmações upstream mais recentes, na verdade, exigem algo mais PKGBUILDpara mudar.

Apenas sinalize um pacote AUR de desenvolvimento desatualizado se você souber que algo está realmente errado. Ou seja, você realmente tentou usá-lo e ele falha ao compilar ou analisar um novo formatado corretamente PKGVER. Às vezes, acontecem coisas que forçam o mantenedor do AUR a atualizar PKGBUILD, como as dependências upstream mudam, as configureopções mudam, as novas versões do GCC detectam erros no código-fonte que os anteriores, as localizações do repositório upstream mudam ou os desenvolvedores upstream mudam onde sua versão típica está dentro do código fonte quebrando oPKGVERfunção de análise. Entenda que, mesmo que falhe na compilação ou no funcionamento, isso pode significar que o mantenedor do AUR precisa fazer alterações em seu processo de compilação ou pode ser um problema de upstream com seu código-fonte pelo qual o mantenedor do AUR não é responsável.

Pacotes desatualizados

Certifique-se de ler a seção "Pacotes de desenvolvimento do AUR" acima, antes de relatar um pacote como desatualizado!

Se o upstream lançou uma versão mais recente para um pacote que não é de desenvolvimento do que no PKGBUILD, você pode clicar em "Sinalizar pacote desatualizado" e digitar uma mensagem para o mantenedor. Use https://packages.archlinux.org para pacotes oficiais do repositório e https://aur.archlinux.org para pacotes AUR. Uma mensagem útil seria o novo número da versão e talvez um link para o comunicado de liberação ou o código-fonte. O recurso de sinalização envia automaticamente sua mensagem ao mantenedor.

Em um pacote AUR, se não houver resposta após duas semanas, você pode clicar em "Enviar Solicitação" com o tipo "Órfão", se desejar solicitar a um Usuário Confiável que remova o mantenedor atual e torne o pacote órfão, se o mantenedor não responde à solicitação órfã. Geralmente, as pessoas arquivam solicitações órfãs apenas se estiverem aptas e dispostas a assumir o pacote, e de preferência apenas se já tiverem uma corrente de trabalho PKGBUILD.

Enquanto isso, você também pode atualizar um pacote desatualizado. Freqüentemente, você só precisa alterar a PKGBUILDatualizando PKGVERpara o número da nova versão e as somas de integridade são atualizadas. Existe um programa updpkgsumsno pacote pacman-contrib, que calcula automaticamente as somas e as atualiza PKGBUILDpara você. Vale a pena conferir as notas de versão do upstream, para ver se elas mencionam que algo precisa mudar durante o processo de instalação da nova versão. Às vezes, as alterações upstream exigem mais alterações ou revisões PKGBUILD/ETC. Freqüentemente, a sourcematriz é incorporada a PKGVERela, muitas vezes nem precisa ser atualizada.