Translation(s): none
This page outlines aspects to take care while creating a derivative Debian distribution.
For now it is just an outline to collect relevant information which could be formalized later on in the form of Specification.
Contents
Intro
Derivative Debian distributions vary in the domains of their specialization, user base, and the scale of modifications/extension they bring on top of vanilla Debian distribution. Therefore, there might not be a strict deterministic set of rules, and rather a set of guidelines could help to decide which actions should be taken by the developers of the derivative distribution to not inflict Debian, and, moreover, benefit from the Debian infrastructure/resources/frameworks where applicable.
Infrastructure
We encourage derivative distributions to mention and define their relationship with Debian on the web page that gives information about the derivative distro (usually the about page).
We encourage derivative distributions to use Debian infrastructure and the software that powers Debian infrastructure where possible.
Repositories
For those derivatives that re-use Debian binary packages, add some source packages and modify some source packages, where possible we encourage them to use standard Debian mirrors and add a second repository containing only the source and binary packages that have been added or modified.
For those derivatives that rebuild Debian source packages, add some source packages and modify some source packages, where possible we encourage them to use standard Debian mirrors for the source packages and add a second repository containing only the source and binary packages that have been added or modified. This recommendation may be hard to do and therefore regular source package syncing is an alternative recommendation.
Of course in both cases it is a good idea to run a Debian mirror to ensure source and binary availability. Any exact mirrors of Debian source and or binary packages should be registered with the Debian mirrors list.
Trademark
Derivative distributions must not be named Debian
Current Debian trademark policy states: To be fair to all businesses, we insist that no business use the name "Debian" in the name of the business, or a domain name of the business.
ongoing work on the Draft of the new Debian trademark policy aims to clarify/relax above restriction. Consult the DebianProjectLeader meanwhile on a case-by-case basis
De-/Re-branding
Depending on the degree of divergence from the vanilla Debian, it might be necessary to introduce non-functional modifications in the deployed system to eliminate user confusion of the derivative distribution with vanilla Debian
Entry points
Following packages along with corresponding files present users with Debian name upon interaction with the system
base-files
- /etc/issue
- /etc/issue.net
- /etc/dpkg/origins/default (symlink to distribution information file)
- /usr/share/base-files/motd
grub-pc
- /etc/grub.d/05_debian_theme
debian-installer
- package root/build/boot/x86/ (branding, references to 'Debian on all the fnumber screens')
- package root/build/config/local (override various strings)
debian-cd
- will probably need customisation for the install images.
synaptic
- uses the debian logo for indicating packages
software-properties-gtk
talks about dfsg and debian release (eg, squeeze). don't know if this counts
Artwork
- Any default background images carrying Debian official use logo?
- "Debian official use logo" with "Debian" word has usage restrictions: "This logo or a modified version may be used by anyone to refer to the Debian project, but does not indicate endorsement by the project. "
Packages
Rebuilt Debian packages should carry distribution specific version suffix to avoid confusion with possibly API/ABI-incompatible original packages provided from Debian archives.
When modifying source packages, rename the Maintainer field to XSBC-Original-Maintainer and add a new Maintainer field.
Bug reports
Since Debian bug tracking system should not be used directly to report bugs in the derivative distributions, submitted bugreports should not be sent directly against Debian packages. reportbug could either be switched (see /usr/share/doc/reportbug/README.developers.gz) or patched (please do not forget to make patch generic and submit it to Debian) to use some other bug tracking system/server; alternatively different address to submit reports could be specified per each source package in the Bugs field of source portion in debian/control file.
Specific choice among above scenarios depends on the degree to which derivative distribution is changing/extending vanilla Debian system. For example, if the derivative does not introduce heavy reconfiguration of the stock Debian system, nor provides custom builds of non-leaf packages -- it should be sufficient to provide custom Bugs: header fields only in rebuilt/new packages. If some base Debian libraries get customized/rebuilt and/or heavy re-configuration of the default Debian system in place, it is advised that all bugreports get submitted to the maintainers of the derivative distribution first for the analysis either the bug is pertinent to stock Debian, where it should be forwarded by the maintainers in such cases.
Popularity Contest
If you want to become the collector of popcon submissions, please do not simply divert popcon submissions from the default popcon.debian.org to your server. Multiple target popcon servers could be listed in SUBMITURLS.
Benefits
- Debian would benefit from more adequate status on the usage of the work of Debian community
If apt package in the derivative carries custom suffix (since per se no other distribution-specific information is included in the popcon submissions) it could allow Debian to discover the most popular derivatives and provide some nice statistics of the usage beyond stock Debian
- Niche packages, which might not be very popular in stock Debian, could be more actively used in a specialized derivative distribution. Having adequate popcon statistic in Debian would guarantee that the package would not be removed from stock Debian, thus offloading maintenance burden on the interested derivative
- Debian's popcon, unlike some other deployed popcon servers, might provide additional information (e.g. historical data) which might not be exposed on the derivative's popcon website for some reason.