C'è un modo semplice per patchare automaticamente le fonti Ubuntu non appena diventano disponibili e caricarle su un PPA?

Sto cercando uno strumento per fare quanto segue:

• Rileva automaticamente gli aggiornamenti di un set di pacchetti sorgente (in particolare gtk + 2 e gtk + 3)
• scarica il pacchetto sorgente
• applica le mie patch personalizzate al sorgente
• impegnare correttamente la patch ( dpkg-source --commit [something-or-other]?)
• in caso di successo caricarli su un PPA su Launchpad (a cui posso quindi indirizzare il mio sistema nel solito modo).

Launchpad può fare tutto questo per me?

In caso contrario, esiste uno strumento che eseguirà automaticamente tutto ciò da un processo cron?

In mancanza di quanto sopra, metterò insieme qualcosa da solo, ma quali comandi sono necessari per:

• rilevare e scaricare gli aggiornamenti del pacchetto sorgente? (Preferirei qualcosa di simile a (bzr | git) pull piuttosto che dover apt-get source una copia nuova ogni volta)
• esegue il commit automatico della patch localmente (utilizzerei sempre la stessa descrizione del commit)?
• caricare le fonti in modo non interattivo su un PPA?

Ho trovato una domanda ( qual è il modo corretto di patchare Wine per un PPA personalizzato? ), Che è simile ma i passaggi nella risposta sono ancora sostanzialmente manuali e interattivi. Una versione completamente manuale di questo, oltre al rilevamento automatico degli aggiornamenti delle fonti, sarebbe di grande aiuto.

Bene, sembra che le ricette di confezionamento siano la strada da percorrere qui. Fondamentalmente, le ricette di packaging possono creare automaticamente pacchetti sorgente Ubuntu e caricarli su un PPA ogni volta che cambia un ramo bzr su Launchpad. La documentazione online è abbastanza buona, ma darò un paio di esempi ...

Innanzitutto, si specifica un ramo da tracciare (ad esempio lp:gtk3) e quindi si aggiunge un comando per nidificare il proprio ramo di packaging Debian in quel ramo. Dai un'occhiata a questa ricetta che ho creato per le build quotidiane di 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

Questa ricetta crea un pacchetto Ubuntu ogni giorno usando l'ultima fonte upstream per Inkscape, ma copia le istruzioni di packaging Debian personalizzate dal lp:~inkscape.dev/inkscape/debian-packagingramo in una sottocartella chiamata " debian".

La pagina delle ricette di packaging su Launchpad ti consente di specificare su quale PPA caricare automaticamente i tuoi pacchetti. Nel nostro caso, è caricato qui .

Come approccio alternativo, potresti basare la tua ricetta su un pacchetto Ubuntu esistente piuttosto che direttamente sulla sorgente upstream. Ad esempio lp:ubuntu/gtk+3.0,. Dovresti quindi creare un ramo di questo codice e eseguire tutte le modifiche necessarie. Chiamiamolo lp:~myaccount/ubuntu/saucy/gtk+3.0/my-custom-build, per esempio. Dovresti quindi creare una ricetta per unire automaticamente le modifiche anziché annidare le istruzioni di imballaggio. La ricetta sarebbe simile a:

# 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

Questa ricetta, quindi, crea automaticamente un pacchetto sorgente Ubuntu personalizzato e lo carica sul tuo PPA ogni volta che c'è un cambiamento nel pacchetto Ubuntu ufficiale.

Se segui questo approccio di "unione", hai due opzioni per applicare le tue patch. O modificheresti semplicemente il codice sorgente upstream direttamente nel tuo ramo e lasceresti che bzr si occupi di unirlo, oppure potresti creare file patch all'interno della debian/cartella usando quilt. Ognuno ha i suoi vantaggi / svantaggi. Il primo approccio è un po 'più intelligente ... se una delle tue patch viene adottata dallo sviluppatore upstream, allora l'unione di solito funzionerà ancora e il pacchetto Ubuntu verrà compilato OK. Quest'ultimo approccio ti consente di gestire le tue patch usando l'approccio standard basato su Debian di mantenere il codice di packaging separato dal codice upstream ... tuttavia, se lo sviluppatore upstream adotta una delle tue patch, quilt non sarà in grado di applicare il (duplicato) patch e il pacchetto non verrà compilato.