Debian Pure Blends

Andreas Tille

Copyright

This manual is Free Software; you may redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2.0, or (at your option) any later version.

This is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. See the GNU General Public License for more details.

A copy of the GNU General Public License is available on the World Wide Web at http://www.gnu.org/copyleft/gpl.html. You can also obtain it by writing to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110, USA.

You can find the source of this article in the Git repository at salsa.debian.org. It is also available as Debian package blends-doc.

A printable version in PDF format will be built from time to time.

Revision History
Revision v119 Jun 2013

Abstract

This paper is intended for people who are interested in the philosophy of Debian Pure Blends (in short "Blends" if it is used clearly in internal Debian context), and the technique that is used to manage those projects. For those who are familiar with the concept of Custom Debian Distributions: We just found a new name for this concept because the old name just not expressed what actually is done. It is explained in detail why Blends are not forks from Debian, but reside completely inside the Debian GNU/Linux distribution, and which advantages can be enjoyed by taking this approach. The concept of metapackages and user role based menus is explained. In short: This document describes why Debian Pure Blends are important to the vitality and quality of Debian.


Table of Contents

1. Introduction
2. What are Debian Pure Blends?
2.1. What is Debian?
2.2. What is Debian? (next try)
2.3. Differences from other distributions
2.4. Debian Pure Blends
2.5. Difference between a Blend and a remastered system
2.5.1. Technical
2.5.2. Philosophical
2.6. Further resources about Blends
3. General ideas
3.1. Looking beyond
3.2. Motivation
3.2.1. Profile of target users
3.2.2. Profile of target administrators
3.3. Status of specialised Free Software
3.4. General problem
3.5. Debian Pure Blends from philosophical point of view
4. Existing Debian Pure Blends
4.1. Debian Junior: Debian for children from 1 to 99
4.2. Debian Med: Debian in Health Care
4.3. Debian Edu: Debian for Education
4.4. Debian Multimedia
4.5. Debian GIS: Geographical Information Systems
4.6. DebiChem: Debian for Chemistry
4.7. Debian Science: Debian for science
4.8. Debian Accessibility Project
4.9. Debian ezgo Project
4.10. Blends that were announced but development is stalled
4.10.1. Debian Desktop: Debian GNU/Linux for everybody
4.10.2. Debian Lex: Debian GNU/Linux for Lawyers
4.10.3. Debian Enterprise
4.10.4. Other possible Debian Pure Blends
5. Distributions inside Debian
5.1. To fork or not to fork
5.1.1. Commercial forks
5.1.2. Non-commercial forks
5.1.3. Disadvantages of separate distribution
5.1.4. Advantages of integration into Debian
5.1.5. Enhancing Debian
5.2. Adaptation to any purpose
6. Technology
6.1. Metapackages
6.1.1. Metapackage definition
6.1.2. Collection of specific software
6.1.3. Packages showing up in more than one metapackage
6.1.4. Adapted configuration inside metapackages
6.1.5. Documentation packages
6.2. Handling of metapackages
6.2.1. Command line tools
6.2.2. Text user interfaces
6.2.3. Graphical user interfaces
6.2.4. Web interfaces
6.2.5. Future handling of metapackages
6.3. User roles
6.3.1. User menu tools
6.4. Development tools
6.5. Dealing with name space pollution
7. How to start a Debian Pure Blend
7.1. Planning to form a Debian Pure Blend
7.1.1. Leadership
7.1.2. Defining the scope of the Blend
7.1.3. Initial discussion
7.2. Setting up
7.2.1. Mailing list
7.2.2. Web space
7.2.3. Repository
7.2.4. Formal announcement
7.2.5. Explaining the project
7.3. Project structure
7.3.1. Sub-setting Debian
7.3.2. Using tasksel and metapackages
7.3.3. Adding new "normal" packages
7.4. First release
7.4.1. Release announcement
7.4.2. Users of a Debian Pure Blend
8. The web sentinel
8.1. Existing and prospective packages
8.2. Tasks files controlling web sentinel content
8.2.1. Configuring Web Sentinel pages per Blend
8.2.2. Debian Description Translation Project
8.2.3. Features of the web sentinel tasks pages
8.3. Bugs overview
8.4. Versions in stable / testing / unstable / new / VCS upstream
8.5. Quality assurance report
9. To do
9.1. Establishing and using communication platforms
9.2. Enhancing visibility
9.2.1. Debian Pure Blends web pages
9.3. Debian Package Tags
9.4. Enhancing basic technologies regarding Debian Pure Blends
9.5. Building Live CDs of each Debian Pure Blend
9.6. New way to distribute Debian
A. Description of development tools
A.1. Package blends-dev
A.1.1. Blend-tasks.desc
A.1.2. debian/control
A.1.3. statusdump
A.1.4. changelogentry
A.1.5. Apt sources.list files in /etc/blends/
A.1.6. Templates in /usr/share/blends/templates
A.2. Package blends-common
A.2.1. blend-role(8)
A.2.2. blend-update-menus(8)
A.2.3. blend-user(8)
A.2.4. blends.conf(5)
A.3. How to develop new normal packages in Pure Blends
A.4. Working with the source repository in Git
A.5. How to create tasks and bugs pages of web sentinel
A.6. Editing static web pages of Blends on blends.debian.org
A.7. Description how Blends relevant data are gathered and stored
A.7.1. Packages in Debian ftp new queue
A.7.2. Machine readable data in Git repositories of Blends and some packaging teams
B. Quick intro into building metapackages
B.1. Defining dependencies for metapackages
B.2. The packaging directory
B.3. The common metapackage
B.4. The metapackage menus
B.5. Menu for any dependency
C. Using the Bug Tracking System
C.1. How to ask for packages which are not yet included
C.2. How to report problems
D. FAQ
D.1. How can I add a dependency?
D.2. What additional information should be provided?
D.3. Should I add binary or source packages?
D.4. Should I add a library package to a user task?
D.5. Can I create a new task if the existing ones do not fit?
D.6. Why not simply use a Wiki?
D.7. Why not simply using DebTags?