Fluxo de trabalho com pacotes automáticos

Question

Eu tenho uma pasta ~/Packaging em que todos os meus pacotes públicos e privados estão. Por exemplo, na pasta Packaging/think-rotate , há as coisas típicas do Debian, da seguinte forma:

think-rotate-2.5.2/
think-rotate-2.5.2.orig/
think-rotate-2.6/
think-rotate-2.6.orig/
think-rotate_1.0.tar.gz
think-rotate_2.5.2-0ubuntu1.debian.tar.gz
think-rotate_2.5.2-0ubuntu1.dsc
think-rotate_2.5.2-0ubuntu1_source.build
think-rotate_2.5.2-0ubuntu1_source.changes
think-rotate_2.5.2.orig.tar.gz@
think-rotate_2.5.2.tar.gz
think-rotate_2.5.orig.tar.gz@
think-rotate_2.5.tar.gz
think-rotate_2.6-0ubuntu1_all.deb
think-rotate_2.6-0ubuntu1_amd64.build
think-rotate_2.6-0ubuntu1_amd64.changes
think-rotate_2.6-0ubuntu1.debian.tar.gz
think-rotate_2.6-0ubuntu1.dsc
think-rotate_2.6-0ubuntu1_source.build
think-rotate_2.6-0ubuntu1_source.changes
think-rotate_2.6-0ubuntu1_source.stable.upload
think-rotate_2.6.orig.tar.gz@
think-rotate_2.6.tar.gz

Eu tenho um script que passa pelos meus projetos e gera o mais recente .tar.gz do meu código-fonte. Então, no que diz respeito a essa questão, novos archives de tar aparecem no diretório de pacotes de vez em quando.

Como não desejo executar uupdate ../….tar.gz em todos os projetos manualmente, escrevi um Script Python 3 que cuida disso, executa debuild -S e dput para fazer o upload para o meu PPA do Launchpad e, em seguida, debuild para compilá-lo para minha máquina local.

O changelog Debian é apenas preenchido com a mensagem padrão “New upstream release”. Esses pacotes são mais para implantação local organizada do que para o público em geral.

O script também usa apt-cache show para verificar se a versão mais recente está instalada e, caso contrário, usa dpkg -i para instalar esse pacote.

Isso funciona um pouco, mas encontrei alguns problemas com a minha versão atual desse script:

• Quando eu atualizo minha máquina para uma nova versão do Ubuntu, ela não reconstrói tudo. Então, eu tenho muitos pacotes que não receberam atualizações do upstream, e a versão mais recente do meu PPA é quantal , não raring .

• Os pacotes são criados para amd64 no meu computador principal e geralmente não podem ser instalados no meu outro computador, que possui i686 . Alguns pacotes são all , então isso não faz mal. Mas eu precisaria reconstruir os pacotes any nessa máquina. O PPA do Launchpad cuida de construí-lo para cada arquitetura, mas meu script não carregou esse pacote para raring , consulte o primeiro problema.

Para resumir, o fluxo de trabalho deve conter todas essas etapas:

• Extraia o novo arquivo tar de origem e atualize o debian/changelog . ( uupdate )

• Se ainda não tiver sido enviado para o PPA, crie um pacote de origem e faça o upload para o PPA do Launchpad. Mas só faça isso, se este for um pacote público, não envie meus pacotes privados para o PPA. ( debuild -S e dput )

• Se o pacote precisar ser atualizado localmente, crie um pacote binário para a arquitetura atual e instale-o. ( debuild e debi ou dpgk -i )

• Verifique se a série está desatualizada, i. e. o upload mais recente foi para quantal e o sistema atual é executado em raring . Em caso afirmativo, reconstrua a fonte novamente e faça o upload para o PPA.

Antes de dizer que devo trabalhar em cada pacote manualmente, tenha em mente que tenho 43 pacotes por aí e gostaria de salvar o trabalho aqui.

Eu poderia trabalhar no meu script para contornar os problemas atuais, mas prefiro usar algo que já funciona em vez de usar o meu. Existe algum takechain ou fluxo de trabalho que os mantenedores usam para manter tantos pacotes atualizados em seus PPAs ou repositórios oficiais?

Atualização 2013-07-08: Eu agora trabalhei no script para lidar com os problemas também. Mas ainda estou interessado em uma solução canônica.

    

Answer 1

Eu mantenho alguns pacotes no trabalho, então deixe-me dar uma perspectiva pessoal sobre isso.

Todas as suas coisas devem ser construídas em um local central, para todas as distribuições e arquiteturas necessárias. Não carregue pacotes de origem e, em seguida, crie novamente localmente. Escolha seus pacotes "privados" do servidor de criação onde você hospeda tudo. Dessa forma, você pode manter seus repositórios privados em /etc/apt/sources.list com todos os outros (proteja com senha, se necessário).

Se o Launchpad não funcionar para você, configure seu próprio sistema de construção. Como você tem muitos pacotes (acima de 40), a configuração de um ambiente de criação adaptado às suas necessidades especiais será compensada mais cedo ou mais tarde.

Você precisará de uma máquina dedicada com acesso à rede para isso - em sua casa ou no trabalho ou em um servidor alugado em um datacenter.

Aqui estão duas opções:

1. Use o Jenkins CI e o script de criação para criar o pacote. Há Jenkins Debian Glue de Michael Prokop, que faz o trabalho e está bem documentado (acabei reescrevendo-o do zero, mas Pode funcionar para você). É 100% código shell, então esteja preparado para fazer alguns scripts Bash se você precisar ajustá-lo.
   Com isso, você poderá construir todos os seus pacotes para todas as combinações de dists e arcos que desejar. Jenkins é maravilhosamente flexível e estável em ROCK, e será bastante fácil de compartimentar seus repositórios (para consumo privado e público).

2. Use o Buildbot - isso será mais trabalho manual do que a opção 1, mas o Buildbot é um projeto em Python e, com base em sua pergunta, presumo que você se sentirá em casa configurando-o. O projeto i3 (gerenciador de janelas) tem uma excelente descrição de como eles configuraram o ambiente do Buildbot, usam isso como ponto de partida .

Eu também strongmente recomendo sbuild sobre pbuilder . Jenkins Debian Glue usa o pbuilder (uma das razões pelas quais acabei descartando-o).

Em qualquer caso, você precisará fazer algumas coisas que você não precisa, até agora, como configurar repositórios de pacotes (que podem ser bem penosos) e manter um servidor de compilação. No final das contas, valerá a pena, e você aprenderá muito.