Differences between revisions 34 and 35
Revision 34 as of 2014-03-28 19:30:54
Size: 6025
Editor: jdstrand
Revision 35 as of 2014-09-09 11:03:53
Size: 6076
Editor: jamesodhunt
Deletions are marked like this. Additions are marked like this.
Line 58: Line 58:
  * Packages which install daemons (`/etc/init.d/*`)   * Packages which install services / daemons (`/etc/init.d/*`, `/etc/init/*`, `/lib/systemd/system/*`)

Promoting a package into main


This document describes the requirements for a package to be considered for inclusion into the supported set of Ubuntu packages (into main), which entails that this package receives the full scope of security and QA support.

The MainInclusionProcess page describes the steps of the process.


The package must fulfill the following requirements:

  1. Availability: The package must already be in the Ubuntu universe, and must build for the architectures it is designed to work on.

  2. Rationale: There must be a certain level of demand for the package, for example:

    • The package is useful for a large part of our user base.
    • The package is a new build dependency or dependency of a package that we already support (additionally, the official image builder requires all used packages be in main).
    • The package helps meet a specific Blueprint goal.
    • The package replaces another package we currently support and promises higher quality and/or better features, so that we can drop the old package from the supported set.
  3. Security: The security history and the current state of security issues in the package must allow us to support the package for at least 9 months (60 for LTS support) without exposing its users to an inappropriate level of security risks. This requires checking of several things that are explained in detail in the subsection Security checks.

  4. Quality assurance:

    • After installing the package it must be possible to make it working with a reasonable effort of configuration and documentation reading.
    • The package must not ask debconf questions higher than medium if it is going to be installed by default. The debconf questions must have reasonable defaults.
    • There are no long-term outstanding bugs which affect the usability of the program to a major degree. To support a package, we must be reasonably convinced that upstream supports and cares for the package.
    • The status of important bugs in Debian's, Ubuntu's, and upstream's bug tracking systems must be evaluated. Links to these bug trackers need to be provided in the MIR report. Important bugs must be pointed out and discussed in the MIR report.

    • The package is maintained well in Debian/Ubuntu (check out the Debian PTS)
    • The package should not deal with exotic hardware which we cannot support.
    • If the package ships a test suite, and there is no obvious reason why it cannot work during build (e. g. it needs root privileges or network access), it should be run during package build, and a failing test suite should fail the build.
    • The package uses a debian/watch file whenever possible. In cases where this is not possible (e. g. native packages), the package should either provide a debian/README.source file or a debian/watch file (with comments only) providing clear instructions on how to generate the source tar file.
  5. UI standards: (generally only for user-facing applications)

    • End-user applications must be internationalized (translatable), using the standard intltool/gettext build and runtime system and produce a proper PO template during build.
    • End-user applications must ship a standard conformant desktop file.
  6. Dependencies:

    • All build and binary dependencies (including Recommends:) must be satisfyable in main (i. e. the preferred alternative must be in main). If not, these dependencies need a separate MIR report (this can be a separate bug or another task on the main MIR bug)

  7. Standards compliance: The package should meet the FHS and Debian Policy standards. Major violations should be documented and justified. Also, the source packaging should be reasonably easy to understand and maintain.

  8. Maintenance: The package must have an acceptable level of maintenance corresponding to its complexity:

    • Simple packages (e.g. language bindings, simple Perl modules, small command-line programs, etc.) might not need very much maintenance effort, and if they are maintained well in Debian we can just keep them synced
    • More complex packages will usually need a developer or team of developers paying attention to their bugs, whether that be in Ubuntu or elsewhere (often Debian). Packages that deliver major new headline features in Ubuntu need to have commitment from Ubuntu developers willing to spend substantial time on them.
    • All packages must have a designated "owning" team, regardless of complexity, which is set as a package bug contact.
  9. Background information:

    • The package descriptions should explain the general purpose and context of the package. Additional explanations/justifications should be done in the MIR report.
    • If the package was renamed recently, or has a different upstream name, this needs to be explained in the MIR report.

Security checks

UbuntuMainInclusionRequirements (last edited 2020-03-24 15:52:43 by paelzer)