BrandingForDerivatives

Differences between revisions 1 and 42 (spanning 41 versions)
Revision 1 as of 2005-04-04 18:05:11
Size: 1074
Editor: ca-studio-bsr1o-251
Comment:
Revision 42 as of 2005-04-28 00:21:55
Size: 7126
Editor: intern146
Comment: "About Ubuntu" needs to move to ubuntu-docs
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= People = ## page was renamed from DerivativeBranding
## page was renamed from UbuntuBranding
## page was renamed from UbuntuDevel/Branding
## page was renamed from UbuntuDownUnder/BOFs/UbuntuDevelopment/Branding
= Branding =
Line 3: Line 7:
 * ColinWatson == Status ==
Line 5: Line 9:
= Goal =  * People: ColinWatsonLead, MartinPittSecond
 * Contributors:
 * Interested: MarkShuttleworth, MattZimmerman, JuanjeOjeda, AndrewFitzsimon
 * Status: DraftSpec, DistroSpecification, UduBof, HighPriority
 * Branch: n/a
 * Pending: MarkShuttleworthQueue -- braindump needed.
 * UduSessions: 1
Line 7: Line 17:
Implement a mechanism to allow simple, centralized branding for Ubuntu derivatives == Introduction ==
Line 9: Line 19:
= Requirements = This specification describes our strategies to allow for the effective branding of Ubuntu and derivatives. Some branding can be attained without affecting packages, other branding initiatives will require derivatives to rebuild or even modify and rebuild packages. We will also refer to aspects of Rosetta that should affect distro branding.

== Rationale ==

== Scope and Use Cases ==
Line 12: Line 26:
  * Installer   * CD
Line 15: Line 29:
  * Installer
Line 17: Line 32:
   * Help texts
   * Dialogs
  * Live CD Installer (UbuntuExpress)
   * Artwork (Logos, images..)
   * Help texts
   * Dialogs
Line 26: Line 47:
  * Desktop    * Grub menu entry
   * Grub theme
  * Application defaults
Line 30: Line 53:
   * Default browser homepage
   * Default browser bookmarks
   * Gnome/Kde theme
   * Menu
   * Apps on "Add/Remove programs"
   * Icons on panel and desktop
   * "About Ubuntu" (System Menu)
  * Others
   * Debootstrap script
Line 31: Line 63:
= Agenda = == Implementation Plan ==
Line 33: Line 65:
 * Runtime branding, build-time branding and package-selection branding
  * Which approach is most suitable for each requirement?
  * Can we avoid build-time branding entirely? It causes big infrastructure problems
 * Branded CD builds
 * Debconf branding
We have discussed several approaches to branding, and in which cases they are useful. By necessity, our plan to improve the branding situation for derivatives is a combination of these approaches.

The Rosetta team has done some initial work to mark branded strings.

Many strings can simply be neutralized. This is the simplest case to handle, and subsequently requires no effort to re-brand for each derivative. We should apply this technique wherever possible, although it does not always make sense: for instance, the installer does need to talk about the distribution it's installing at some point. Similarly, [:PackageSelection:development work] is proceeding on debootstrap to avoid having to rebuild debootstrap simply to change the contents of the base system.

Runtime substitution strategies are appropriate for simple circumstances (e.g., Apache version string, Mozilla version string). In some cases, we can use the lsb_release command and have a reasonable chance of having the code passed upstream. Since it is not always appropriate to call an external program, we will need to add a `liblsb-release` to provide the functionality of `lsb_release` as a library and use it for identification strings.

A number of items of branding can be refactored by collecting branding data into central locations. This works well for artwork and for gconf configuration data.

Some items really require build-time branding. There are hard problems to be solved in the packaging system and in Launchpad before we can manage a separate build for every derivative. This isn't achievable for Breezy, so for the near term we must avoid it as far as possible.

The hardest part of the problem is branding human-readable strings. These must be translated, so retranslation is required after branding them. Upstream software rarely uses distro-specific branding, so we can deal with that on a case-by-case basis. Most branding applies to debconf templates, and most of that is in the installer; other packages, and indeed much of the installer as well, can and should be neutralized. For the remaining cases, we have the following (non-exclusive) options:
 * Translate the remaining few cases manually to properly catch linguistic issues (plurals, genders, tenses, etc.). This would require additional complexity and effort in order to avoid duplicating work across distributions which target the same languages.
 * Try to catch the most common cases with a global macro (debconf already supports per-package macro substitution).
 * Use special-case macros, but since they have to be maintained somehow, this could create more problems than it solves.

=== Tasks that need to be done once and for all ===

 * Use `lsb_release` at build time in `debian-installer` to display correct boot loader text.
 * Use `liblsb-release` or `lsb_release` in initrd build for "Starting $distro...", and in the bootloader installers for generating appropriate menu entries.
 * Use `lsb_release` in `reportbug` and similar tools to select the correct bug tracker.
 * Neutralize debconf templates in the installer (also consider using a global macro).
 * Move `.desktop` file for "About Ubuntu" into `ubuntu-docs`.

=== Tasks that need to be done for every derivative ===

Even after the above, it still remains to make some changes to source packages. We propose to create a tool to perform these changes in a guided fashion, with feedback from the user. This could be a script that uses HCT to make source package changes and publish them to a personal APT archive. (There are already similar projects around, see [http://software-libre.org/moin/Meta/en/BrandingSystem Branding System]).

The following changes need to be made:

 * Adapt strings in `lsb-release`.
 * Change boot loader splash image in `debian-installer`.
 * Adapt and translate remaining strings in `debian-installer`.
 * Add a new `$distro-artwork` package which uses `update-alternatives` to provide a common path for all files, so that gdm etc. can find the files.
 * Add a new `$distro-docs` package if desired.
 * Package selection: Create/change seeds, add new $distro-meta package, configure installer to install it; $distro-meta package can be updated from the seeds at build time.
 * Rebuild `debian-installer` for the distribution.

Having done this, Launchpad can perform CD builds (once it knows how to do this); it is simple to replace the splash image and bootloader text with appropriate branding at CD build time.

== Outstanding Issues ==

=== UDU BOF Agenda ===
Line 40: Line 112:
  * artwork (<dist>-artwork)  * Live CD Installer (UbuntuExpress)
  * Artwork (Logos, images..)
  * Help texts
  * Dialogs
 * Base
  * Archive/cdimage keyring? This may stop being an issue; see ["CDRomAuthentication"]
 * Boot
  * USplash image
  * Grub theme: not necessary to brand; if you wish, change d-i
 * Application defaults
  * Default browser bookmarks
  * Menu
  * Apps on "Add/Remove programs"
  * Icons on panel and desktop
  * "About Ubuntu" (System Menu)
Line 42: Line 128:
= Pre-Work = === UDU Pre-Work ===
Line 44: Line 130:
 * Review DistributionDefaultsAndBranding against the above  * Review [http://www.ubuntu.com/wiki/DistributionDefaultsAndBranding DistributionDefaultsAndBranding] against the above

Branding

Status

Introduction

This specification describes our strategies to allow for the effective branding of Ubuntu and derivatives. Some branding can be attained without affecting packages, other branding initiatives will require derivatives to rebuild or even modify and rebuild packages. We will also refer to aspects of Rosetta that should affect distro branding.

Rationale

Scope and Use Cases

  • Provide for branding or neutralization, as appropriate, of the following components:
    • CD
      • Boot loader splash image
      • Boot loader text
    • Installer
      • Debconf templates
      • Package selection
      • Help texts
      • Dialogs
    • Live CD Installer (UbuntuExpress)

      • Artwork (Logos, images..)
      • Help texts
      • Dialogs
    • Live CD
      • "Starting Ubuntu..."
    • Base
      • Archive keyring?
      • Debconf templates?
      • lsb-release? (hard)
    • Boot
      • USplash image
      • "Starting Ubuntu..."
      • Grub menu entry
      • Grub theme
    • Application defaults
      • GDM theme
      • Splash graphic
      • Default wallpaper
      • Default browser homepage
      • Default browser bookmarks
      • Gnome/Kde theme
      • Menu
      • Apps on "Add/Remove programs"
      • Icons on panel and desktop
      • "About Ubuntu" (System Menu)
    • Others
      • Debootstrap script

Implementation Plan

We have discussed several approaches to branding, and in which cases they are useful. By necessity, our plan to improve the branding situation for derivatives is a combination of these approaches.

The Rosetta team has done some initial work to mark branded strings.

Many strings can simply be neutralized. This is the simplest case to handle, and subsequently requires no effort to re-brand for each derivative. We should apply this technique wherever possible, although it does not always make sense: for instance, the installer does need to talk about the distribution it's installing at some point. Similarly, [:PackageSelection:development work] is proceeding on debootstrap to avoid having to rebuild debootstrap simply to change the contents of the base system.

Runtime substitution strategies are appropriate for simple circumstances (e.g., Apache version string, Mozilla version string). In some cases, we can use the lsb_release command and have a reasonable chance of having the code passed upstream. Since it is not always appropriate to call an external program, we will need to add a liblsb-release to provide the functionality of lsb_release as a library and use it for identification strings.

A number of items of branding can be refactored by collecting branding data into central locations. This works well for artwork and for gconf configuration data.

Some items really require build-time branding. There are hard problems to be solved in the packaging system and in Launchpad before we can manage a separate build for every derivative. This isn't achievable for Breezy, so for the near term we must avoid it as far as possible.

The hardest part of the problem is branding human-readable strings. These must be translated, so retranslation is required after branding them. Upstream software rarely uses distro-specific branding, so we can deal with that on a case-by-case basis. Most branding applies to debconf templates, and most of that is in the installer; other packages, and indeed much of the installer as well, can and should be neutralized. For the remaining cases, we have the following (non-exclusive) options:

  • Translate the remaining few cases manually to properly catch linguistic issues (plurals, genders, tenses, etc.). This would require additional complexity and effort in order to avoid duplicating work across distributions which target the same languages.
  • Try to catch the most common cases with a global macro (debconf already supports per-package macro substitution).
  • Use special-case macros, but since they have to be maintained somehow, this could create more problems than it solves.

Tasks that need to be done once and for all

  • Use lsb_release at build time in debian-installer to display correct boot loader text.

  • Use liblsb-release or lsb_release in initrd build for "Starting $distro...", and in the bootloader installers for generating appropriate menu entries.

  • Use lsb_release in reportbug and similar tools to select the correct bug tracker.

  • Neutralize debconf templates in the installer (also consider using a global macro).
  • Move .desktop file for "About Ubuntu" into ubuntu-docs.

Tasks that need to be done for every derivative

Even after the above, it still remains to make some changes to source packages. We propose to create a tool to perform these changes in a guided fashion, with feedback from the user. This could be a script that uses HCT to make source package changes and publish them to a personal APT archive. (There are already similar projects around, see [http://software-libre.org/moin/Meta/en/BrandingSystem Branding System]).

The following changes need to be made:

  • Adapt strings in lsb-release.

  • Change boot loader splash image in debian-installer.

  • Adapt and translate remaining strings in debian-installer.

  • Add a new $distro-artwork package which uses update-alternatives to provide a common path for all files, so that gdm etc. can find the files.

  • Add a new $distro-docs package if desired.

  • Package selection: Create/change seeds, add new $distro-meta package, configure installer to install it; $distro-meta package can be updated from the seeds at build time.
  • Rebuild debian-installer for the distribution.

Having done this, Launchpad can perform CD builds (once it knows how to do this); it is simple to replace the splash image and bootloader text with appropriate branding at CD build time.

Outstanding Issues

UDU BOF Agenda

  • Refactoring desktop branding
    • gconf schemas, etc. (<dist>-branding)

  • Live CD Installer (UbuntuExpress)

    • Artwork (Logos, images..)
    • Help texts
    • Dialogs
  • Base
    • Archive/cdimage keyring? This may stop being an issue; see ["CDRomAuthentication"]
  • Boot
    • USplash image
    • Grub theme: not necessary to brand; if you wish, change d-i
  • Application defaults
    • Default browser bookmarks
    • Menu
    • Apps on "Add/Remove programs"
    • Icons on panel and desktop
    • "About Ubuntu" (System Menu)

UDU Pre-Work

UbuntuDownUnder/BOFs/BrandingForDerivatives (last edited 2008-08-06 16:23:24 by localhost)