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 criados 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 pela 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 de origem. 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 similar ABS é composto de uma árvore de diretório (a árvore ABS) residente sob varabs. 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, bem 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 genérico, 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 rsync em varabs em sua máquina (local). No sistema local, a árvore contém subdiretórios para cada repositório especificado em etcabs. conf. Que por sua vez contêm um subdiretório para cada pacote. Nota: A árvore ABS é sincronizada uma vez por dia, de modo que pode ficar aquém 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 Criação de 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 (sem suporte) 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 pelo usuário 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: 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 o 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 recente, mais antiga, beta ou de desenvolvimento de um pacote do 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 ABS Building pacotes usando abs consiste em estas etapas: Instalar 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 (normalmente residentes em varabsltrepogtltpkgnamegt) em um diretório de compilação. Navegue até esse diretório, edite o PKGBUILD (se 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. A instalação é tão fácil como fazer pacman - U lt. pkg. tar. xz filegt. A remoção de pacotes também é tratada 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. Etcabs. conf Edite etcabs. conf para incluir seus repositórios desejados. Remova o. Na frente dos repositórios apropriados. Por exemplo: A árvore ABS é uma hierarquia de diretórios SVN localizada sob varabs e tem a seguinte aparência: A árvore ABS tem exatamente a mesma estrutura do banco de dados de pacotes: Primeiro nível: Nome do repositório Segundo nível: Diretórios do nome do pacote Terceiro 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 pequena. Baixar árvore ABS Sua árvore ABS agora é criada sob varabs. Observe que os ramos de árvore foram criados correspondendo aos que você especificou em etcabs. 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. Etcmakepkg. conf Notas: use o segundo argumento do modelo para fornecer indicações mais detalhadas. (Discutir em Discussão: Arch Build System) makepkg s etcmakepkg. conf especifica variáveis de ambiente global 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. Definir a variável PACKAGER em etcmakepkg. conf Definir a variável PACKAGER em etcmakepkg. conf é uma etapa opcional, mas altamente recomendável. Permite que uma bandeira identifique rapidamente quais pacotes foram construídos e / ou instalados por VOCÊ, e não o mantenedor oficial. Isto é facilmente realizado usando 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 etcpacman. conf. Criar um diretório de compilação É recomendável criar um diretório de compilação onde a compilação real ocorrerá. Nunca modifique 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 varabs. Propriedade de um usuário normal. Crie seu diretório de compilação. por exemplo. Copie o ABS da árvore (varabsltrepositorygtltpkgnamegt) para o diretório de compilação. Criar pacote No nosso exemplo, vamos construir o pacote de gerenciador de exibição slim. Copie o ABS esbelto da árvore ABS para um diretório de compilação: Navegue até o diretório de compilação: Modifique o PKGBUILD para o 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 o gerenciamento automático de dependência 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 limpamente instalado para o seu sistema com 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 total 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 etcpacman. 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 essa atualização porque está na seção IgnoreGroup. Neste ponto o pacote modificado deve ser reconstruído a partir do ABS para evitar atualizações 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 git que oferece fontes mais atualizadas. Aviso Criando e usando um kernel personalizado tornará muito difícil obter suporte para seu sistema. Embora seja uma experiência de aprendizado para compilar o seu próprio kernel, você não terá permissão para arquivar bugs no kernel custom-built (se você fizer isso, eles serão Rejeitados sem explicação adicional). Nota: Esta página necessitaria de limpeza significativa. Você pode querer consultar a página do KernelBuildYourOwnKernel no wiki do Ubuntu, em vez disso, que é um guia mais limpo e mais atualizado para o edifício (simples) do kernel Se você tiver um contrato de suporte comercial com o UbuntuCanonical, isso anulará esse suporte. Observe também que esta página descreve como fazer as coisas para o kernel Edgy (2.6.17) e mais recente. Até esta fonte do kernel, não tínhamos mecanismos no lugar que permitissem às pessoas construir seus próprios kernels facilmente. Isso foi intencional. Esta página NÃO descreve como construir kernels upstream do kernel. org. Isto é como reconstruir o kernel real do Ubuntu a partir da fonte. Razões para compilar um kernel personalizado Você é um desenvolvedor do kernel. Você precisa do kernel compilado de uma maneira especial, que o kernel oficial não é compilado em (por exemplo, com algum recurso experimental habilitado). Você está tentando depurar um problema no kernel Ubuntu de estoque para o qual você arquivou ou irá arquivar um relatório de bug. Você tem hardware que o kernel Ubuntu não suporta. Você ama computadores e está curioso e interessado em cortar em seu próprio sistema de GNULinux para aprender mais sobre como trabalha (com a compreensão que você necessitará reparar qualquer coisa que você quebra). Razões para NÃO compilar um kernel personalizado Você só precisa compilar um driver especial. Para isso, você só precisa instalar os pacotes linux-headers. Você não tem idéia do que está fazendo, e se quebrar algo, você precisará de ajuda para corrigi-lo. Dependendo do que você faz de errado, você pode acabar tendo que reinstalar o seu sistema a partir do zero. Você chegou a esta página por engano, e check-out porque parecia interessante, mas você realmente não quer aprender muito sobre os kernels. Se você deseja instalar um novo kernel sem compilação, você pode usar o Synaptic. Procure linux-image e selecione a versão do kernel que deseja instalar. Uma maneira mais fácil é clicar em System gt Administration gt Update Manager. Em seguida, clique no botão Verificar e, finalmente, clique em Aplicar todas as atualizações, incluindo o kernel. Ferramentas que você precisa Para começar, você precisará instalar alguns pacotes. Use uma linha de comando a seguir para instalar com precisão os pacotes necessários para a versão que você está usando: Nota: O pacote makedumpfile não está disponível no Hardy. Obter a fonte do kernel Existem algumas maneiras de obter a origem do kernel do Ubuntu: Opção A) Use git Use git - Isto é para usuários que sempre querem ficar em sincronia com a mais recente fonte do kernel do Ubuntu. Para obter informações, instruções detalhadas podem ser encontradas no Guia do Kernel Git O repositório git não inclui os arquivos de controle necessários, portanto você deve construí-los por: Opção B) Baixar o arquivo de origem Baixar o arquivo de origem - Isto é para usuários que Quer reconstruir os pacotes padrão do Ubuntu com patches adicionais. Observe que isso quase sempre estará desatualizado em comparação com a fonte de desenvolvimento mais recente; portanto, você deve usar git (opção A) se precisar dos patches mais recentes. Use um comando follow para instalar as dependências de compilação e extrair a fonte (para o diretório atual): Fonte de módulos Ubuntu também pode ser necessária se você planeja habilitar PAE e 64 GiB suporte no kernel para 32 bits Hardy (8.04). Os módulos fornecidos pelo Ubuntu podem não ser compatíveis com um kernel habilitado para PAE. A fonte será baixada para um subdiretório dentro do diretório atual. Ubuntu Karmic Koala (9.10) e versões mais recentes A fonte será baixada para o diretório atual como um trio de arquivos (para Lucid, pelo menos) (.orig. tar. gz. diff. gz. E. dsc) e um sub - diretório. Por exemplo, se uname - r retorna 2.6.32-25-genérico. Youll obter linux2.6.32.orig. tar. gz. Linux2.6.32-25.44.diff. gz. Linux2.6.32-25.44.dsc eo sub-diretório linux-2.6.32. Opção C) Baixe o pacote de origem Baixe o pacote de origem (as instruções detalhadas estão mais abaixo nesta página em Alternate Build Method (B): The Old-Fashioned Debian Way) - Isto é para usuários que simplesmente querem modificar ou brincar com, O Ubuntu-remendado kernel fonte. Novamente, este não será o mais atualizado (use Option Agit se você precisar da fonte mais recente). Lembre-se de que este NÃO é o mesmo que a opção BDownload do arquivo de origem. Modifique a fonte para suas necessidades Para a maioria das pessoas, basta modificar os configs. Se você precisar instalar um patch, leia as instruções do provedor do patch para saber como aplicá-lo. As configurações de Ubuntu de ações estão localizadas em debianconfigARCH onde ARCH é a arquitetura que você está construindo para (Começando com Jaunty este é debian. masterconfigARCH). Neste diretório existem vários arquivos. O arquivo de configuração é a base para todos os destinos nessa arquitetura. Em seguida, existem vários arquivos config. FLAVOUR que contêm opções específicas para esse destino. Por exemplo, aqui estão os arquivos para 2.6.20, i386: Se você não encontrar os arquivos de configuração debianconfig. Você pode encontrá-los em seu diretório de inicialização (por exemplo, bootconfig-2.6.22-14-genérico) caso contrário você deve verificar se um local alternativo foi especificado no debiandebian. env do diretório de origem do kernel. Se você precisar alterar uma opção de configuração, basta modificar o arquivo que contém a opção. Se você modificar apenas o arquivo de configuração, ele afetará todos os destinos dessa arquitetura. Se você modificar um dos arquivos de destino, ele somente afetará esse destino. Depois de aplicar um patch, ou ajustar as configs, é sempre melhor para regenerar os arquivos de configuração para garantir que eles são consistentes. Há um comando auxiliar para isso. Para regenerar todas as arquiteturas executadas: Se você quiser apenas atualizar uma arquitetura. Run: Nota: Se você não tem o diretório debian depois de usar o apt-get source. Use dpkg-source - x dsc para extrair as fontes corretamente. Para que esses dois comandos funcionem, você precisa dar os scripts nos diretórios debianscriptsmisc e debianscripts para executar a permissão com o seguinte comando: Build the Kernel (s) Existem duas maneiras listadas de construir o kernel do Ubuntu: Build Method A: Build the kernel (Quando a fonte é do repositório git, ou da fonte apt-get) Para construir o kernel (s) é muito simples. Dependendo de suas necessidades, você pode querer construir todos os destinos do kernel, ou apenas um específico para o seu sistema. No entanto, você também quer certificar-se de que você não choque com os kernels de ações. Nota: Embora estas instruções externas incluam fazer um ramo separado e exclusivo do kernel, ao contrário aqui, eles incluem explicações completas de todas as etapas necessárias do início ao fim. Estas instruções são específicas para o git-tree e para a fonte baixada via apt-get source. Não ao baixar o pacote linux-source de kernel. org Use este comando para construir todos os destinos para a arquitetura que você está construindo: debianrules clean cria debiancontrol. Debianchangelog. E assim por diante do debian. ltbranchnamegt (por exemplo, debian. master). É necessário em árvores git após git commit 3ebd3729ce35b784056239131408b9a72b0288ef UBUNTU: Config Resumo do diretório debian. A variável de ambiente AUTOBUILD aciona recursos especiais na compilação do kernel. Primeiro, ele ignora verificações ABI normais (ABI é a compatibilidade binária). Ele pode fazer isso porque ele também cria um único ID ABI. Se você usou um repositório git, este ID exclusivo é gerado a partir do git HEAD SHA. Se não, ele é gerado a partir do programa uuidgen (o que significa que cada vez que você executar a compilação debianrules, o UUID será diferente). Os seus pacotes serão nomeados utilizando esta ID. (Observe que no Intrepid e mais recente, você precisará skipabitrue para ignorar verificações ABI.) Para criar um destino específico. Use este comando: Onde FLAVOR é um dos principais sabores do kernel (por exemplo, genérico) Para construir um dos sabores personalizados (encontrados em debianbinary-custom. d), use: A partir desta documentação, sabores personalizados incluem xen e rt. Se você tiver mais de um processador ou mais de um núcleo, você pode acelerar as coisas executando comandos de compilação simultâneos. Prepend CONCURRENCYLEVEL2 para dois processadores ou dois núcleos substituir 2 com qualquer número que se adapte a sua configuração de hardware (para Gutsy e mais tarde, você pode alternativamente usar DEBBUILDOPTIONSparallel2). Se você obtiver erros ABI, você pode evitar a verificação ABI com skipabitrue. Por exemplo, Para acionar uma reconstrução, remova o arquivo de carimbo apropriado de debianstamps (por exemplo, stamp-build-server para o sabor do servidor, etc.). Os debs são colocados no seu diretório pai do diretório de origem do kernel. Se necessário, a fonte de módulos Ubuntu para Hardy (8.04) pode ser construída de forma semelhante. Como alternativa, se você precisar especificar um kernel diferente do executado, use Se você receber um erro, tente executar este no kerneldir. O novo sistema de criação do Ubuntu é ótimo para desenvolvedores, para pessoas que precisam do mais recente kernel de borda sangrenta, e as pessoas que precisam construir um ambiente diversificado Conjunto de grãos (vários sabores). No entanto, pode ser um pouco complexo para usuários comuns. Se você não precisa das fontes de desenvolvimento mais recentes, existe uma maneira mais simples de compilar seu kernel a partir do pacote linux-source. Como sugerido acima, tudo o que você precisa para isso é: O último comando na seqüência leva você para o diretório superior de uma árvore de origem do kernel. Antes de construir o kernel, você deve configurá-lo. Se você deseja reutilizar a configuração do kernel atualmente em execução, comece com Antes de executar make menuconfig ou make xconfig (que é o que o próximo passo diz que você faça), certifique-se de ter os pacotes necessários: Se você quiser Como para ver o que é diferente entre a sua configuração original do kernel e o novo (e decidir se você quer qualquer um dos novos recursos), você pode executar: Desde o kernel 2.6.32, um novo recurso permite que você atualize a configuração para apenas Compile módulos que são realmente utilizados em seu sistema: Em seguida, independentemente de você está re-usando uma configuração existente ou a partir do zero: E quanto a isso. (Que é da página KernelBuildYourOwnKernel na seção Modificando a configuração) Se você reutilizou a configuração existente, note que os kernels do Ubuntu compõem com informações de depuração, o que torna os módulos do kernel resultantes (arquivos. ko) muito maiores do que de outra forma estar. Para desativar isso, vá para o configs Kernel hackinglt -, em seguida, sob depuração Kernel, - gt e desativar Compilar o kernel com informações de depuração. Agora você pode compilar o kernel e criar os pacotes: Você pode habilitar o uso paralelo make make - j). Tente 1 número de núcleos de processador. por exemplo. 3 se você tiver um processador dual core: Em um kernel mais recente, se você só precisa de pacotes binários e deseja que várias compilações (ao editar a fonte) não façam com que tudo seja reconstruído, use: Os pacotes. deb serão criados no pai No diretório de origem do Linux (neste exemplo, eles seriam colocados em src porque o nosso diretório de origem do Linux é Instalar o novo kernel Se você quiser ver a tela de abertura do Ubuntu (ou usar o modo de texto) antes de chegar ao X em vez de apenas Uma tela preta, você quer certificar-se de que o driver do framebuffer carrega: Agora que você disse ao initramfs-tools quais módulos ele deve incluir, e uma vez que a compilação esteja completa, você pode instalar o debs gerado usando o dpkg. Ubuntu para o Hardy (8.04) anterior, instale-os da seguinte forma: Se você usar módulos de linux-restricted-modules, você precisará recompilar isso contra o seu novo pacote linux-headers Nota: Em resposta aos vários comentários no restante Desta seção: On Ub Untu Precise (12.04) parece que postinst faz cuidar do material initramfs. Depois de instalar o pacote meu novo kernel inicializado muito bem sem seguir qualquer um dos métodos abaixo. Alguém por favor me corrija se eu me engano. Desde Ubuntu Lucid (10.04) a imagem postinst já não executa os comandos de criação do initramfs. Em vez disso, existem scripts de exemplo fornecidos que irão executar a tarefa. Esses scripts funcionarão também para imagens oficiais do kernel. Por exemplo: Nota: Eu não poderia obter os scripts acima para ajudar na geração de um initrd para o kernel - e assim o kernel construído couldnt boot a única coisa que trabalhou para mim foi a recomendação em debian-administration. orgarticleHowDoIMakeaninitrdimage. Use o comando initramfs. É solução real. O que eu usei (depois que os kernels customizados. debs foram instalados), era: Note (Michael): isso é porque você precisa incluir os scripts do pacote certo para construir o initrd no momento da instalação do pacote. A opção make-kpkg é --overlay-dir. Por padrão, o make-kpkg usa usrsharekernel-package como um diretório de sobreposição, que contém os scripts padrão, não personalizados para uma distribuição Debian, e não os necessários para a construção de um kernel do Ubuntu. Primeiro copie o diretório de sobreposição padrão para o seu diretório pessoal: Em seguida, instale a origem do kernel que você está usando atualmente, usando o nome exato do pacote, ex. Que descompactará as fontes para HOMElinux-2.6.32. Agora copie os scripts de controle em sua nova sobreposição: E agora você pode executar make-kpkg com a opção de linha de comando adicional --overlay-dirHOMEkernel-package. Rebuilding linux-restricted-modules O pacote linux-restricted-modules (lrm) contém um número de drivers não-DFSG-free (assim como alguns firmware eo daemon de rede sem fio ipw3945) que, em um mundo perfeito, não teriam que ser Embalados separadamente, mas que infelizmente não estão disponíveis sob uma licença compatível com GPL. Se você usar qualquer um do hardware suportado pelo pacote l-r-m, você provavelmente encontrará que seu sistema não funciona tão bem depois de mudar para um kernel personalizado. Neste caso, você deve tentar compilar o pacote l-r-m. Consulte CustomRestrictedModules sobre como reconstruir l-r-m (se você usar nVidia ou ATI drivers binários, você faz). Nota: você precisará de cerca de 8 horas de tempo de compilação e cerca de 10 Gb de espaço no disco rígido para compilar todos os sabores do kernel e módulos restritos. Nota adicional: Não há pacotes l-r-m ou linux-restricted-modules em Lucid. Acelerando a Build Use distcc e, se você está reconstruindo muitas vezes, ccache. Uma boa visão geral do uso de distcc em um sistema baseado em debian está disponível em myrddin. orghowtousing-distcc-com-debian. Se você tiver máquinas AMD64 disponíveis em sua rede de área local, eles ainda podem participar na construção de código de 32 bits distcc parece lidar com isso automaticamente. No entanto, com distcc assumir todas as compilações por padrão, você precisará definir HOSTCC para que quando kernel constrói deseja usar o compilador no próprio host, eles não acabam distribuindo trabalhos para o servidor de 64 bits. Se você não fizer isso, você obterá falhas de compatibilidade de link entre código de 64 bits e 32 bits. Meu comando make-kpkg, com usrlibccache na cabeça do meu PATH. Se como: Mais documentação Por favor, vá para a página wiki da comunidade para comentários, perguntas e discussão: wiki. ubuntuKernelCustomBuildCreating 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. Abrange a criação de um PKGBUILD 8211 um arquivo de descrição de compilação de pacotes obtido por makepkg para criar um pacote binário de origem. Se já estiver na posse de um PKGBUILD. Consulte makepkg. Para obter instruções sobre as regras existentes e formas de melhorar a qualidade do pacote, consulte os padrões de empacotamento do Arch. Os pacotes no Arch Linux são construídos usando o utilitário makepkg e as informações armazenadas em um arquivo PKGBUILD. Quando makepkg é executado, ele procura por 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 installupgraderemove. (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. Isso 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 os membros do grupo que deseja instalar, mas não pode 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 você não pode 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. Faz o download dos arquivos 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 passos necessários para compilar 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 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. After successful completion, the resulting binaries and metadata of the package, i. e. package version and dependencies, are packed in a pkgname. pkg. tar. xz package file that can be installed with pacman - U ltpackage filegt . To begin with a new package, you should first create an empty working directory, (preferably abs pkgname ), change into that directory, and create a PKGBUILD file. You can either copy the prototype PKGBUILD usrsharepacmanPKGBUILD. proto to your working directory or copy a PKGBUILD from a similar package. The latter may be useful if you only need to change a few options. Warning: Use only the PKGBUILD prototypes provided in the pacman package (PKGBUILD-split. proto, PKGBUILD-vcs. proto and PKGBUILD. proto). The prototypes files in the abs package and in the ABS git repository are significantly out of date and should not be used. See FS34485 . Defining PKGBUILD variables Example PKGBUILDs are located in usrsharepacman. An explanation of possible PKGBUILD variables can be found in the PKGBUILD article. makepkg defines two variables that you should use as part of the build and install process: srcdir This points to the directory where makepkg extracts or symlinks all files in the source array. pkgdir This points to the directory where makepkg bundles the installed package, which becomes the root directory of your built package. All of them contain absolute paths, which means, you do not have to worry about your working directory if you use these variables properly. Note: makepkg . and thus the build() and package() functions, are intended to be non-interactive. Interactive utilities or scripts called in those functions may break makepkg . particularly if it is invoked with build-logging enabled ( - L ). (See FS13214 .) Note: Apart from the current package Maintainer, there may be previous maintainers listed above as Contributors. PKGBUILD functions There are five functions, listed here in the order they are executed if all of them exist. If one does not exist, it is simply skipped. Note: This does not apply to the package() function, as it is required in every PKGBUILD This function, commands that are used to prepare sources for building are run, such as patching. This function runs right after package extraction, before pkgver() and the build function. If extraction is skipped ( makepkg - e ), then prepare() is not run. Note: (From man PKGBUILD ) The function is run in bash - e mode, meaning any command that exits with a non-zero status will cause the function to exit. pkgver() runs after the sources are fetched, extracted and prepare() executed. So you can update the pkgver variable during a makepkg stage. This is particularly useful if you are making gitsvnhgetc. packages. where the build process may remain the same, but the source could be updated every day, even every hour. The old way of doing this was to put the date into the pkgver field which, if the software was not updated, makepkg would still rebuild it thinking the version had changed. Some useful commands for this are git describe. hg identify - ni. etc. Please test these before submitting a PKGBUILD, as a failure in the pkgver() function can stop a build in its tracks. Note: pkgver cannot contain spaces or hyphens ( - ). Using sed to correct this is common. Now you need to implement the build() function in the PKGBUILD file. This function uses common shell commands in Bash syntax to automatically compile software and create a pkg directory to install the software to. This allows makepkg to package files without having to sift through your file system. The first step in the build() function is to change into the directory created by uncompressing the source tarball. makepkg will change the current directory to srcdir before executing the build() function. Therefore, in most cases, like suggested in usrsharepacmanPKGBUILD. proto. the first command will look like this: Now, you need to list the same commands you used when you manually compiled the software. The build() function in essence automates everything you did by hand and compiles the software in the fakeroot build environment. If the software you are packaging uses a configure script, it is good practice to use --prefixusr when building packages for pacman. A lot of software installs files relative to the usrlocal directory, which should only be done if you are manually building from source. All Arch Linux packages should use the usr directory. As seen in the usrsharepacmanPKGBUILD. proto file, the next two lines often look like this: Note: If your software does not need to build anything, DO NOT use the build() function. The build() function is not required, but the package() function is. Place for calls to make check and similar testing routines. It is highly recommended to have check() as it helps to make sure software has been built correctly and works fine with its dependencies. Users who do not need it (and occasionally maintainers who can not fix a package for this to pass) can disable it using BUILDENV(check) in PKGBUILDmakepkg. conf or call makepkg with --nocheck flag. The final step is to put the compiled files in a directory where makepkg can retrieve them to create a package. This by default is the pkg directorya simple fakeroot environment. The pkg directory replicates the hierarchy of the root file system of the softwares installation paths. If you have to manually place files under the root of your filesystem, you should install them in the pkg directory under the same directory structure. For example, if you want to install a file to usrbin. it should instead be placed under pkgdirusrbin. Very few install procedures require the user to copy dozens of files manually. Instead, for most software, calling make install will do so. The final line should look like the following in order to correctly install the software in the pkg directory: Note: It is sometimes the case where DESTDIR is not used in the Makefile you may need to use prefix instead. If the package is built with autoconf automake . use DESTDIR this is what is documented in the manuals. If DESTDIR does not work, try building with make prefixpkgdirusr install. If that does not work, you will have to look further into the install commands that are executed by make lt. gt install . In some odd cases, the software expects to be run from a single directory. In such cases, it is wise to simply copy these to pkgdiropt. More often than not, the installation process of the software will create sub-directories below the pkg directory. If it does not, however, makepkg will generate a lot of errors and you will need to manually create sub-directories by adding the appropriate mkdir - p commands in the build() function before the installation procedure is run. In old packages, there was no package() function. So, files were put into the pkg directory at the end of the build() function. If package() is not present, build() runs via fakeroot . In new packages, package() is required and runs via fakeroot instead, and build() runs without any special privileges. makepkg --repackage runs only the package() function, so it creates a. pkg. file without compiling the package. This may save time e. g. if you just have changed the depends variable of the package. Note: The package() function is the only required function in a PKGBUILD. If you must only copy files into their respective directories to install a program, do not put it in the build() function, put that in the package() function. Note: Creating symlinks is a slightly awkward process in the package() function. Using the naive approach ln - s fromfoo togoo will result in a broken symlink to the build directory. The way to create a proper link is to create it pointing to an initially-broken source, ln - s fromfoo togoo. Once the package is installed, the link will point to the right place. Testing the PKGBUILD and package As you are writing the build() function, you will want to test your changes frequently to ensure there are no bugs. You can do this using the makepkg command in the directory containing the PKGBUILD file. With a properly formatted PKGBUILD. makepkg will create a package with a broken or unfinished PKGBUILD. it will raise an error. If makepkg finishes successfully, it will place a file named pkgname-pkgver. pkg. tar. xz in your working directory. This package can be installed with the pacman - U command. However, just because a package file was built does not imply that it is fully functional. It might conceivably contain only the directory and no files whatsoever if, for example, a prefix was specified improperly. You can use pacmans query functions to display a list of files contained in the package and the dependencies it requires with pacman - Qlp package file and pacman - Qip package file respectively. If the package looks sane, then you are done However, if you plan on releasing the PKGBUILD file, it is imperative that you check and double-check the contents of the depends array. Also ensure that the package binaries actually run flawlessly It is annoying to release a package that contains all necessary files, but crashes because of some obscure configuration option that does not quite work well with the rest of the system. If you are only going to compile packages for your own system, though, you do not need to worry too much about this quality assurance step, as you are the only person suffering from mistakes, after all. Checking package sanity After testing package functionality check it for errors using namcap. Check PKGBUILD contents for common errors and package file hierarchy for unnecessarymisplaced files Scan all ELF files in package using ldd. automatically reporting which packages with required shared libraries are missing from depends and which can be omitted as transitive dependencies Heuristically search for missing and redundant dependencies and much more. Get into the habit of checking your packages with namcap to avoid having to fix the simplest mistakes after package submission. Submitting packages to the AUR Please read AUR User GuidelinesSubmitting packages for a detailed description of the submission process. Download the source tarball of the software you want to package. Try compiling the package and installing it into an arbitrary directory. Copy over the prototype usrsharepacmanPKGBUILD. proto and rename it to PKGBUILD in a temporary working directory -- preferably abs . Edit the PKGBUILD according to the needs of your package. Run makepkg and see whether the resulting package is built correctly. If not, repeat the last two steps. Before you can automate the package building process, you should have done it manually at least once unless you know exactly what you are doing in advance . in which case you would not be reading this in the first place. Unfortunately, although a good bunch of program authors stick to the 3-step build cycle of. configure make make install , this is not always the case, and things can get real ugly if you have to apply patches to make everything work at all. Rule of thumb: If you cannot get the program to compile from the source tarball, and make it install itself to a defined, temporary subdirectory, you do not even need to try packaging it. There is not any magic pixie dust in makepkg that makes source problems go away. 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