Posted by Steve on Sun 10 Jul 2005 at 19:03
Debian is well known for the software which is contained in its repositories. There are thousands of packages available already in the official archives, (and more packages held in various unofficial archives). But how does new software get added to the distribution?Requirements
In order for a package to be "in" the Debian distribution it needs to exist upon within the official Debian package repositories. For that to happen four things need to occur:
- The software must be turned into a Debian package.
- An existing Debian Developer must upload it.
- The software must meet the Debian Free Software Guidelines.
- The ftp masters must approve its inclusion.
After the package is made?
Before you begin creating the package you should first file an "ITP" bug in the Debian Bug Tracking System (BTS). This means that you Intend To Package the given software. Doing this reduces the risk of somebody else duplicating your effort by simultaneously working upon the same piece of software.
The list of packages for which ITP bugs have been filed should be viewed and searched before you start work on your package, to make sure you don't duplicate effort of somebody else needlessly.
Creating packages for your own personal use is a fairly simple process, especially if you create a Debian package with checkinstall or use some other existing tool to help such as the dh-make-perl tool for packaging Perl CPAN modules.
To have a package in the Official Debian repositories the requirements are set a bit higher than just a rough package; Your package must follow the Debian standards, and conform to the Debian policy manual.
These policy guidelines help ensure that the software which is included is of the highest possible quality.
The policy manual describes how software is named, which section of the archive it should be placed into and how different aspects of its installation should be handled. There are additional manuals which describe other things, such as the perl-policy which covers how Perl packages should be handled and the menu-policy which covers how menu entries should be structured.
To a complete newcomer these policies might be a little bit dense and hard to understand at first, but after working through an example or two things become much clearer. A useful reference is the Debian New Maintainer Guide which describes the creation of Debian packages with good examples.
Once you have a package your job is almost complete, the software is ready and could be added to the repository. How that is done depends largely on who you are.
If you're an existing developer then uploading is a simple job, if you're not a member of the project, but intend to become one, then you must find an existing developer to check your work and "sponsor" your upload.
In general new developers join the Debian project by creating and having new packages uploaded to the archive. These might be either wholly new pieces of software or previously orphaned packages which have no current maintainer.
Because non-developers may not upload directly into the Debian archive such uploads must be "sponsored".
If you're not a member of the project and would like to join then you should start by becoming familiar with the New Maintainer's Corner, this describes exactly how a person goes through the process of becoming a Debian Developer.
Sidestepping that process for a moment though, if you have a package which you have previously filed an ITP bug for, and subsequently gone on to create, then your next job is to find a developer to upload it on your behalf.
The common way of doing that is to seek assistance from the debian-mentors mailing list. This list specialises in helping and "mentoring" new applicants - both in terms of assisting in the creation of packages, and in answering questions about the process.
The debian-mentors FAQ should provide a useful reference.
To find a sponsor you should send a message describing your package, and providing a link to the location from which the source can be downloaded. Nobody will be interested in merely seeing a link to the binary .deb file, because they will wish to see how your package is constructed and will rebuild it themselves to test it.
If you receive a response then you may also receive some questions, and suggestions for improving the package. Once your potential sponsor is happy with the package they will upload it for you.
(Matthew Palmer wrote a nice checklist for people sponsoring package uploads which might be useful for people to read. It highlights a couple of areas where new packagers sometimes make mistakes.
The New Queue
Developers have the power to directly upload their created packages. This isn't an excuse for failing to file ITP bugs, nor is it a divine right - the packages which are uploaded should still conform to the relevant policies, and still have to wait their time in the New Queue.
Developers, if they have time for it, are encouraged to join the debian-mentors mailing list and sponsor packages which interest them.
The Developer's Reference contains a section on sponsoring uploads which explains how they should be carried out, and what you need to do. This is nicely augmented by the sponsorship checklist which was previously mentioned.
New packages which are uploaded to the archives are not blindly added - instead they require manual addition to the archives. This is the job of the "ftp masters".
The current membership of the ftp master team, like all other teams, is listed upon the Debian Organizational Structure page.
The package which has been uploaded will sit in the NEW Queue until it is either approved and moved into the official archives - or rejected, in which case the package uploader will receive an explanation of why its addition was refused.
For reference "new packages" includes wholly new packages and packages which have had a new name - such as versioned library packages. This explains part of the delay involved in the acceptance of new packages as there are always new packages to examine and accept/reject.
Whilst having a package in the official archives is usually the goal of a packager, or an author, once the package is accepted that's not the end. Instead that's the start of the support process.
Once the package is available to the Debian user community bugs will likely be found, or suggestions made for improvement - either in the package itself, or in the scripts, examples, or manpages which are included with it.
Any bugs found and reported will likely require a new upload to fix. If you've made an upload via a sponsor you should approach them again to see if they will repeat their upload. It's usually common for somebody to continue sponsoring a package which they've previously sponsored, unless time constraints make it difficult.
Another common source of problems for new packages is a failure to build upon some of the platforms which Debian supports - in that case the build logs can be used to spot warnings, and compilation errors.
If you have a bug-free package congratulations you can now sit back and see how many people are using it via the popularity contest - which we mentioned the Debian popularity contest briefly in the past.