Arch Build System O que é o Arch Build System O Arch Build System é um sistema semelhante a um porto para construir e embalar software a partir do código fonte. Embora o pacman seja a ferramenta especializada do Arch para o gerenciamento de pacotes binários (incluindo pacotes construídos com o ABS), o ABS é uma coleção de ferramentas para compilar fontes em pacotes instaláveis .pkg. tar. xz. O que é um sistema Ports-like Ports é um sistema usado pelo BSD para automatizar o processo de criação de software a partir do código fonte. O sistema usa uma porta para baixar, descompactar, corrigir, compilar e instalar o software fornecido. Uma porta é apenas um pequeno diretório no computador do usuário, nomeado após o software correspondente a ser instalado, que contém alguns arquivos com as instruções para a construção e instalação do software a partir do código fonte. Isso torna a instalação de software tão simples como digitar make ou make install clean dentro do diretório ports. ABS é um conceito semelhante ABS é composto de uma árvore de diretório (a árvore ABS) residente sob / var / abs. Esta árvore contém muitos subdiretórios, cada um dentro de um nome de repo e cada nomeado por seu respectivo pacote. Esta árvore representa (mas não contém) todo o software oficial do Arch. Recuperável através do sistema SVN. Você pode se referir a cada subdiretório nomeado por pacote como um ABS, da mesma forma que se referiria a uma porta. Esses ABS (ou subdiretórios) não contêm o pacote de software nem a fonte, mas sim um arquivo PKGBUILD (e às vezes outros arquivos). Um PKGBUILD é um simples script de compilação do Bash, um arquivo de texto contendo as instruções de compilação e empacotamento, assim como o URL do tarball de origem apropriado a ser baixado. (O componente mais importante do ABS são PKGBUILDs.) Ao emitir dentro do comando ABS makepkg, o software é primeiro compilado e depois empacotado dentro do diretório de compilação. Agora você pode usar pacman (o gerenciador de pacotes Arch Linux) para instalar, atualizar e remover o novo pacote. Resumo do ABS O ABS pode ser usado como um termo geral, uma vez que inclui e confia em vários outros componentes, portanto, embora não seja tecnicamente preciso, o ABS pode se referir às seguintes ferramentas como um conjunto completo de ferramentas: Árvore ABS A estrutura de diretório ABS contendo arquivos necessários para construir todos Oficiais (mas não os próprios pacotes nem os arquivos de origem do software). Ele está disponível nos repositórios svn e git eo script abs (do pacote abs) faz o download deles usando o rsync em / var / abs / em sua máquina (local). No sistema local, a árvore contém subdiretórios para cada repositório especificado em /etc/abs. conf. Que por sua vez contêm um subdiretório para cada pacote. Nota: A árvore ABS é sincronizada uma vez por dia, por isso pode ficar atrás do que já está disponível nos repositórios. PKGBUILD Um script Bash que contém o URL do código-fonte junto com as instruções de compilação e empacotamento. Makepkg shell ferramenta de comando que lê o PKGBUILDs, automaticamente downloads e compila as fontes e cria um. pkg. tar de acordo com a matriz PKGEXT em makepkg. conf. Você também pode usar makepkg para criar seus próprios pacotes personalizados a partir de fontes AUR ou de terceiros. Consulte Criando pacotes para obter mais informações. Pacman pacman é completamente separado, mas é necessariamente invocado por makepkg ou manualmente, para instalar e remover os pacotes construídos e para buscar dependências. AUR O Arch User Repository é separado do ABS mas AUR (não suportado) PKGBUILDs são construídos usando makepkg para compilar e empacotar o software. Em contraste com a árvore ABS em sua máquina local, o AUR existe como uma interface de site. Ele contém muitos milhares de PKGBUILDs contribuídos pelos usuários para o software que não está disponível como um pacote oficial do Arch. Se você necessitar construir um pacote fora da árvore oficial do arco, as possibilidades são ele estão no AUR. Aviso: Os PKGBUILDs oficiais supor que os pacotes são construídos em um chroot limpo. Construir software em um sistema de compilação sujo pode falhar ou causar um comportamento inesperado em tempo de execução, porque se o sistema de compilação detectar dependências dinamicamente, o resultado depende de quais pacotes estão disponíveis no sistema de compilação. Por que eu gostaria de usar o ABS O Arch Build System é usado para: Compilar ou recompilar um pacote, por qualquer motivo Faça e instale novos pacotes a partir da fonte de software para os quais ainda não existem pacotes disponíveis (consulte Criação de pacotes) (Por exemplo, com pacbuilder) Construa e instale seu próprio kernel personalizado (veja a compilação do kernel) Obtenha os módulos do kernel trabalhando com seu kernel personalizado Compile e instale facilmente seu próprio kernel personalizado Instalar uma versão mais nova, mais antiga, beta ou de desenvolvimento de um pacote Arch editando o número da versão no PKGBUILD ABS não é necessário usar o Arch Linux, mas é útil para automatizar certas tarefas de compilação de origem. Como usar o ABS Construir pacotes usando abs consiste em estas etapas: Instale o pacote de abs com pacman. Execute abs como root para criar a árvore ABS, sincronizando-a com o servidor Arch Linux. Copie os arquivos de compilação (geralmente residentes em / var / abs / ltrepogt / ltpkgnamegt) para um diretório de compilação. Navegue até esse diretório, edite o PKGBUILD (se desejado / necessário) e faça makepkg. De acordo com as instruções no PKGBUILD, makepkg irá baixar o tarball fonte adequada, descompactá-lo, patch (se desejado), compilar de acordo com CFLAGS especificado em makepkg. conf. E finalmente comprimir os arquivos construídos em um pacote com a extensão. pkg. tar. gz ou. pkg. tar. xz. Instalar é tão fácil como fazer pacman - U lt. pkg. tar. xz filegt. A remoção de pacotes também é feita pelo pacman. Instale as ferramentas Isso irá pegar os scripts abs-sync, vários scripts de compilação e rsync (como uma dependência, se você ainda não tiver). Antes que você possa realmente construir qualquer coisa, no entanto, você também vai precisar de ferramentas básicas de compilação. Estes são facilmente coletados no grupo de pacotes base-devel. Este grupo pode ser instalado com pacman. /etc/abs. conf Edite /etc/abs. conf para incluir seus repositórios desejados. Remova o. Na frente dos repositórios apropriados. Por exemplo: A árvore ABS é uma hierarquia de diretório SVN localizada em / var / abs e se parece com isto: A árvore ABS tem exatamente a mesma estrutura que o banco de dados do pacote: Primeiro nível: Nome do repositório Segundo nível: : PKGBUILD (contém informações necessárias para criar um pacote) e outros arquivos relacionados (patches, outros arquivos necessários para a construção do pacote) O código-fonte para o pacote não está presente no diretório ABS. Em vez disso, o PKGBUILD contém um URL que irá transferir o código de origem quando o pacote é criado. Assim, o tamanho da árvore abs é bastante pequeno. Baixar árvore ABS Sua árvore ABS agora é criada em / var / abs. Observe que os ramos de árvore foram criados correspondendo aos que você especificou no /etc/abs. conf. O comando abs deve ser executado periodicamente para manter em sincronia com os repositórios oficiais. Arquivos individuais do pacote ABS também podem ser baixados com: Desta forma, você não precisa verificar a árvore abs inteira apenas para construir um pacote. /etc/makepkg. conf Notas: use o segundo argumento do modelo para fornecer indicações mais detalhadas. Makepkg s /etc/makepkg. conf especifica variáveis de ambiente globais e sinalizadores de compilador que você pode editar se você estiver usando um sistema SMP ou especificar outras otimizações desejadas. As configurações padrão são para o i686 e x8664 otimizações que funcionará bem para essas arquiteturas em sistemas de CPU única. (Os padrões funcionarão em máquinas SMP, mas só usarão um núcleo / CPU ao compilar see makepkg para detalhes.) Definir a variável PACKAGER em /etc/makepkg. conf Definir a variável PACKAGER em /etc/makepkg. conf é um opcional Mas passo altamente recomendado. Permite que uma bandeira identifique rapidamente quais pacotes foram construídos e / ou instalados por VOCÊ, não o mantenedor oficial. Isto é facilmente realizado usando o expac. Mostrando todos os pacotes (incluindo aqueles de AUR) Mostrando apenas pacotes contidos em repos Este exemplo mostra apenas pacotes contidos nos repos definidos em /etc/pacman. conf. Criar um diretório de compilação É recomendável criar um diretório de compilação onde a compilação real ocorrerá. Nunca deverá modificar a árvore de ABS construindo dentro dela, pois os dados serão perdidos (substituídos) em cada atualização do ABS. É uma boa prática usar seu diretório pessoal, embora alguns usuários do Arch preferem criar um diretório local sob / var / abs /. Propriedade de um usuário normal. Crie seu diretório de compilação. por exemplo. Copie o ABS da árvore (/ var / abs / ltrepositorygt / ltpkgnamegt) para o diretório de compilação. Pacote de compilação No nosso exemplo, vamos construir o pacote de gerenciador de exibição de slim. Copie o ABS slim da árvore ABS para um diretório de construção: Navegue para o diretório de compilação: Modifique o PKGBUILD de acordo com seu gosto. Se você precisar fazer alterações na própria fonte, em vez de apenas no PKGBUILD, consulte Patching no ABS. Em seguida, execute makepkg (com o sinalizador - s para ativar a manipulação automática de dependências de tempo de compilação): Observação: Antes de reclamar sobre dependências ausentes (make), lembre-se de que o grupo base-devel é assumido como sendo instalado ao criar com makepkg. Consulte Instalar ferramentas. Instale como root: É isso. Você acabou de construir slim da fonte e instalou-o de forma limpa para o seu sistema com o pacman. A remoção de pacotes também é tratada pelo pacman com pacman - R slim. O método ABS de instalação de software proporciona conforto, mantendo a transparência completa e controle das funções de construção e instalação incluídas no PKGBUILD. Essencialmente, as mesmas etapas estão sendo executadas no método tradicional (geralmente incluindo as etapas ./configure, make, make install), mas o software é instalado em um ambiente falso de raiz. (Uma raiz falsa é simplesmente um subdiretório dentro do diretório de compilação que funciona e se comporta como o diretório raiz do sistema. Em conjunto com o programa fakeroot, makepkg cria um diretório raiz falso e instala os binários compilados e arquivos associados nele, com root como Proprietário.) A raiz falsa. Ou subdiretório que contém o software compilado, é então compactado em um arquivo com a extensão. pkg. tar. xz. Ou um pacote. Quando invocado, o pacman extrai o pacote (o instala) no diretório raiz real do sistema (/). Preservar pacotes modificados A atualização do sistema com o pacman substituirá um pacote modificado do ABS pelo pacote do mesmo nome dos repositórios oficiais. Consulte as instruções a seguir para saber como evitar isso. Insira uma matriz de grupo no PKGBUILD e adicione o pacote a um grupo chamado modificado. Adicione este grupo à seção IgnoreGroup em /etc/pacman. conf. Se novas versões estiverem disponíveis nos repositórios oficiais durante uma atualização do sistema, o pacman imprime uma nota que ignora esta atualização porque está na seção IgnoreGroup. Neste ponto o pacote modificado deve ser reconstruído a partir do ABS para evitar upgrades parciais. Outras ferramentas pbget - recupera PKGBUILDs para pacotes individuais diretamente da interface da web. Inclui suporte AUR. Asp - uma ferramenta para gerenciar os arquivos de origem de compilação usados para criar pacotes Arch Linux. Usa a interface do git que oferece fontes mais atuais. Estou tentando criar meu primeiro deb assim que eu não sei muito sobre ele ainda. Este é o meu arquivo de regras no momento: No momento estou lendo documentação e tentando entender como escrever arquivos de regras mais complicadas. Estou preso em binário-arco e binário-indep alvos. Em suma, eu não entendo o que eles realmente representam. A documentação diz que o arco do pacote é determinado pela Arquitetura: linha no arquivo de controle. Se o valor for tudo, o pacote é dependente da arquitetura. Se o valor é qualquer, então o pacote é uma arquitetura independente. Compreendo perfeitamente esta parte. Mas então eu começo a ler arquivos do homem para ferramentas do debhelper. Man dpkg-buildpackage diz: Ele chama debian / rules build seguido de fakeroot debian / rules binary-target (a menos que uma compilação somente fonte tenha sido solicitada com - S). Observe que binário-alvo é binário (caso padrão, ou se - b é especificado) ou binário-arco (se - B é especificado) ou binário-indep (se - A é especificado) Comandos na seqüência binário-indep são passados A opção - i para garantir que eles funcionem apenas em pacotes binários independentes e os comandos nas seqüências de arco binário passam a opção - a para garantir que eles funcionem apenas em pacotes dependentes da arquitetura. Então eu tento ver o conjunto padrão de comandos para binário, binário-arco e alvos binários-indep, digitando e obter conjuntos de comandos totalmente iguais. A única diferença é - i e - a sinalizadores após cada comando. Então a primeira pergunta é - qual é a diferença entre, por exemplo, dhautobuild, dhautobuild - a e dhautobuild - i (ou algum outro dhcommand) E outra pergunta é - se o meu arquivo de controle consiste apenas em pacotes com toda a arquitetura preciso usar binário - indep alvo, ou eu posso fazer sem ele e usar apenas construir-arco alvo no meu arquivo de regras. Perguntou May 27 13 at 20:37 The Difference O binário destino-indep constrói todos Arquitetura: todos os pacotes binários em seu pacote de origem. O binário de destino constrói todos os outros pacotes, Arquitetura: qualquer ou pacotes com uma lista de arquitetura explícita ou alguns caracteres de arquitetura como Arquitetura: linux-any. A distinção destes dois caminhos dentro do processo de compilação é relevante se você tiver um pacote de origem que contenha ambos os tipos de pacotes binários, dependentes da arquitetura e independentes: A compilação inicial do pacote constrói ambos os tipos de pacotes binários, mas cada compilação subseqüente Em diferentes arquiteturas só precisa construir os pacotes binários dependentes da arquitetura já que você já construiu todos os pacotes independentes da arquitetura na primeira compilação. Imagine que você tem um pacote de origem chamado foo que constrói os pacotes binários foo-programs e foo-data. Enquanto os programas em foo-programas precisam ser compilados (por exemplo, por estar escrito em C) e, portanto, o pacote binário é de Arquitetura: qualquer. Os arquivos de dados em foo-data (imagens, traduções, textos de ajuda, documentação, texturas, mapas de jogo, etc.) são os mesmos para todas as arquiteturas, daí sua Arquitetura: tudo. Vamos dizer que a versão upstream do foo é 1.0 e é a primeira revisão do pacote Debian dessa versão upstream. Você primeiro constrói todos os pacotes na arquitetura amd64 para PCs de 64 bits, você obterá foo-programs1.0-1amd64.deb e foo-data1.0-1all. deb. Mas você também quer ser capaz de executá-lo em PCs de 32 bits, daí você também precisa foo-programs1.0-1i386.deb. Mas você não precisa de um segundo foo-data1.0-1all. deb. Para que seu processo de compilação só exija os alvos - arch, p. Chamando dpkg-buildpackage - B. Necessidade de alvos explícitos Com o debian / rules de estilo dh mínimo, pode não ser necessário especificar explicitamente alvos, já que muitos sistemas de compilação upstream não fazem essa distinção, mas se o fizerem (por exemplo, tendo um alvo de criação separado para a construção da documentação, Implementar que, por exemplo, como este: (Exemplo tirado da página do manual dh (7).) Criando pacotes Este artigo tem como objetivo auxiliar os usuários a criar seus próprios pacotes usando o sistema de construção Arch-Linux, também para apresentação em AUR. De um PKGBUILD 8211 um arquivo de descrição de compilação de pacote obtido por makepkg para criar um pacote binário de origem. Se já estiver em posse de um PKGBUILD, veja makepkg. Para obter instruções sobre regras existentes e formas de melhorar a qualidade do pacote, Linux é construído usando o utilitário makepkg e as informações armazenadas em um arquivo PKGBUILD. Quando makepkg é executado, ele procura um PKGBUILD no diretório atual e segue as instruções nele para adquirir os arquivos necessários e / ou compilá-los para serem empacotados dentro de um Arquivo de pacote (pkgname. pkg. tar. xz). O pacote resultante contém arquivos binários e instruções de instalação prontos para serem instalados pelo pacman. Um pacote Arch não é mais do que um arquivo tar, ou tarball, compactado usando xz, que contém os seguintes arquivos gerados pelo makepkg: Os arquivos binários a serem instalados..PKGINFO. Contém todos os metadados necessários pelo pacman para lidar com pacotes, dependências, etc. MTREE. Contém hashes e timestamps dos arquivos, que estão incluídos no banco de dados local para que o pacman possa verificar a integridade do pacote..INSTALAR. Um arquivo opcional usado para executar comandos após o estágio de instalação / atualização / remoção. (Este arquivo está presente somente se especificado no PKGBUILD.).Chogar. Um arquivo opcional mantido pelo mantenedor do pacote documentando as alterações do pacote. (Não está presente em todos os pacotes.) Meta pacotes e grupos Um grupo de pacotes é um conjunto de pacotes relacionados, definidos pelo packager, que podem ser instalados ou desinstalados simultaneamente usando o nome do grupo como um substituto para cada nome de pacote individual. Enquanto um grupo não é um pacote, ele pode ser instalado de forma semelhante a um pacote, consulte PacmanInstalling grupos de pacotes e PKGBUILDgroups. Um meta pacote, muitas vezes (embora nem sempre) intitulado com o sufixo - meta, fornece funcionalidade semelhante a um grupo de pacotes, pois permite que vários pacotes relacionados sejam instalados ou desinstalados simultaneamente. Meta pacotes podem ser instalados como qualquer outro pacote, consulte PacmanInstalling pacotes específicos. A única diferença entre um pacote meta e um pacote regular é que um pacote meta está vazio e existe puramente para vincular pacotes relacionados juntos via dependências. A vantagem de um meta pacote, em comparação com um grupo, é que qualquer novo membro pacotes serão instalados quando o meta pacote em si é atualizado com um novo conjunto de dependências. Isto está em contraste com um grupo em que os novos membros do grupo não serão instalados automaticamente. A desvantagem de um pacote meta é que ele não é tão flexível quanto um grupo - você pode escolher quais membros do grupo deseja instalar, mas não é possível escolher quais dependências de pacotes meta você deseja instalar. Da mesma forma, você pode desinstalar membros do grupo sem ter que remover o grupo inteiro, mas não é possível remover as dependências do pacote meta sem ter que desinstalar o próprio pacote meta. Preparação Software de pré-requisito Certifique-se primeiro de que as ferramentas necessárias estão instaladas. A instalação do grupo de pacotes base-devel deve ser suficiente, inclui make e ferramentas adicionais necessárias para a compilação a partir da fonte. Uma das principais ferramentas para a criação de pacotes é makepkg (fornecido pelo pacman), que faz o seguinte: Verifica se as dependências do pacote estão instaladas. Descarrega o (s) arquivo (s) de origem do (s) servidor (es) especificado (s). Descompacta o (s) arquivo (s) de origem. Compila o software e o instala em um ambiente fakeroot. Tira símbolos de binários e bibliotecas. Gera o arquivo meta do pacote que está incluído em cada pacote. Comprime o ambiente fakeroot em um arquivo de pacote. Armazena o arquivo de pacote no diretório de destino configurado, que é o atual diretório de trabalho por padrão. Baixe e teste a instalação Faça o download do tarball de origem do software que deseja empacotar, extraia-o e siga as etapas dos autores para instalar o programa. Anote todos os comandos e / ou etapas necessários para compilá-lo e instalá-lo. Você estará repetindo os mesmos comandos no arquivo PKGBUILD. A maioria dos autores de software adere ao ciclo de compilação de 3 etapas: Este é um bom momento para se certificar de que o programa está funcionando corretamente. Criando um PKGBUILD Quando você executa o makepkg. Ele procurará um arquivo PKGBUILD no atual diretório de trabalho. Se um arquivo PKGBUILD for encontrado, ele baixará o código fonte do software e o compilará de acordo com as instruções especificadas no arquivo PKGBUILD. As instruções devem ser totalmente interpretáveis pelo shell Bash. Após a conclusão bem-sucedida, os binários e metadados resultantes do pacote, isto é, a versão do pacote e as dependências, são compactados em um arquivo de pacote pkgname. pkg. tar. xz que pode ser instalado com pacman - U ltpackage filegt. Para começar com um novo pacote, você deve primeiro criar um diretório de trabalho vazio, (preferencialmente / abs / pkgname), mudar para esse diretório e criar um arquivo PKGBUILD. Você pode copiar o protótipo PKGBUILD /usr/share/pacman/PKGBUILD. proto para seu diretório de trabalho ou copiar um PKGBUILD de um pacote similar. O último pode ser útil se você só precisa alterar algumas opções. Aviso: Utilize apenas os protótipos PKGBUILD fornecidos no pacote pacman (PKGBUILD-split. proto, PKGBUILD-vcs. proto e PKGBUILD. proto). Os arquivos de protótipos no pacote abs e no repositório ABS git estão significativamente desatualizados e não devem ser usados. Ver FS34485. Definindo variáveis PKGBUILD Exemplo PKGBUILDs estão localizados em / usr / share / pacman /. Uma explicação de possíveis variáveis PKGBUILD pode ser encontrada no artigo PKGBUILD. Makepkg define duas variáveis que você deve usar como parte do processo de compilação e instalação: srcdir Isso aponta para o diretório em que makepkg extrai ou simboliza todos os arquivos na matriz de origem. Pkgdir Isso aponta para o diretório em que o makepkg agrupa o pacote instalado, que se torna o diretório raiz do seu pacote construído. Todos eles contêm caminhos absolutos, o que significa, você não precisa se preocupar com seu diretório de trabalho se você usar essas variáveis corretamente. Nota: makepkg. E, portanto, as funções build () e package (), são destinadas a ser não-interativo. Utilitários interativos ou scripts chamados nessas funções podem quebrar makepkg. Especialmente se for invocado com o build-logging ativado (-L). (Consulte FS13214.) Observação: Além do atual Pacote Manutenção, podem existir mantenedores anteriores listados acima como Contribuintes. Funções PKGBUILD Existem cinco funções, listadas aqui na ordem em que são executadas, se todas elas existem. Se não existe, simplesmente é ignorado. Nota: Isto não se aplica à função package (), como é exigido em cada PKGBUILD Começando com pacman 4.1, você pode atualizar a variável pkgver durante um makepkg. Pkgver () é executado logo após as fontes são obtidas e extraídas. Isto é particularmente útil se você estiver fazendo git / svn / hg / etc. Pacotes. Onde o processo de compilação pode permanecer o mesmo, mas a fonte pode ser atualizada todos os dias, mesmo a cada hora. A velha maneira de fazer isso era colocar a data no campo pkgver que, se o software não foi atualizado, makepkg ainda iria reconstruí-lo pensando que a versão tinha mudado. Alguns comandos úteis para isso são git descrever. Hg identificar - ni. Etc Por favor, teste estes antes de enviar um PKGBUILD, como uma falha na função pkgver () pode parar uma compilação em suas faixas. Observação: pkgver não pode conter espaços ou hifens (-). Usando sed para corrigir isso é comum. Pacman 4.1 introduz a função prepare (). Nesta função, os comandos que são usados para preparar fontes para construção são executados, como o patch. Essa função é executada antes da função de compilação e após a extração do pacote. Se a extração é ignorada (makepkg - e), então prepare () não é executado. Nota: (Do homem PKGBUILD) A função é executada no modo bash - e, significando que qualquer comando que sai com um status diferente de zero fará com que a função saia. Agora você precisa implementar a função build () no arquivo PKGBUILD. Esta função usa comandos shell comuns na sintaxe Bash para compilar automaticamente o software e criar um diretório pkg para instalar o software. Isso permite que o makepkg envie arquivos sem ter que passar pelo sistema de arquivos. A primeira etapa na função build () é mudar para o diretório criado descompactando o tarball de origem. Makepkg irá alterar o diretório atual para srcdir antes de executar a função build (). Portanto, na maioria dos casos, como sugerido em /usr/share/pacman/PKGBUILD. proto. O primeiro comando será semelhante a este: Agora, você precisa listar os mesmos comandos que você usou quando você compilou manualmente o software. A função build () basicamente automatiza tudo o que você fez manualmente e compila o software no ambiente de compilação fakeroot. Se o software que você está empacotando usa um script configure, é uma boa prática usar --prefix / usr ao construir pacotes para pacman. Um monte de software instala arquivos relativos ao diretório / usr / local, o que só deve ser feito se você estiver construindo manualmente a partir da fonte. Todos os pacotes do Arch Linux devem usar o diretório / usr. Como visto no arquivo /usr/share/pacman/PKGBUILD. proto, as próximas duas linhas geralmente se parecem com isso: Nota: Se o software não precisar construir nada, NÃO use a função build (). A função build () não é necessária, mas a função package () é. Local para chamadas para fazer check e rotinas de testes semelhantes. É altamente recomendável ter check (), pois ajuda a garantir que o software foi construído corretamente e funciona bem com suas dependências. Usuários que não precisam dele (e ocasionalmente mantenedores que não conseguem corrigir um pacote para isso passar) podem desativá-lo usando BUILDENV (check) em PKGBUILD / makepkg. conf ou chamar makepkg com --nocheck flag. A etapa final é colocar os arquivos compilados em um diretório onde makepkg pode recuperá-los para criar um pacote. Por padrão, o diretório pkg é um ambiente fakeroot simples. O diretório pkg replica a hierarquia do sistema de arquivos raiz dos caminhos de instalação dos softwares. Se você tiver que colocar arquivos manualmente na raiz do seu sistema de arquivos, você deve instalá-los no diretório pkg sob a mesma estrutura de diretório. Por exemplo, se você deseja instalar um arquivo em / usr / bin. Ele deve ser colocado em pkgdir / usr / bin. Muito poucos procedimentos de instalação exigem que o usuário copie dezenas de arquivos manualmente. Em vez disso, para a maioria dos softwares, chamar make install irá fazê-lo. A última linha deve ser semelhante à seguinte para instalar corretamente o software no diretório pkg: Nota: às vezes é o caso em que DESTDIR não é usado no Makefile você pode precisar usar o prefixo em vez disso. Se o pacote é construído com autoconf / automake. Use DESTDIR isso é o que está documentado nos manuais. Se DESTDIR não funcionar, tente construir com make prefixpkgdir / usr / install. Se isso não funcionar, você terá que olhar mais para os comandos de instalação que são executados por make lt. Gt install. Em alguns casos ímpares, o software espera ser executado a partir de um único diretório. Em tais casos, é aconselhável simplesmente copiá-los para pkgdir / opt. Mais frequentemente do que não, o processo de instalação do software irá criar sub-diretórios abaixo do diretório pkg. No entanto, makepkg irá gerar muitos erros e você precisará criar manualmente subdiretórios adicionando os comandos apropriados do mkdir - p na função build () antes que o procedimento de instalação seja executado. Em pacotes antigos, não havia nenhuma função package (). Assim, os arquivos foram colocados no diretório pkg no final da função build (). Se package () não estiver presente, build () é executado via fakeroot. Em novos pacotes, o pacote () é necessário e é executado via fakeroot e build () executa sem privilégios especiais. Makepkg --repackage executa apenas a função package (), então cria um. pkg. Arquivo sem compilar o pacote. Isto pode poupar tempo, e. Se você apenas mudou a variável dependente do pacote. Nota: A função package () é a única função necessária em um PKGBUILD. Se você só deve copiar arquivos em seus respectivos diretórios para instalar um programa, não o coloque na função build (), coloque isso na função package (). Nota: A criação de links simbólicos é um processo um tanto desajeitado na função package (). Usando a abordagem naive ln - s / from / foo / to / goo resultará em um link simbólico quebrado para o diretório de compilação. A maneira de criar um link adequado é criá-lo apontando para uma fonte inicialmente quebrada, ln - s / from / foo / to / goo. Uma vez que o pacote é instalado, o link irá apontar para o lugar certo. Testando o PKGBUILD eo pacote Como você está escrevendo a função build (), você vai querer testar suas alterações com freqüência para garantir que não haja erros. Você pode fazer isso usando o comando makepkg no diretório que contém o arquivo PKGBUILD. Com um PKGBUILD devidamente formatado. Makepkg criará um pacote com um PKGBUILD quebrado ou inacabado. Ele irá gerar um erro. Se makepkg terminar com êxito, ele colocará um arquivo chamado pkgname-pkgver. pkg. tar. xz em seu diretório de trabalho. Este pacote pode ser instalado com o comando pacman - U. No entanto, apenas porque um arquivo de pacote foi criado não implica que ele é totalmente funcional. Poderia conter apenas o diretório e nenhum arquivo se, por exemplo, um prefixo foi especificado incorretamente. Você pode usar as funções de consulta do pacmans para exibir uma lista de arquivos contidos no pacote e as dependências que ele requer com o arquivo de pacote pacman - Qlp e o arquivo pacman - Qip, respectivamente. Se o pacote parecer sã, então você está concluído No entanto, se você planeja liberar o arquivo PKGBUILD, é imperativo que você verifique e verifique novamente o conteúdo da matriz depende. Certifique-se também de que os binários do pacote realmente funcionam perfeitamente É irritante para liberar um pacote que contém todos os arquivos necessários, mas falha por causa de alguma opção de configuração obscura que não funciona bem com o resto do sistema. Se você só vai compilar pacotes para o seu próprio sistema, no entanto, você não precisa se preocupar muito com esta etapa de garantia de qualidade, como você é a única pessoa que sofre de erros, afinal. Verificação da sanidade do pacote Após testar a funcionalidade do pacote, verifique se há erros usando o namcap. Verifique o conteúdo de PKGBUILD para erros comuns e hierarquia de arquivos de pacote para arquivos desnecessários / incorretos Varre todos os arquivos ELF no pacote usando ldd. Informando automaticamente quais pacotes com bibliotecas compartilhadas necessárias estão faltando de dependentes e que podem ser omitidos como dependências transitivas Heuristicamente buscam dependências em falta e redundantes e muito mais. Adquira o hábito de verificar seus pacotes com namcap para evitar ter que corrigir os erros mais simples após a apresentação do pacote. Enviando pacotes para a AUR Por favor, leia AUR User GuidelinesSubmitting pacotes para uma descrição detalhada do processo de submissão. Faça o download do tarball de origem do software que deseja empacotar. Tente compilar o pacote e instalá-lo em um diretório arbitrário. Copie o protótipo /usr/share/pacman/PKGBUILD. proto e renomeie-o para PKGBUILD em um diretório de trabalho temporário - preferencialmente / abs /. Edite o PKGBUILD de acordo com as necessidades do seu pacote. Execute makepkg e verifique se o pacote resultante é criado corretamente. Caso contrário, repita os dois últimos passos. Antes de automatizar o processo de construção de pacotes, você deve ter feito isso manualmente pelo menos uma vez, a menos que saiba exatamente o que está fazendo com antecedência. Caso em que você não estaria lendo isso em primeiro lugar. Infelizmente, apesar de um bom grupo de autores do programa se ater ao ciclo de compilação de 3 etapas do ./configure make make install, isso nem sempre é o caso, e as coisas podem ficar muito feias se você tiver que aplicar patches para fazer tudo funcionar em todos . Regra geral: Se você não conseguir obter o programa para compilar do tarball de origem e torná-lo instalar em um subdiretório definido, temporário, você nem precisa tentar empacotá-lo. Não há nenhuma poeira mágica do duende no makepkg que faz com que os problemas da fonte desapareçam. In a few cases, the packages are not even available as source and you have to use something like sh installer. run to get it to work. You will have to do quite a bit of research (read READMEs, INSTALL instructions, man pages, perhaps ebuilds from Gentoo or other package installers, possibly even the MAKEFILEs or source code) to get it working. In some really bad cases, you have to edit the source files to get it to work at all. However, makepkg needs to be completely autonomous, with no user input. Therefore if you need to edit the makefiles, you may have to bundle a custom patch with the PKGBUILD and install it from inside the prepare() function, or you might have to issue some sed commands from inside the prepare() function. More detailed guidelines Package creation guidelines
No comments:
Post a Comment