MOTU Q&A session

Getting Started

The key thing about packages in ubuntu and debian is that we both deal with the source
package and what users install are binary packages.

We only do source changes and only do source uploads to the build daemons, which
(hopefully, if we do everything alright) turn our source packages into binary packages.

Getting a random source package to play with

 apt-get source xicc

look at the output of

less xicc-0.2/debian/control

gives

Source: xicc
Section: x11
Priority: optional
Maintainer: Ross Burton 
Build-Depends: debhelper (>=4.1.16), cdbs, libxt-dev, libglib2.0-dev
Standards-Version: 3.6.2

Package: xicc
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: set the ICC colour profile for an X display
 This utility lets you set an ICC colour profile for an X display, so that
 applications can use it to display colour calibrated images.  Applications have
 to specifically look for this atom but several applications such as Gimp and
 Eye Of Gnome already do.

There are two sections:
the first deals with the source package and specifies things like build-depends (the packages that are needed to build the package)
the second section deals with binary packages - in this case it's simple: one source package called xicc, one binary package called xicc.
Notice one field called 'Architecture:' it says 'any' which means: please build this source package on any architecture in the data center which includes i386, amd64, powerpc, lpia, hppa and so on.

this is only necessary for packages that use architecture dependant code, like C code or C++ code.
in the case of python package (which just contains python code that is interpreted), you'd change 'any' to 'all' which means it's only built on one build daemon, but will be installable on all architectures, because it's the same binary package anywhere.

For Ubuntu Mobile enter lpia in this field.

 ${shlibs:Depends}

is a variable that will be substituted with all the library packages the binary files in the binary package link to.
For example,

apt-cache show xicc

lists the following:

 libc6 (>= 2.3.4-1), libglib2.0-0 (>= 2.8.0), libice6, libsm6, libx11-6

because that's the libaries the binary in the package links to.

In depth analysis of 'the libraries the binary in the package links to'

        aptitude download xicc
        dpkg -x xicc_0.2-2_i386.deb test
        ldd test/usr/bin/xicc

lists all the binaries that the that the built xicc binary links to

{misc:Depends}

will be expanded by the packaging tools that run during the build process for example dh_gconf (in the debhelper package) will notice if you have gconf schema files in the package and automatically add a postinst script that will rebuild the gconf database after the installation on a machine. also, it will add gconf as a dependency to ${misc:Depends}

Another variable often used (but not in the example above) is

${source:Version}

For this check out pidgin:

apt-cache showsrc pidgin | head -n 3

pidgin is split up into 10 binary packages so if somebody installs pidgin, you want to make sure that the installed version of pidgin-data is the same else you can't rely on all the images and sound files being at the right place and so on
This is why in pidgin's Depends you write something like

Depends: pidgin-data (= ${Source:Version}), ...

which will be automatically replaced with the current source version of that upload

More Resources

Patching Workshop
Basic Packaging
Merging