I’ll leave the anatomy of a Debian package for Google-U

Generating a package skeleton with dh_make

# Get the tools you'll need
sudo apt install devscripts

Start by picking a package name, and a version you want you package to be. I’ll go with the class “foo” and “0.1”, but feel free to chose something more relevant:

mkdir foo-0.1
cd foo-0.1
# Here  pick "indep" to specify that the package is architecture independent.
dh_make --indep --createorig

This will have created a debian/ subdirectory in the foo-0.1 directory. Narrow it down to the essentials:

mkdir essentials
mv debian/{changelog,compat,rules,control} essentials
rm -r debian
mv essentials debian

Recreate the debian/ subdirectory, this time with only the most important files present.

You folder should now look like:

foo-0.1/
└── debian
    ├── changelog
    ├── compat
    ├── control
    └── rules

Filing the generated control file

The control file is the file that lists all the package’s metadata, and, roughly everything that will show up for your users when they use apt-cache to query information about it.

While the generated control file is almost useable as-is, we’ll need to quickly edit a couple of fields for our new package:

Choosing a Section

Sections are used to group packages related to a particular topic. You should pick one from the list .

For a wallpaper package the “universe/graphics” section is probably appropriate.

This is optional however, so you as well just remove the “Section:” line for our dead simple package.

Editing the homepage

Either add a link to a relevant website, or remove the line altogether.

Adding a source control link

If you are planning to maintain this package with a version control system (which is a pretty good idea in general), you should add the URL to it in the control file, as modern dh_make will have pre-filled for you.

Users of your package will get a warning message when getting the package’s source (using “apt-get source” for example) telling them where the package is maintained, and will therefore help potential contributors know how and where to submit packaging fixes.

Adding description fields

The most important part of this exercise: add a short and long description of what your package does.

Adding the actual files

It’s time to add the files we want to ship. For this, let’s prepare the ground and add a “tree” directory in our foo-0.1 folder. That folder will be “translated” into our target system’s root by the install rules we’ll create just now:

mkdir tree
echo './tree/* ./' > debian/foo.install

Make sure to replace “foo.install” by “.install”!

You can now add your files in the “tree” subdirectory, as if it was the target system’s root.

For example, adding a wallpaper to a desktop install:

mkdir -p tree/usr/share/backgrounds/
cp my_penguin_picture.png tree/usr/share/backgrounds/.

On the installed system, the penguin picture file will be installed in /usr/share/backgrounds

Your tree should now look like something like this:

foo-0.1/
├── debian
│   ├── changelog
│   ├── compat
│   ├── control
│   ├── rules
│   └── foo.install
└── tree
    └── usr
        └── share
            └── backgrounds
                └── my_penguin_picture.png

Create a changelog entry

Time to add a changelog entry to your package.

The Debian changelog is the file that tracks what changes in your package, in a machine-readable way, and is also the file that determines what the version number for particular build will be.

The “dch” program will help you greatly in this task by doing most of the grunt work for you. If your package were a “real” package to be distributed with Ubuntu proper, you’d need to pay special attention to the version number, but for now, we’ll just go for the easy scheme and number things like “0.1” then “0.2” and so on.

Doing things this way is called creating a “native package”.

Here’s what my example changelog looks like after editing it:

foo (0.1) zesty; urgency=low

* Initial release. Add whatever is relevant here.

-- Christopher Glass <[email protected]>  Thu, 23 Jul 2015 18:26:05 +0300

Make sure your name matches your GPG key’s identity exactly here, that will make signing the packages more simple.

Important: Make sure you replace the default “unstable” by whatever Ubuntu version you target! It’s a classic source of failing builds (at least for me).

Building and uploading the package

Making a test binary deb

Before we think about publishing our work, let’s build a test .deb file. Simply running the following command in your top-level directory should take care of the deb file creation:

debuild