Debian Developer's Reference

Developer's Reference Team <developers-reference@packages.debian.org>

• Copyright © 2019 - 2023 Holger Levsen

• Copyright © 2015 - 2020 Hideki Yamane

• Copyright © 2008 - 2015 Lucas Nussbaum

• Copyright © 2004 - 2007 Andreas Barth

• Copyright © 2002 - 2009 Raphaël Hertzog

• Copyright © 1998 - 2003 Adam Di Carlo

• Copyright © 1997 - 1998 Christian Schwarz

This manual is free software; you may redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version.

This is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. See the GNU General Public License for more details.

A copy of the GNU General Public License is available as /usr/share/common-licenses/GPL-2 in the Debian distribution or on the World Wide Web at the GNU web site. You can also obtain it by writing to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.

This is Debian Developer's Reference version 13.14, released on 2024-10-30.

If you want to print this reference, you should use the pdf version. This manual is also available in some other languages.

• 1. Scope of This Document
• 2. Applying to Become a Member
  • 2.1. Getting started
  • 2.2. Debian mentors and sponsors
  • 2.3. Registering as a Debian member
• 3. Debian Developer's Duties
  • 3.1. Package Maintainer's Duties
    • 3.1.1. Work towards the next stable release
    • 3.1.2. Maintain packages in stable
    • 3.1.3. Manage release-critical bugs
    • 3.1.4. Coordination with upstream developers
  • 3.2. Administrative Duties
    • 3.2.1. Maintaining your Debian information
    • 3.2.2. Maintaining your public key
    • 3.2.3. Voting
    • 3.2.4. Going on vacation gracefully
    • 3.2.5. Retiring
    • 3.2.6. Returning after retirement
• 4. Resources for Debian Members
  • 4.1. Mailing lists
    • 4.1.1. Basic rules for use
    • 4.1.2. Core development mailing lists
    • 4.1.3. Special lists
    • 4.1.4. Requesting new development-related lists
  • 4.2. IRC channels
  • 4.3. Documentation
  • 4.4. Debian machines
    • 4.4.1. The bugs server
    • 4.4.2. The ftp-master server
    • 4.4.3. The www-master server
    • 4.4.4. The people web server
    • 4.4.5. salsa.debian.org: Git repositories and collaborative development platform
    • 4.4.6. GitHub.com: Submitting pull requests to upstream repositories
    • 4.4.7. chroots to different distributions
  • 4.5. The Developers Database
  • 4.6. The Debian archive
    • 4.6.1. Sections
    • 4.6.2. Architectures
    • 4.6.3. Packages
    • 4.6.4. Distributions
      • 4.6.4.1. Stable, testing, and unstable
      • 4.6.4.2. More information about the testing distribution
      • 4.6.4.3. Experimental
    • 4.6.5. Release code names
  • 4.7. Debian mirrors
  • 4.8. The Incoming system
  • 4.9. Package information
    • 4.9.1. On the web
    • 4.9.2. The dak ls utility
  • 4.10. The Debian Package Tracker
  • 4.11. Developer's packages overview
  • 4.12. Debian's FusionForge installation: Alioth
  • 4.13. Goodies for Debian Members
• 5. Managing Packages
  • 5.1. New packages
  • 5.2. Recording changes in the package
  • 5.3. Testing the package
  • 5.4. Layout of the source package
  • 5.5. Picking a distribution
    • 5.5.1. Special case: uploads to the stable and oldstable distributions
    • 5.5.2. Special case: the stable-updates suite
    • 5.5.3. Special case: uploads to testing/testing-proposed-updates
  • 5.6. Uploading a package
    • 5.6.1. Source and binary uploads
    • 5.6.2. Uploading to ftp-master
    • 5.6.3. Delayed uploads
    • 5.6.4. Security uploads
    • 5.6.5. Other upload queues
    • 5.6.6. Notifications
  • 5.7. Specifying the package section, subsection and priority
  • 5.8. Handling bugs
    • 5.8.1. Monitoring bugs
    • 5.8.2. Responding to bugs
    • 5.8.3. Bug housekeeping
    • 5.8.4. When bugs are closed by new uploads
    • 5.8.5. Handling security-related bugs
      • 5.8.5.1. Debian Security Tracker
      • 5.8.5.2. Confidentiality
      • 5.8.5.3. Security Advisories
      • 5.8.5.4. Preparing packages to address security issues
      • 5.8.5.5. Uploading the fixed package
  • 5.9. Moving, removing, renaming, orphaning, adopting, and reintroducing packages
    • 5.9.1. Moving packages
    • 5.9.2. Removing packages
      • 5.9.2.1. Removing packages from Incoming
    • 5.9.3. Replacing or renaming packages
    • 5.9.4. Orphaning a package
    • 5.9.5. Adopting a package
    • 5.9.6. Reintroducing packages
  • 5.10. Porting and being ported
    • 5.10.1. Being kind to porters
    • 5.10.2. Guidelines for porter uploads
      • 5.10.2.1. Recompilation or binary-only NMU
      • 5.10.2.2. When to do a source NMU if you are a porter
    • 5.10.3. Porting infrastructure and automation
      • 5.10.3.1. Mailing lists and web pages
      • 5.10.3.2. Porter tools
      • 5.10.3.3. wanna-build
    • 5.10.4. When your package is not portable
    • 5.10.5. Marking non-free packages as auto-buildable
  • 5.11. Non-Maintainer Uploads (NMUs)
    • 5.11.1. When and how to do an NMU
    • 5.11.2. NMUs and debian/changelog
    • 5.11.3. Using the DELAYED/ queue
    • 5.11.4. NMUs from the maintainer's point of view
    • 5.11.5. Source NMUs vs Binary-only NMUs (binNMUs)
    • 5.11.6. NMUs vs QA uploads
    • 5.11.7. NMUs vs team uploads
  • 5.12. Package Salvaging
    • 5.12.1. When a package is eligible for package salvaging
    • 5.12.2. How to salvage a package
  • 5.13. Collaborative maintenance
  • 5.14. The testing distribution
    • 5.14.1. Basics
    • 5.14.2. Updates from unstable
      • 5.14.2.1. Out-of-date
      • 5.14.2.2. Removals from testing
      • 5.14.2.3. Circular dependencies
      • 5.14.2.4. Influence of package in testing
      • 5.14.2.5. Details
    • 5.14.3. Direct updates to testing
    • 5.14.4. Frequently asked questions
      • 5.14.4.1. What are release-critical bugs, and how do they get counted?
      • 5.14.4.2. How could installing a package into testing possibly break other packages?
  • 5.15. The Stable backports archive
    • 5.15.1. Basics
    • 5.15.2. Exception to the testing-first rule
    • 5.15.3. Who can maintain packages in the stable-backports archive?
    • 5.15.4. When can one start uploading to stable-backports?
    • 5.15.5. How long must a package be maintained when uploaded to stable-backports?
    • 5.15.6. How often shall one upload to stable-backports?
    • 5.15.7. How can one learn more about backporting?
• 6. Best Packaging Practices
  • 6.1. Best practices for debian/rules
    • 6.1.1. Helper scripts
    • 6.1.2. Separating your patches into multiple files
    • 6.1.3. Multiple binary packages
  • 6.2. Best practices for debian/control
    • 6.2.1. General guidelines for package descriptions
    • 6.2.2. The package synopsis, or short description
    • 6.2.3. The long description
    • 6.2.4. Upstream home page
    • 6.2.5. Version Control System location
      • 6.2.5.1. Vcs-Browser
      • 6.2.5.2. Vcs-*
  • 6.3. Best practices for debian/changelog
    • 6.3.1. Writing useful changelog entries
    • 6.3.2. Selecting the upload urgency
    • 6.3.3. Common misconceptions about changelog entries
    • 6.3.4. Common errors in changelog entries
    • 6.3.5. Supplementing changelogs with NEWS.Debian files
  • 6.4. Best practices around security
  • 6.5. Best practices for maintainer scripts
  • 6.6. Configuration management with debconf
    • 6.6.1. Do not abuse debconf
    • 6.6.2. General recommendations for authors and translators
      • 6.6.2.1. Write correct English
      • 6.6.2.2. Be kind to translators
      • 6.6.2.3. Unfuzzy complete translations when correcting typos and spelling
      • 6.6.2.4. Do not make assumptions about interfaces
      • 6.6.2.5. Do not use first person
      • 6.6.2.6. Be gender neutral
    • 6.6.3. Templates fields definition
      • 6.6.3.1. Type
      • 6.6.3.2. Description: short and extended description
      • 6.6.3.3. Choices
      • 6.6.3.4. Default
    • 6.6.4. Template fields specific style guide
      • 6.6.4.1. Type field
      • 6.6.4.2. Description field
      • 6.6.4.3. Choices field
      • 6.6.4.4. Default field
  • 6.7. Internationalization
    • 6.7.1. Handling debconf translations
    • 6.7.2. Internationalized documentation
  • 6.8. Common packaging situations
    • 6.8.1. Packages using autoconf/automake
    • 6.8.2. Libraries
    • 6.8.3. Documentation
    • 6.8.4. Specific types of packages
    • 6.8.5. Architecture-independent data
    • 6.8.6. Needing a certain locale during build
    • 6.8.7. Make transition packages deborphan compliant
    • 6.8.8. Best practices for .orig.tar.{gz,bz2,xz} files
      • 6.8.8.1. Pristine source
      • 6.8.8.2. Repackaged upstream source
      • 6.8.8.3. Changing binary files
    • 6.8.9. Best practices for debug packages
      • 6.8.9.1. Automatically generated debug packages
      • 6.8.9.2. Manual -dbg packages
    • 6.8.10. Best practices for meta-packages
• 7. Beyond Packaging
  • 7.1. Bug reporting
    • 7.1.1. Reporting lots of bugs at once (mass bug filing)
      • 7.1.1.1. Usertags
  • 7.2. Quality Assurance effort
    • 7.2.1. Daily work
    • 7.2.2. Bug squashing parties
  • 7.3. Contacting other maintainers
  • 7.4. Dealing with inactive and/or unreachable maintainers
  • 7.5. Interacting with prospective Debian developers
    • 7.5.1. Sponsoring packages
      • 7.5.1.1. Sponsoring a new package
      • 7.5.1.2. Sponsoring an update of an existing package
    • 7.5.2. Granting upload permissions to DMs
    • 7.5.3. Advocating new developers
    • 7.5.4. Handling new maintainer applications
• 8. Internationalization and Translations
  • 8.1. How translations are handled within Debian
  • 8.2. I18N & L10N FAQ for maintainers
    • 8.2.1. How to get a given text translated
    • 8.2.2. How to get a given translation reviewed
    • 8.2.3. How to get a given translation updated
    • 8.2.4. How to handle a bug report concerning a translation
  • 8.3. I18N & L10N FAQ for translators
    • 8.3.1. How to help the translation effort
    • 8.3.2. How to provide a translation for inclusion in a package
  • 8.4. Best current practice concerning l10n

Appendix

• 1. Overview of Debian Maintainer Tools
  • 1.1. Core tools
    • 1.1.1. dpkg-dev
    • 1.1.2. debconf
    • 1.1.3. fakeroot
  • 1.2. Package lint tools
    • 1.2.1. lintian
    • 1.2.2. lintian-brush
    • 1.2.3. piuparts
    • 1.2.4. debdiff
    • 1.2.5. diffoscope
    • 1.2.6. duck
    • 1.2.7. adequate
    • 1.2.8. i18nspector
    • 1.2.9. cme
    • 1.2.10. licensecheck
    • 1.2.11. blhc
  • 1.3. Helpers for debian/rules
    • 1.3.1. debhelper
    • 1.3.2. dh-make
    • 1.3.3. equivs
  • 1.4. Package builders
    • 1.4.1. git-buildpackage
    • 1.4.2. debootstrap
    • 1.4.3. pbuilder
    • 1.4.4. sbuild
  • 1.5. Package uploaders
    • 1.5.1. dupload
    • 1.5.2. dput
    • 1.5.3. dcut
  • 1.6. Maintenance automation
    • 1.6.1. devscripts
    • 1.6.2. reportbug
    • 1.6.3. autotools-dev
    • 1.6.4. dpkg-repack
    • 1.6.5. alien
    • 1.6.6. dpkg-dev-el
    • 1.6.7. dpkg-depcheck
    • 1.6.8. debputy
  • 1.7. Porting tools
    • 1.7.1. dpkg-cross
  • 1.8. Documentation and information
    • 1.8.1. debian-policy
    • 1.8.2. doc-debian
    • 1.8.3. developers-reference
    • 1.8.4. maint-guide
    • 1.8.5. debmake-doc
    • 1.8.6. packaging-tutorial
    • 1.8.7. how-can-i-help
    • 1.8.8. docbook-xml
    • 1.8.9. debiandoc-sgml
    • 1.8.10. debian-keyring
    • 1.8.11. debian-el