Differences between revisions 37 and 38
Revision 37 as of 2007-08-19 11:41:04
Size: 6636
Comment: Fixed slightly garbled syntax
Revision 38 as of 2007-08-19 11:42:58
Size: 6662
Comment: trivial changes (added dh-make-perl)
Deletions are marked like this. Additions are marked like this.
Line 20: Line 20:
= Kind of packages = = Debian package types =
Line 30: Line 30:
=== dh-make-perl ===

This project is in a very early stage. Any contributions are welcome. First of all, a index of sections, chapters and paragraphs has to be created. Feel free to add topics you consider somewhat useful. ?TableOfContents INDEX

Introduction

What is a debian package?

How to choose what to package

There are quite a few things you need to take into consideration while choosing something to package. Some of these include:

  • Is the package released ander a DFSG compatible license? Note that if this isn't the case, you can't get the package into the main section of the archive.
  • Do you use the package? Are you familiar enough with it to handle bug reports? It is essential that you at least use the package so that you can interpret and help out with bug reports which may arise from users. Also, though knowledge of the source code is not an absolute necessary, it is very useful and you can fix up some things and send patches upstream. This is most useful when upstream is not active or available immediately for bug fixes.
  • Are you sure the package you are considering does something very different from packages in Debian which provide similar functionality already?
  • Are you sure there'll be a sufficient audience for the package in Debian?
  • Are you willing to take the required responsibility to maintain the package and keep it updated and fixed on a regular basis?

What to do before packaging

  • Ensure that the package is not in Debian already. An apt-cache search <pkgname>, followed by a search on Google to find out whether the package already has been packaged as a ""deb"" should be sufficient. Don't duplicate work; you'll feel badly knowing that you've spent a week on packaging something someone has already packaged months ago!

  • File an "Intent to Package" (ITP) bug to the Debian project, and CC the bug report to the debian-developers mailing list (reportbug does this automatically). The people on debian-devel might have some comments to make on your proposed ITP. If there isn't any opposition for a period of time, (say a week), you can assume that nobody opposes your intention of packaging the software.

Sending an ITP bug

Debian package types

native

non-native

Creating packages

Pre-requirements

Getting the source

from a tarball

from a revision control system

Packaging tools

dh-make

dh-make-perl

debhelper

CDBS

Benefits

Drawbacks

yada

dpatch

dbs

quilt

debscripts (what?)

debnest

Initial "debianization"

Naming

Initial version number

Editing debian/ files

required files

debian/copyright

debian/changelog

debian/control

debian/rules

other files

debian/compat

debian/docs

debian/dirs

debian/menu

debian/watch

Editing other files

Packaging

Splitting your application into multiple binary packages

  • ?PkgSplit

Packaging according to the build system

Simple top level Makefile

autotools

Python distutils

... other tips

Building packages

Pre-requirements

Building tools

debuild

debuild will automatically run lintian or linda, but their warning and error messages may scroll off the screen. However, debuild also creates a log file of the entire build in the parent of the source directory (with the file extension .build). You may find it convenient to open the build log in your editor to review the lintian messages.

pbuilder and cowbuilder

debaux-build

sbuild

Checking packages

lintian and linda

piuparts

autopkgtests

edos-debcheck

yaclc

debi

Of course, you should actually install your new package as one part of checking it. "debi" saves some typing by installing the most recent .deb file found in a parent of the current directory. It requires root privileges, so you will actually type "sudo debi" (or, using bash's command history, perhaps just "^Rsu").

Debian Quality Assurance Site

If there is already a version of the package in the collection, you should review its entry at the QA site. You can start at http://packages.qa.debian.org/common/index.html. Check the "Bug Count", "TODO", and "Testing Status" sections.

Uploading packages

Sponsorships

Signing packages

debsigs

Uploading tools

dtools

dput and dcut

debaux-publish

dupload

Maintaining an archive

Updating packages

If you download a new upstream source file, move it to the parent of the current source directory. Make sure it has a name with a Debian compliant version number, say "foo-2.1.tar.gz". cd into the current source directory. You can port the current patches to the new sources with

  • uupdate ../foo-2.1.tar.gz

Now cd into the new source directory and look for any failed patches

  • find . -name \*.rej

Once you have cleared these up, build and check the package as described above.

Update a repository

mini-dinstall

Using version control to manage packaging

Bazaar

Darcs

Git

Mercurial

Subversion

Appendix: Examples

Appendix: Editors with useful features

vi/vim

GNU Emacs

If you use emacs, be sure to install the "dpkg-dev-el" package. It provides special modes for editing the control and changelog files.

Appendix: Debian Policies

Some (useful) stuff about packaging: