BR Indice(depth=2 align=right)

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 su distribuzioni basate su Debian, siete pregati 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. [http://www.willnichols.me.uk/progs/debpack/ Qui è possibile trovare una breve introduzione ai pacchetti Debian (in inglese).]

Anchor(Prerequisiti)

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.This guide assumes that the reader has a reasonable knowledge of building and installing software from source on Linux distributions. Inoltre, in questa guida si usa sempre l'interfaccia a linea di comando (CLI), quindi è necessaria una certa domistichezza nell'uso del Terminale. È quindi necessario saper eseguire, perlomeno, i seguenti comandi: BR

• 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 [http://www.gnu.org/software/make/manual/make.html GNU] (in inglese).

Getting Started

Binary and Source Packages

Most users of a Debian-based distribution such as Ubuntu will never have to deal with the actual source code that is used to create all of the applications on their computers. Instead, the source code is compiled into binary packages from the source package that contains both the source code itself and the rules for making the binary package. Package maintainers upload the source packages with their changes to the build systems that then compile the binary packages for each architecture. A separate system distributes the generated binary .deb files and source changes to the repository mirrors.

Packaging Tools

For convenience, here's an apt-get command to install all of them:

sudo apt-get install build-essential devscripts ubuntu-dev-tools debhelper dh-make diff patch cdbs quilt gnupg fakeroot lintian pbuilder

The Personal Builder: pbuilder

Basic Packaging

We will go through two examples with the common build systems. We will use debhelper, the most common build system in Debian. It helps the packager by automating repetitive tasks. Then we will briefly cover the Common Debian Build System (CDBS), a more streamlined build system that uses debhelper.

Packaging from Scratch

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 queue and has to be reviewed by an Ubuntu archive team member.

Packaging

• Most importantly: see copyright and licensing information 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 NEW Reject FAQ 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

CategoryHomepage CategoryInTraduzione