Overview

Many helper tools for packaging
We'll have a look at svn-buildpackage, dh-make-perl, stdeb and equivs
The first helps you keeping your packaging files in SVN
dh-make-perl makes Debian packages from Perl modules
stdeb makes Debian packages from Python modules
equivs allows you to create small, "empty" packages

Keeping packaging files in SVN

Packaging files are like code
If you're serious about it, you should use a VCS
Also {cvs,darcs,arch,git,hg}-buildpackage
Work roughly the same
Easy enough to use (small learning curve)

Using `svn-buildpackage`

Create a first version of the package
Build the package normally with debuild

Once you have the .dsc, import it into SVN:

svn-inject -v -o whatever_1.0-1.dsc http://myserver/svn/debian/

Now you can checkout the debian directory and build the package:

svn-buildpackage -rfakeroot
svn-buildpackage -rfakeroot --svn-ignore-new    # Ignore local changes
svn-buildpackage -rfakeroot --svn-tag           # Final build: tag the repo
svn-buildpackage -rfakeroot --svn-tag-only      # Only tag, not build

You need the original tarball under ../tarballs/whatever_1.0.orig.tar.gz

Usual workflow

You typically have a directory for Debian packages

I like this layout:

packages/
|-- memcached
|   |-- build-area                                      # Final binary packages
|   |   `-- memcached-0.10.obsolete.0.698430759905936  # Also failed builds for inspection
|   |-- tarballs
|   `-- trunk
|       `-- debian
`-- mininotificator
    |-- build-area
    |-- tarballs
    `-- trunk
        `-- debian

Once it's in SVN, you hack on it and build using svn-buildpackage
Once you're ready to release the package, use --svn-tag
Tagging creates a new, fake changelog entry that you should commit

New upstream versions

When a new upstream version comes:
```
svn-upgrade whatever-1.1.tar.gz
  
```
It reapplies your changes to the new version (if any)
Also copies the new tarball to the appropriate location
Also creates a new changelog entry for the new upstream version

Packaging Perl modules

Creating Debian packages for Perl modules is usually always the same
Not hard, but boring and error-prone
dh-make-perl to the rescue!
To package modules from CPAN:
```
dh-make-perl --cpan Module::Name
  
```
It creates Module-Name-VERSION directory with the Perl code and the debian dir

To package our own modules:

dh-make-perl                        # Inside the unpacked Perl module dir

This just creates the debian dir
Watch out for /usr/lib/perl/5.8 in the generated packages!

Packaging Python modules

Same story with Python modules
stdeb to the rescue!
To package some Python module:
```
py2dsc Whatever-1.0.tar.gz
  
```
This creates a directory deb_dist dir with a source package (remember, three files!)
You have to unpack it (dpkg-source) and build it normally
Don't ask me about the confusing names, I have no idea

Meta-packages and such

WTF is that? "Empty" packages that depend on others
Easy way to control which things a system has installed
Can also uninstall packages (Conflicts and such)
For quick and dirty meta-packages, you can use equivs
That's not really its purpose, but whatever

To create a simple "empty" package:

equivs-control new-package-name.control
$EDITOR        new-package-name.control
equivs-build   new-package-name.control

The equivs "control" file is similar to debian/control

`equivs` control file example

Section: misc
Priority: optional
Standards-Version: 3.6.2

Package: some-new-package
Version: 2.1
Maintainer: Random J Developer <randomd@example.com>
Depends: cool-package1, cool-package2
Architecture: all
Description: Does some really good stuff
 Empty package depending on packages that do good stuff.
 .
 So yeah, short description is slightly misleading. Whatever.

See the equivs-build (1) manpage.

Takk!

Takk. Spørsmål?