Debian Trends



Introduction

Debian packaging practices evolved over time. This page provides some historical perspective about how those practices evolved. This data was generated with lintian, a rather basic script, data from snapshot.debian.org starting in 2005, and computational power from Grid'5000. This is a static page, last refreshed in September 2025. If it is not fresh enough, nag the author!

All graphs are for Debian testing (main only, not contrib/non-free), because there is a number of unmaintained or abandonned packages in Debian unstable that we do not want to report about. Alternate graphs with Debian unstable are also provided. Each graph provides the number of packages in each case over time. Vertical lines indicate release dates.

How you can help

  • Make the necessary changes to lintian so that it can report information about the above stuff, and help include the lintian modifications into standard lintian.
  • Hack on the data collection itself (there are development instructions in README.md)
  • Provide ideas for additional graphs (ideally, with the relevant Lintian tags)

Contact: Lucas Nussbaum <lucas@debian.org>

Debhelper compatibility level

Also available:

Build systems

Also available:

Source formats

Also available:

Source formats and patch systems

Also available:

Version Control System

Also available:

VCS Hosting

Also available:

Copyright format: machine-readable (DEP-5) vs old format

Also available:

Co-maintenance

Also available:

Rules-Requires-Root

Note that "no" is now the default, so this graph is mainly interesting for the historical perspective.

Also available:

Support for build-arch and build-indep

Also available:

Test suite

This tracks packages that declare a Testsuite in debian/control and/or the dsc file.

Also available:

Continuous Integration on Salsa

This graph only looks at source packages, and thus misses:

  • git repositories that exclude shipping debian/salsa-ci.yml in source using a debian/.gitattributes file
  • salsa projects that specify a CI configuration file in another project in the salsa project configuration (using recipes/debian.yml@salsa-ci-team/pipeline)

Also available:

git-buildpackage

This tracks packages that use git-buildpackage by checking for presence of debian/gbp.conf. It misses packages that use git-buildpackage but do not include a debian/gbp.conf file.

Also available:

debian/watch version

Also available:

Uploads using dgit and tag2upload

This is based on the analysis of the Dgit and Git-Tag-Info fields in the dsc file.

Also available:

Smells

Inspired by code smells (any characteristic in the source code of a program that possibly indicates a deeper problem), this page also provides a list of packages that should be refreshed to newer standards.

This is subjective (and feel free to criticize, but I might feel free to ignore critics :-) ). Here is the logic:

  • Debhelper compatibility level: on 2024-08-01, 97.9% of packages in testing have a debhelper compatibility level of 9 or higher (9: 3%; 10: 6%; 11: 4%; 12: 12%; 13: 69%; 14: 0%). Therefore, using a debhelper compatibility level lower than 9 is a smell.
  • Build system: on 2024-08-01, 93.5% of packages in testing use dh (others: cdbs: 4%; debhelper: 2%; other: 0%; : 0%). So, not using dh is a smell.
  • Source format and patch system: on 2024-08-01, 99.4% of packages in testing use 3.0 (quilt) (97.4%) or 3.0 (native) (2.0%). Therefore, not using 3.0 is a smell
  • VCS: On 2024-08-01, 93.8% of packages use Git, 6.0% use no VCS at all, and 0.2% use another VCS. 88.4% use Git on Salsa, and 2.8% use Git on Alioth (and will likely move to Salsa). Therefore, not using Git and Salsa is a smell (except if the package is using dgit).
  • Overall, 86.1% of packages use a debhelper compatibility level >= 9, dh, 3.0 (native) or 3.0 (quilt), Git, and either Salsa or Alioth.
List of packages with smells:

Also available:

Contact: Lucas Nussbaum <lucas@debian.org>. See Introduction for pointers to source code.