Existe uma maneira fácil de corrigir automaticamente as fontes do ubuntu à medida que elas se tornam disponíveis e fazem o upload para um PPA?

Question

Estou procurando uma ferramenta para fazer o seguinte:

• Detectar automaticamente atualizações para um conjunto de pacotes de origem (especificamente gtk + 2 e gtk + 3)
• faça o download do pacote de origem
• aplicar meus próprios patches personalizados à fonte
• confirme o patch corretamente ( dpkg-source --commit [something-or-other] ?)
• se for bem sucedido, carregue-os para um PPA no Launchpad (para o qual posso apontar o meu sistema da forma habitual).

O Launchpad pode fazer tudo isso para mim?

Se não, existe uma ferramenta que fará automaticamente tudo isso a partir de um cron job?

Sem o que foi dito acima, eu mesmo vou bater alguma coisa junto, mas quais comandos eu preciso:

• detecta e faz o download das atualizações do pacote de origem? (Eu prefiro algo como (bzr | git) puxar ao invés de ter que apt-get fonte uma cópia nova a cada vez)
• auto-commit o patch localmente (eu usaria a mesma descrição de confirmação toda vez)?
• carrega as fontes de forma não interativa para um PPA?

Eu encontrei uma pergunta ( Qual é a maneira correta de corrigir o Wine para um PPA personalizado? ), que é semelhante, mas as etapas da resposta ainda são basicamente manuais e interativas. Uma versão completamente automatizada disso, além de detecção automática de atualizações de fontes, ajudaria muito.

    

Answer 1

Bem, parece que as receitas de embalagem são o caminho a seguir. Basicamente, as receitas de empacotamento podem criar automaticamente pacotes fonte do Ubuntu e enviá-los para um PPA sempre que uma ramificação bzr no Launchpad for alterada. A documentação on-line é muito boa, mas darei alguns exemplos ...

Primeiro, você especifica uma ramificação para rastrear (por exemplo, lp:gtk3 ) e depois adicione um comando para aninhar sua própria ramificação de pacotes Debian naquela ramificação. Dê uma olhada em esta receita que criei para compilações diárias do Inkscape.

# bzr-builder format 0.4 deb-version 1:0.48+devel+{revno}+{revno:packaging}
lp:inkscape
nest packaging lp:~inkscape.dev/inkscape/debian-packaging debian

Esta receita cria um pacote do Ubuntu a cada dia usando a fonte upstream mais recente para o Inkscape, mas copia instruções personalizadas de empacotamento do Debian a partir do lp:~inkscape.dev/inkscape/debian-packaging ramifica em uma subpasta chamada" debian ".

A página de receita de embalagem no Launchpad permite que você especifique qual PPA carregar automaticamente seus pacotes. No nosso caso, é enviado aqui .

Como uma abordagem alternativa, você poderia basear sua receita em um pacote Ubuntu existente, em vez de diretamente na fonte upstream. Por exemplo, lp:ubuntu/gtk+3.0 . Em seguida, você precisa criar uma ramificação desse código e confirmar as modificações necessárias. Vamos chamá-lo de lp:~myaccount/ubuntu/saucy/gtk+3.0/my-custom-build , por exemplo. Você criaria uma receita para mesclar automaticamente as alterações em vez de aninhar as instruções de empacotamento. A receita seria algo como:

# bzr-builder format 0.4 deb-version {debversion}+{date}
lp:ubuntu/gtk+3.0
merge my-custom-build lp:~myaccount/ubuntu/saucy/gtk+3.0/my-custom-build

Esta receita, portanto, cria automaticamente um pacote de código-fonte personalizado do Ubuntu e o carrega no seu PPA sempre que houver uma alteração no pacote oficial do Ubuntu.

Se você adotar essa abordagem de "mesclagem", terá duas opções para aplicar seus patches. Você pode simplesmente editar o código-fonte do upstream diretamente em seu branch e deixar que o bzr cuide de mesclá-lo, ou você pode criar arquivos de patch dentro da pasta debian/ usando o quilt. Cada um tem suas próprias vantagens / desvantagens. A primeira abordagem é um pouco mais inteligente ... se um de seus patches for adotado pelo desenvolvedor do upstream, a mesclagem normalmente ainda funcionará e o pacote do Ubuntu irá construir OK. A última abordagem permite lidar com seus patches usando a abordagem padrão baseada no Debian de manter o código de empacotamento separado do código upstream ... entretanto, se o desenvolvedor for adotar um de seus patches, o quilt não poderá aplicar o (duplicado) patch e o pacote falhará na construção.