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 August 2024. 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

  • Provide ideas for more graphs. The current to-do list is:
    • Standards-Version
    • init scripts vs systemd units vs both (see #951653)
    • patches and tags (DEP-3)
    • age of packages (last upload date)
    • dgit adoption (it is not clear how we can detect that)
    • git packaging workflow (but there is probably no way for lintian to detect that)
  • 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)

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

Also available:

Support for build-arch and build-indep

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.