UbuntuPackagingChangesSpec

Summary

Document reoccurring packaging changes made in Ubuntu to allow consistent changes in all affected packages. The documentation serves as a guideline/policy for a release cycle and is updated during the release cycle. It essentially documents the best practice behaviours expected of packagers.

Rationale

Documenting the best practice makes it easier to remember/check what needs to be done with packages. This is tied into our ongoing transitions to some degree -> most transitions will generate a new best practice as a result.

Use cases

  • dh_iconcache usage (rationale, what to do, affected packages)
  • hide menu entries; in dapper three different "solutions": remove the desktop file, add one of two extra entries in the desktop file. recommend one way.
  • use of lsb messages during system startup / daemons
  • branding (if it affects not just package specific changes)
  • launchpad-integration
  • library dependencies (removing duplicate libraries)
  • naming menu entries (HIG)
  • language packs (doesn't require a change to a package, but changes the package)

Scope

Design

The document can be found at https://wiki.ubuntu.com/UbuntuPackagingChanges

All changes are described on the same page; each entry should be kept short. If a longer description / more elaborate instructions are needed, the entry includes a pointer to a sub page, an URL to a posting to ubuntu-devel-announce, etc.

Each entry consists of:

  • Title: A concise one line description desrcibing the change.

  • Description: What is changed (no more than 50 words).

  • Keywords: Categorize this change (i.e. desktop, package-renaming, abi/api-change, etc), optional, we don't have that many changes yet.

  • Affected packages: Describe all affected packages, don't name them here themself, maybe point to a subpage, if a complete listing of those packages exists.

  • Rationale: Why do we change this? Why do we change it this way?

  • Release: Started to do that in dapper, not needed anymore in edgy, etc ...

  • Status: started on, finished at, completed for main/universe ...

  • Instructions: How to change the package.

  • Examples: One or two example packages having these changes already implemented.

Implementation

Code

Data preservation and migration

Outstanding issues

  • Should that document become a required policy for edgy?

    RobertCollins - I spoke with mdz about this, his thoughts are that making it a policy will require at least another discussion session to try to identify what size change needs to be documented etc. Instead of that, this should just be considered documentation with the usual requirement that documentation is kept up to date.

BoF agenda and discussion

Many changes in packages in Ubuntu are made on a policy / decision, and are applied to a set of packages. Those changes should be documented during the whole development cycle of edgy (and further releases). These reocurring changes may be clear to uploaders to main, but would give a guideline to uploaders to universe.

Maintain that list as a reference in the wiki.

Review feedback

  • There are a few things that could be added here:

    • The Spec/EasierMotuing specification talks about reorganising the MOTU pages, this new page seems to be an essential one to get linked in.

    • the implementation phase for this specification should be doing the initial documentation - there seems to be a start already on this.
    • Some links to the transition process would be useful I think on this page and on the transition process page, so that people know this is a good place to document the transition impact.

CategorySpec

UbuntuPackagingChangesSpec (last edited 2008-08-06 16:26:49 by localhost)