titolo guida alla pacchettizzazione
Introduzione
Benvenuti nella guida alla pacchettizzazione di Ubuntu! Questa guida é dedicata a chiunque desideri creare e mantenere pacchetti Ubuntu e, anche se molti dei concetti espressi qui possono essere usati per creare pacchetti binari per scopi personali, é stata scritta per quelle persone che vogliono distribuire i propri pacchetti su larga scala. Benché questa guida sia specifica per Ubuntu, può risultare utile anche per altre distribuzioni basate su Debian.
Ci sono diversi motivi per imparare a pacchettizzare per Ubuntu: innanzitutto, costruire e correggere pacchetti è un ottimo modo per contribuire alla Comunità, inoltre è anche un buon metodo per conoscere e imparare il funzionamento di Ubuntu e delle applicazioni che si utilizzano. Può capitare che si voglia installare un pacchetto non presente negli archivi di Ubuntu: una volta letta questa guida, si avranno gli strumenti e le conoscenze necessarie per fare questo e molte altre cose.
Da dove iniziare
Se si è appena approdati alla pacchettizzazione in distribuzioni basate su Debian, vi preghiamo di leggere questa guida interamente, prestando particolare attenzione alle sezioni [FabioMarconi/Prove10#Prerequisiti Prerequisiti] e [PackagingGuide#Pacchettizzazione elementare Pacchettizzazione elementare]. Coloro che sono già esperti di pacchettizazione Debian, troveranno la sezione [../Ubuntu Pacchettizzazione in Ubuntu] molto utile. Qui è possibile trovare una breve introduzione ai pacchetti Debian (in inglese).
Prerequisiti
Questa guida da per scontato che il lettore abbia una ragionevole conoscenza della procedura di compilazione ed installazione di software da sorgente su distribuzioni Linux. Inoltre, in questa guida si usa sempre l'interfaccia a linea di comando (CLI), quindi è necessaria una certa familiarità nell'uso del Terminale. È necessario saper eseguire, perlomeno, i seguenti comandi:
Make: GNU Make è uno strumento molto importante per la compilazione di software. Esso viene utilizzato per trasformare una compilazione complessa in una forma più semplice. È importante sapere come usarlo, poichè la maggior parte delle informazioni inerenti il processo di pacchettizzazione saranno memorizzate in un Makefile. La documentazione inerente è reperibile sul sito web GNU (in inglese).
./configure: Questo script è incluso in quasi tutti i sorgenti Linux, specialmente per software scritti in linguaggi compilati tipo il C ed il C++. Viene usato per generare un Makefile (il file usato da make) il quale è opportunamente configurato per il sistema in uso. È usato dagli strumenti di pacchettizzazione standard Debian, per cui è importante sapere cosa compie lo script configure. Informazioni su ./configure possono essere trovate nella documentazione di make.
Apt/Dpkg: Oltre all'utilizzo come programmi d'installazione apt e dpkg hanno molte caratteristiche che li rendono utili per la pacchettizzazione:
apt-cache dump - elenca ogni pacchetto nella cache. Questo comando è particolarmente utile in combinazione con una pipe grep tipo apt-cache dump | grep foo per ricercare i pacchetti i cui nomi o dipendenze includono foo.
apt-cache policy - elenca i repository (main/restricted/universe/multiverse) in cui un pacchetto è presente.
apt-cache show - mostra informazioni riguardanti un pacchetto binario.
apt-cache showsrc - mostra informazioni riguardanti un pacchetto sorgente.
apt-cache rdepends - mostra le dipendenze inverse di un pacchetto (quali pacchetti richiedono la dipendenza cercata).
dpkg -S - elenca il pacchetto binario al quale un particolare file appartiene.
dpkg -l - elenca i pacchetti attualmente installati. È simile ad apt-cache dump ma riguarda i pacchetti installati.
dpkg -c - elenca i contenuti di un pacchetto binario. È utile per verificare che i file siano installati nell'esatto posto.
dpkg -f - mostra il file di controllo per un pacchetto binario. È utile per verificare che le dipendenze siano esatte.
grep-dctrl - ricerca particolari informazioni nei pacchetti. È uno specifico uso del pacchetto grep ma non è preinstallato.
diff e patch:
Il programma diff può essere usato per comparare due file e creare delle patch. Un tipico esempio potrebbe essere: diff -ruN file.old file.new > file.diff. Questo comando creerà un diff (ricorsivamente se sono usate delle directory) che mostra le differenze, o delta, tra i due file.
Il programma patch viene usato per applicare una patch (solitamente creata con diff o programmi similari) ad un file o directory. Per applicare la patch precedentemente creata, eseguire: patch -p0 < file.diff. L'opzione -p dice a patch quanto dovrebbe togliere dai percorsi per i nommi dei file nella patch. L'opzione -p0 indica non toglere nulla o lascia l'indirizzo integro.
Tutto ciò che riguarda il codice di Ubuntu, traduzioni, pacchetti, bug, liste di controllo accessi, informazioni sui gruppi, ecc., risiedono in Launchpad, quindi se si desidera contribuire ad una discussione su un bug, caricare pacchetti, contribuire allo sviluppo di codice e traduzioni, è necessario:
Per iniziare
Pacchetti sorgente e binari
Molti utenti di distribuzioni basate su Debian quale Ubuntu non avranno mai a che fare con il codice sorgente usato per la creazione di tutte le applicazioni installate nel computer.Invece, il codice sorgente è compilato in pacchetti binari derivati dal pacchetto sorgente il quale contiene sia il codice sorgente in se che le regole per fare il make del pacchetto binario. Il responsabile del pacchetto carica i pacchetti sorgenti con le loro variazioni sul sistema di assemblaggio che compilerà i pacchetti binari per ogni architettura. Un sistema separato distribuirà i file .deb generati e le variazioni al sorgente ai mirror dei repository.
Strumenti per la pacchettizzazione
Esistono molti strumenti scritti appositamente per la pacchettizzione in sistemi basati su Debian. Molti non sono essenziali alla creazione di pacchetti, ma risultano molto utili e spesso automatizzano compiti ripetitivi. I relativi manuali e pagine informative sono una buona risorsa di informazioni. Comunque la seguente è una lista di pacchetti che sono considerati necessari per iniziare la pacchettizzazione:
build-essential è un metapacchetto che dipende da libc6-dev, gcc, g++ e dpkg-dev. Un pacchetto con il quale è possibile non avere familiarità è dpkg-dev, il quale contiene strumenti come dpkg-buildpackage e dpkg-source che sono usati per creare, estrarre ed assemblare pacchetti sorgente e binari.
devscripts contiene molti script che semplificano il lavoro del creatore del pacchetto. Alcuni dei più utilizzati sono debdiff, dch, debuild e debsign.
Ubuntu-dev-tools è anch'esso una raccolta di script, ma specifici per Ubuntu. Contiene strumenti quali update-maintainer, dgetlp, what-patch, pbuilder-dist ecc..
debhelper sono script che eseguono comuni attività di pacchettizzazione.
dh-make può essere usato per creare un modello per la pacchettizzazione.
diff e patch sono usati rispettivamente per creare ed applicare patch. Vengono molto usati durante la pacchettizzazione perchè sono semplici, puliti, e più efficienti nella creazione di piccole variazioni, quali le aggiunte di patch, evitando così di avere copie multiple dello stesso file. Nota: in Ubuntu 10.04 il binario diff è fornito dal pacchetto diffutils. Il pacchetto diff è diventato un pacchetto fittizio di transizione.
cdbs acronimo di Common Debian Build System. Esso prevede (stando a quanto riportato nalla descrizione del pacchetto) un "sano insieme di regole predefinite su cui i pacchetti possono essere costruiti; se necessario, è possibile non tenere conto delle succitate regole".
quilt gestisce una serie di patch tenendo traccia dei cambiamenti che ognuna di esse comporta. Queste vengono logicamente organizzate come una catasta, ove è possibile applicarle, non applicarle, modificarle lavorando sulla catasta (push/pop). Questo pacchetto, completamente integrato in CDBS consente al creatore l'utilizzo di questo nuovo paradigma per i propri script di pacchetizzazione, beneficiando del comfort offerto da quilt per le modifiche dei diff a monte. Questo pacchetto fornisce anche alcuni supporti elemntari anche a coloro che non utilizzano CDBS.
gnupg è una completa e libera sostituzione di PGP usata per firmare digitalmente i file ed il pacchetto stesso.
fakeroot simula l'esecuzione di un comando con i permessi di root. È utile durante la creazione di pacchetti binari come utente normale.
lintian disseziona i pacchetti Debian e riporta bug o violazioni della Policy. Contiene controlli automatici di molti aspetti della Policy Debian come quelli per gli errori comuni.
pbuilder crea un sistema chroot e vi costruisce un pacchetto all'interno. È un sistema ideale da usare per verificare che un pacchetto abbia correttamente costruito le dipendenze e per costruire pacchetti puliti da testare e distribuire.
Per comodità, è di seguito riportato un comando apt-get per installare tutti i sopracitati pacchetti:
sudo apt-get install build-essential devscripts ubuntu-dev-tools debhelper dh-make diff patch cdbs quilt gnupg fakeroot lintian pbuilder
Il costruttore personale: pbuilder
L'utilizo di pbuilder come costruttore di pacchetti consente di costruire il pacchetto all'interno di un ambiente chroot. È possibile costruire pacchetti binari senza usare pbuilder ma bisogna innanzitutto avere tutte le dipendenze necesarie installate sul sistema. Comunque pbuilder consente al pacchettizzatore il controllo delle dipendenze costruite dato che i pacchetti vengono costruiti all'interno di un installazione Ubuntu minimale, e le dipendenze costruite vengono scaricate seguendo le linee guida del file debian-control. Per una guida maggiormente esplicativa delle funzionalità di pbuilder si veda la relativa pagina wiki (in inglese).
Una breve panoramica:
Per creare un ambiente pbuilder, eseguire:
sudo pbuilder create --distribution $(lsb_release -cs) \
--othermirror "deb http://archive.ubuntu.com/ubuntu $(lsb_release -cs) main restricted universe multiverse"Per costruire un pacchetto utilizzando pbuilder, eseguire:
sudo pbuilder build *.dsc
Per aggiornare un ambiente pbuilder, eseguire:
sudo pbuilder update
Utilizzare pbuilder-dist (contenuto in ubuntu-dev-tools) per avere configurazioni molto differenti di pbuilder relative ai rilasci di Ubuntu.
Pacchettizzazione base
I problemi principali che incontra chi è alle prime armi con la pacchettizzazione sono che esistono molteplici modi di pacchettizzare e vi è più di uno strumento per svolgere il lavoro.
Spesso lo sviluppo di pacchetti richiede l'instalazione di molti pacchetti (specialmente -dev contenenti header ed altri comuni file per lo sviluppo) che non fanno normalmente parte di una installazione Ubuntu Desktop. Se si vuole evitare di installare pacchetti extra, oppure si vuole sviluppare per un rilascio di Ubuntu diverso da quello in uso, l'uso di un ambiente chroot è altamente raccomandato. Una guida all'impostazione di un chroot può essere reperita sul wiki (in inglese).
Verranno analizzati due esempi con i comuni strumenti di generazione pacchetti. Verranno usati debhelper, il più diffuso sistema di costruzione in Debian, che tra le altre cose automatizza i compiti ripetitivi e verrà coperto brevemente il Common Debian Build Sistem (CDBS), un più razionalizzato strumento di generazione basato su debhelper.
La pacchettizzazione dall'inizio
Pacchetti necessari: build-essential, automake, gnupg, lintian, fakeroot, pbuilder, debhelper, dpatch e dh-make. In questa esercitazione verrà preso come esempio il programma GNU hello. L'archivio è scaricabile presso ftp.gnu.org. Per gli scopi di questo programma si userà la directory ~/hello.
mkdir ~/hello cd ~/hello wget http://ftp.gnu.org/gnu/hello/hello-2.4.tar.gz
Se si sta pacchettizzando un proprio software, oppure il software non è reperibile come file tar.gz è possibile crearlo dalla directory sorgente estratta con il seguente comando:
mkdir hello-2.4 tar czf hello-2.4.tar.gz hello-2.4
Per lo scopo di questo esempio si comparerà il pacchetto creato hello con l'equivalente già pacchettizzato nei repository Ubuntu (chiamato hello-debhelper). Per ora verrà piazzato nella directory Ubuntu per poterlo analizzare in seguito:
mkdir ubuntu cd ubuntu apt-get source hello-debhelper cd ..
changelog
control
copyright
rules
Building the Package Locally (Binary Only)
Building the Package (Source and Binary)
Requirements for New Ubuntu Packages
When a source package is uploaded to Ubuntu which does not yet exist in the archive, or builds a new binary package, it will be held in the NEW and has to be reviewed by an Ubuntu member.
Packaging
Most importantly: see copyright below.
- The source and binary packages should have a sane name: neither should they clutter the namespace (such as "editor") nor should they have an entirely nonsensical name (such as "new-stuff-manager").
debian/control and debian/rules should build packages with the right Architecture:, Build-Depends[-Indep]:, and rules target (binary-arch vs. binary-indep).
- Maintainer and init scripts should not excessively mess up the system.
A more comprehensive list of package checks is available from the Code Review page.
Other
The Debian lists some important special cases which mostly apply to Ubuntu as well.
Process documentation: UbuntuDevelopment/NewPackages
Packaging with CDBS
Advanced Packaging
Common Mistakes
dh_make Example Files
When you use dh_make to create the initial "debianisation", example files for various tasks are created in the debian/ directory. The templates have a .ex extension. If you want to use one, rename it to remove the extension. If you do not need it, remove it to keep the debian/ directory clean.
Abusing dh_installdirs .dirs Files
Many packages wrongly use dh_installdirs and .dirs files to create directories. 99% of those cases are not necessary, since dh_install and .install files will automatically take care of creating directories. You only need to use dh_installdirs if your package needs to ship empty nonstandard directories, e. g. /etc/mypackage/plugins.d/.
Changing the Original Tarball
Solutions
Tips
Copyright Information
Example 1: GPL
Example 2: GPL with different GPL derived files from a different author
General Advice
Combining the GPL with another license will always make the combined work either GPL or, if the licenses conflict, undistributable. A list of combinable licenses is available at http://www.gnu.org/licenses/license-list.html.
Usually you will need to list the different relevant licenses in debian/copyright. A good way to do this is to list files with a different license together with the license in question. Whether you actually need to list a given license depends on the stipulations of the licenses involved.
What you don't need to mention are licenses from libraries the package links against. They are accompanied by their own copyright file, and the package in question can never be installed without the linked library. Of course, there are exceptions that impose different restrictions, such as the OpenSSL License, which requires a disclaimer to be present in debian/copyright if one of its works is used (as in linked against) in a project. Such additional restrictions imply that the utilized library is incompatible with the GPL.
While most projects don't typically encounter legal issues, it's very simple to introduce these via inaccurate copyright files. There is a rule of thumb: better safe than sorry, so be verbose and include any item in doubt in debian/copyright.
Reference Packages
Patch Systems
General Tips
The easiest way
Patching Without a Patch System
Example 1.
Example 2.
So this way of patching the source, while technically fine, can become very complicated and unmanageable. To make patching easier and more straightforward, patch systems were developed. We will take a look at couple of the most popular ones.
CDBS with Simple Patchsys (Example Package: pmount)
Since the Ubuntu Edgy version of cdbs, cdbs-edit-patch also works for packages using tarball.mk, and it can edit patches which produce rejections.
dpatch
quilt (Example Package: xterm)
Patching Other People's Packages
The most important thing to keep in mind when patching packages maintained by other people is to keep the patch system (or lack thereof) that the maintainer has set up. This will ensure consistency and make the package maintainer more likely to accept your patch.
It is also a good idea to separate patches logically rather than creating one giant patch. If the upstream authors apply one of your changes but not another it is much easier to just drop a patch than edit a monolithic patch to update it.
KDE
Essential Packaging Bits
KDE Manpages
Supplementary Files
.desktop Files
Man Pages
Using POD
Recipes
Note: PackagingGuide/Recipes may offer some recipes not included below.
Updating an Ubuntu Package
Ingredients
Method
For Bonus Points...
Creating a Debdiff
Use Ubuntu Merge Proposals
Consult the Release Schedule
Traditional Process
Ingredients
Method
Creating and Using a debian/watch File
Ingredients
Method
Notes
Steps 3 and 5 (of the howto) can be combined by using additional parameters in the URL line of the watch file
version=3 http://sf.net/medit/mooedit-(.*).tar.bz2 debian uupdate
You may want to continue at MOTU/Contributing#head-b205c74e27fe15e79e10c9e7f14d3cdfb359d81d to create an interdiff for sponsorship.
Appendix
Additional Resources
Example files
List of Debhelper Tools
Go back to PackagingGuide.
CategoryPackagingGuide