[Blends-commit] [SCM] blends-gsoc branch, master, updated. e2497ff793a5f68220ac8fc007f9f378f7f04607
Andreas Tille
tille at debian.org
Sun Nov 24 17:44:45 UTC 2013
The following commit has been merged in the master branch:
commit e2497ff793a5f68220ac8fc007f9f378f7f04607
Author: Andreas Tille <tille at debian.org>
Date: Sun Nov 24 18:43:56 2013 +0100
The XML documentation is moved to the "non-GSoC" Blends Git - just make sure that no competing edits will happen
diff --git a/doc/Makefile b/doc/Makefile
deleted file mode 100644
index fd5669b..0000000
--- a/doc/Makefile
+++ /dev/null
@@ -1,102 +0,0 @@
-## ----------------------------------------------------------------------
-## Makefile : makefile for docbook-xml
-## ----------------------------------------------------------------------
-
-## ----------------------------------------------------------------------
-## Document definitions
-doc_lang := en
-doc_name := debian-blends
-doc_xml := $(shell for l in $(doc_lang); do echo $(doc_name).$$l.xml; done)
-sources := $(shell find . -name "*.xml")
-doc_pdf := $(shell for l in $(doc_lang); do echo $$l/pdf/$(doc_name).$$l.pdf; done)
-doc_ps := $(shell for l in $(doc_lang); do echo $$l/ps/$(doc_name).$$l.ps; done)
-doc_dvi := $(shell for l in $(doc_lang); do echo $$l/dvi/$(doc_name).$$l.dvi; done)
-
-doc_txt := $(shell for l in $(doc_lang); do echo $$l/txt/$(doc_name).$$l.txt; done)
-#this needed cause xmlto txt does not include section numbering by default
-doc_txt_params := --stringparam section.autolabel=1 --stringparam section.label.includes.component.label=1
-
-doc_html := $(shell for l in $(doc_lang); do echo $$l/html/index.html; done)
-pkg := blends-doc
-
-doc_html_en := en/html
-doc_pdf_en := en/pdf/debian-blends.en.pdf
-
-## ----------------------------------------------------------------------
-## General definitions
-LN := /bin/ln -sf
-RMR := /bin/rm -fr
-LOCALE := unset LC_ALL; unset LANG; unset LANGUAGE;
-
-## ----------------------------------------------------------------------
-# this can and will be overriden by a higher level makefile
-PUBLISHDIR := alioth.debian.org:/srv/alioth.debian.org/chroot/home/groups/blends/htdocs/blends
-
-# There is no difference between letter and a4, but a2 for instance works
-PAPERSIZE := a4
-
-## ----------------------------------------------------------------------
-## Targets
-all: html
-
-validate: $(doc_xml)
- for f in $(doc_xml); do \
- xmllint --valid --noout $$f; \
- done
-
-html: $(doc_html)
-
-$(doc_html) $(doc_html_en): $(doc_xml) $(sources)
- for l in $(doc_lang); do \
- f=$(doc_name).$$l.xml; d=$$l/html; \
- mkdir -p $$d; \
- $(LOCALE) xmlto -o $$d -x $(doc_name).xsl html $$f; \
- done
-
-txt $(doc_txt): $(doc_xml)
- for l in $(doc_lang); do \
- f=$(doc_name).$$l.xml; d=$$l/txt; \
- mkdir -p $$d; \
- $(LOCALE) xmlto $(doc_txt_params) -o $$d txt $$f; \
- done
-
-ps $(doc_ps): $(doc_xml)
- for l in $(doc_lang); do \
- f=$(doc_name).$$l.xml; d=$$l/ps; \
- mkdir -p $$d; \
- $(LOCALE) xmlto -o $$d --with-dblatex ps $$f; \
- done
-
-
-pdf $(doc_pdf) $(doc_pdf_en): $(doc_xml)
- for l in $(doc_lang); do \
- f=$(doc_name).$$l.xml; d=$$l/pdf; \
- mkdir -p $$d; \
- $(LOCALE) xmlto -o $$d --with-dblatex pdf $$f; \
- done
-
-
-dvi $(doc_dvi): $(doc_xml)
- for l in $(doc_lang); do \
- f=$(doc_name).$$l.xml; d=$$l/dvi; \
- mkdir -p $$d; \
- $(LOCALE) xmlto -o $$d --with-dblatex dvi $$f; \
- done
-
-
-publish: $(doc_html_en) $(doc_pdf_en)
- rsync -azult --delete $(doc_html_en)/*.html $(PUBLISHDIR)
- rsync -azult $(doc_pdf_en) $(PUBLISHDIR)
-
-clean:
- for l in $(doc_lang); do \
- for d in html pdf txt ps dvi info; do \
- $(RMR) $$l/$$d; \
- done; \
- done
- find . -name "*~" -exec $(RMR) {} \;
-
-distclean:
- make clean
-
-.PHONY: all publish clean distclean validate
diff --git a/doc/debian-blends.en.xml b/doc/debian-blends.en.xml
deleted file mode 100644
index 6a2733c..0000000
--- a/doc/debian-blends.en.xml
+++ /dev/null
@@ -1,40 +0,0 @@
-<?xml version='1.0' ?>
-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V5.0a1//EN"
- "/usr/share/xml/docbook/schema/dtd/4.5/docbookx.dtd" [
-
- <!-- textual data entities -->
- <!ENTITY titletoc SYSTEM "en/00_titletoc.xml">
- <!ENTITY ch-introduction SYSTEM "en/01_introduction.xml">
- <!ENTITY ch-about SYSTEM "en/02_about.xml">
- <!ENTITY ch-general-ideas SYSTEM "en/03_general_ideas.xml">
- <!ENTITY ch-existing-blends SYSTEM "en/04_existing_blends.xml">
- <!ENTITY ch-inside SYSTEM "en/05_inside.xml">
- <!ENTITY ch-technology SYSTEM "en/06_technology.xml">
- <!ENTITY ch-starting SYSTEM "en/07_starting.xml">
- <!ENTITY ch-websentinel SYSTEM "en/08_websentinel.xml">
- <!ENTITY ch-todo SYSTEM "en/09_todo.xml">
- <!ENTITY ap-devel SYSTEM "en/A_devel.xml">
- <!ENTITY ap-quickintro SYSTEM "en/B_quickintro.xml">
- <!ENTITY ap-bts SYSTEM "en/C_bts.xml">
-
-
-]>
-
-<book id="debiandoc-xml">
- &titletoc;
-
- &ch-introduction;
- &ch-about;
- &ch-general-ideas;
- &ch-existing-blends;
- &ch-inside;
- &ch-technology;
- &ch-starting;
- &ch-websentinel;
- &ch-todo;
-
- &ap-devel;
- &ap-quickintro;
- &ap-bts;
-
-</book>
\ No newline at end of file
diff --git a/doc/debian-blends.xsl b/doc/debian-blends.xsl
deleted file mode 100644
index ede2348..0000000
--- a/doc/debian-blends.xsl
+++ /dev/null
@@ -1,13 +0,0 @@
-<?xml version='1.0'?>
-<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
-<xsl:import href="/usr/share/xml/docbook/stylesheet/docbook-xsl/html/docbook.xsl"/>
-<xsl:import href="/usr/share/xml/docbook/stylesheet/docbook-xsl/html/chunk.xsl"/>
-
-<xsl:param name="chapter.autolabel" select="1"/>
-<xsl:param name="section.autolabel" select="1"/>
-<xsl:param name="section.label.includes.component.label" select="1"/>
-
-<xsl:param name="chunk.first.sections" select="0"/>
-<xsl:param name="chunk.section.depth" select="0"/>
-
-</xsl:stylesheet>
\ No newline at end of file
diff --git a/doc/en/00_titletoc.xml b/doc/en/00_titletoc.xml
deleted file mode 100644
index 4022394..0000000
--- a/doc/en/00_titletoc.xml
+++ /dev/null
@@ -1,78 +0,0 @@
-<bookinfo>
- <title>Debian Pure Blends</title>
-
- <author>
- <firstname>Andreas</firstname>
- <surname>Tille</surname>
- <affiliation>
- <address>
- <email>tille at debian.org</email>
- </address>
- </affiliation>
- </author>
-
- <revhistory>
- <revision>
- <revnumber>v1</revnumber>
- <date>19 Jun 2013</date>
- <!--<authorinitials></authorinitials>
- <revremark></revremark> -->
- </revision>
- </revhistory>
-
- <copyright>
- <year>2004 - 2013</year> <holder>Andreas Tille, Ben Armstrong, Emmanouil Kiagias</holder>
- </copyright>
-
- <legalnotice>
- <title>Copyright</title>
- <para>
- 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.
- </para>
-
- <para>
- This is distributed in the hope that it will be useful, but
- <emphasis>without any warranty</emphasis>; without even the implied warranty
- of merchantability or fitness for a particular purpose. See the
- GNU General Public License for more details.
- </para>
-
- <para>
- A copy of the GNU General Public License is available
- on the World Wide Web at <ulink url="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.
- </para>
-
- <para>
- You can find the source of this article
- <ulink url="http://git.debian.org/?p=blends/blends.git;a=tree;f=doc/en">in the Git repository at git.debian.org</ulink>.
- It is also available as Debian package <package>blends-doc</package>.
- </para>
-
- <para>
- A <ulink url="debian-blends.en.pdf">printable version in PDF format</ulink> will be built
- from time to time.
- </para>
- </legalnotice>
-
- <abstract>
- <para>
- 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.
- </para>
- </abstract>
-</bookinfo>
\ No newline at end of file
diff --git a/doc/en/01_introduction.xml b/doc/en/01_introduction.xml
deleted file mode 100644
index ea903de..0000000
--- a/doc/en/01_introduction.xml
+++ /dev/null
@@ -1,63 +0,0 @@
-<chapter id="introduction">
-
- <title>Introduction</title>
-
-<para>
- A general purpose operating system like Debian can be the
- perfect solution for many different problems. Whether
- you want Debian to work for you in the classroom, as a
- games machine, or in the office, each problem area has its
- own unique needs and requires a different subset of
- packages tailored in a different way.
-</para>
-
-<para>
- Debian Pure Blends
- provide support for special user interests. They implement a new
- approach to cover interests of specialised users, who might be
- children, lawyers, medical staff, visually impaired people, etc. Of
- late, several Debian Pure Blends have evolved. The common goal of
- those is to make installation and administration of computers for
- their target users as easy as possible, and to serve in the role as
- the missing link between software developers and users well.
-</para>
-
-<para>
- To clarify the relation between a Blend and a derivative which is
- frequently mixed up Ben Armstrong said in a
- <ulink url="http://lists.debian.org/debian-blends/2011/07/msg00010.html">
- discussion on the Blends mailing list</ulink>:
- "While a Blend strives to mainstream with Debian, a derivative
- strives to differentiate from Debian."
-</para>
-
-<para>
- Using the object oriented approach as an analogy, if Debian as a whole
- is an object, a Debian Pure Blend is an instance of this object that
- inherits all features while providing certain properties.
- </para>
-
-<para>
- So the Debian project releases the Debian Distribution which
- includes several Blends. In contrast to this, there might be some
- other Debian related Projects, either external or non-official, which
- may create "derivative distributions". But these are not the
- responsibility of the Debian project.
-</para>
-
-<para>
- A word of warning: The fact that a Blend covering a certain field of
- work does exist does not mean that it might be a complete drop in
- replacement of Free Software solutions for all tasks in this specific
- field. Some Blends just started to work on this and adopted the
- technical framework to formalise the work on the project but it might
- perfectly happen that there is just a lack of available Free Software
- solutions for certain tasks. Debian can do less about this because we
- just assemble a set of software which was developed outside the Debian
- GNU/Linux distribution. So it has to be checked whether a specific
- Blend is fit for the intended purpose, whether it might cover just
- some parts of a fields of work or whether it is just a concept to develop
- some solutions for the future.
-</para>
-
-</chapter>
\ No newline at end of file
diff --git a/doc/en/02_about.xml b/doc/en/02_about.xml
deleted file mode 100644
index df8f57f..0000000
--- a/doc/en/02_about.xml
+++ /dev/null
@@ -1,365 +0,0 @@
-<chapter id="about">
-
- <title>What are Debian Pure Blends?</title>
-
-<sect1 id="debian">
- <title>What is Debian?</title>
-
-<para>
- The core of an operating system is a piece of software that interacts
- with the hardware of the computer, and provides basic functionality
- for several applications. On Linux based systems, the so-called
- kernel provides this functionality, and the term Linux just means
- this core without those applications that provide the functionality
- for users. Other examples are the Hurd, or the flavours of the BSD
- kernel.
-</para>
-
-<para>
- Many applications around UNIX-like kernels are provided by the
- <ulink url="http://www.gnu.org/">GNU</ulink> system. That is why Linux based
- operating systems are described as GNU/Linux systems. The GNU tools
- around the Linux kernel build a complete operating system.
-</para>
-
-<para>
- Users do not need only an operating system. They also need certain
- applications like web servers, or office suites. A
- <emphasis>distribution</emphasis> is a collection of software packages around the
- GNU/Linux operating system that satisfies the needs of the target
- user group. There are general distributions, which try to support
- all users, and there are several specialised distributions, which
- each target a special group of users.
-</para>
-
-<para>
- <emphasis>Distributors</emphasis> are those companies that are building these
- collections of software around the GNU/Linux operating system.
- Because it is Free Software, the user who buys a distribution pays
- for the service that the distributor is providing. These services
- might be:
-
-<itemizedlist>
- <listitem>
- <para>Preparing a useful collection of software around GNU/Linux.</para>
- </listitem>
- <listitem><para>Caring for smooth installation that the target user is able to
- manage.</para>
- </listitem>
- <listitem>
- <para>Providing software updates and security fixes.</para>
- </listitem>
- <listitem>
- <para>Writing documentation and translations to enable the user to use
- the distribution with maximum effect.</para>
- </listitem>
- <listitem><para>Selling Boxes with ready to install CDs and printed
- documentation.</para>
- </listitem>
- <listitem>
- <para>Offering training and qualification.</para>
- </listitem>
- </itemizedlist>
-
-</para>
-
-<para>
- Most distributors ship their distribution in binary packages. Two
- package formats are widely used:
-
- <variablelist>
- <varlistentry>
- <term>RPM (RedHat Package Manager)</term>
- <listitem>
- <para>which is supported by RedHat, SuSE, Mandriva and others.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>DEB (Debian Package)</term>
- <listitem>
- <para>used by Debian and derived distributions.</para>
- </listitem>
- </varlistentry>
- </variablelist>
-
- All GNU/Linux distributions have a certain amount of common ground,
- and the <ulink url="http://www.linuxbase.org/">Linux Standard Base</ulink>
- (LSB) is attempting to develop and promote a set of standards
- that will increase compatibility among Linux distributions, and enable
- software applications to run on any compliant system.
-</para>
-
-<para>
- The very essence of any distribution, (whether delivered as RPMs, DEBs,
- Source tarballs or ports) is the choice of <emphasis>policy statements</emphasis>
- made (or not made, as the case may be) by the creators of the distribution.
-</para>
-
-<para>
- <emphasis>Policy statements</emphasis> in this sense are things like
- "configuration files live in
- <filename>/etc/$package/$package.conf</filename>, logfiles go to
- <filename>/var/log/$package/$package.log</filename> and the documentation
- files can be found in <filename>/usr/share/doc/$package</filename>."
-</para>
-
-<para>
- The policy statements are followed by the tool-chains and
- libraries used to build the software, and the lists of dependencies, which
- dictate the prerequisites and order in which the software has to be
- built and installed. (It's easier to ride a bicycle if you put the wheels
- on first. ;-) )
-</para>
-
-<para>
- It is this <emphasis>adherence to policy</emphasis> that causes a distribution
- to remain consistent within its own bounds. At the same time, this is
- the reason why packages can not always be safely installed across
- distribution boundaries. A SuSE <filename>package.rpm</filename> might not
- play well with a RedHat <filename>package.rpm</filename>, although the
- packages work perfectly well within their own distributions. A
- similar compatability problem could also apply to packages from the
- same distributor, but from a different version or generation of the
- distribution.
-</para>
-
-<para>
-<remark>AT: The context is somehow missing here.</remark>
- As you will see later in more detail, Debian Pure Blends are
- just a modified ruleset for producing a modified (specialised)
- version of Debian GNU/Linux.
-</para>
-<para>
- A package management system is a very strong tool to manage software
- packages on your computer. A large amount of the work of a
- distributor is building these software packages.
-</para>
-
-<para>
- Distributors you might know are
- <ulink url="http://www.mandriva.com/">Mandriva</ulink>,
- <ulink url="http://www.redhat.com/">RedHat</ulink>,
- <ulink url="http://www.suse.com/">SuSE</ulink>
- (now owned by <ulink url="http://www.novell.com/linux/">Novell</ulink>)
- and others.
-</para>
-<para>
- <ulink url="http://www.debian.org">Debian</ulink> is just one of them.
-</para>
-
-<para>
-Well, at least this is what people who do not know Debian well might
-think about it. But, in fact, Debian is a different kind of
-distribution ...
-</para>
-
-</sect1>
-
-<sect1 id="whatdebian">
- <title>What is Debian? (next try)</title>
-
-<para>
-The Debian Project is an association of individuals who have made
-common cause to create a free operating system. This operating system
-that we have created is called <emphasis>Debian GNU/Linux</emphasis>,
-or simply Debian for short.
-</para>
-<para>
-Moreover, work is in progress to provide Debian of kernels other than
-Linux, primarily for the Hurd. Other possible kernels are the
-flavours of BSD, and there are even people who think about ports to MS
-Windows.
-</para>
-<para>
-All members of the Debian project are connected in a
-<ulink url="http://people.debian.org/~tille/talks/img/earthkeyring.png">web of trust</ulink>,
-which is woven by signing GPG keys. One requirement to become a
-member of the Debian project is to have a GPG key signed by a Debian
-developer. Every time one Debian developer meets another developer
-for the first time, they sign each other's keys. In this way, the web
-of trust is woven.
-</para>
-
-</sect1>
-
-<sect1 id="difference">
- <title>Differences from other distributions</title>
-
-<para>
-
-<itemizedlist>
- <listitem>
- <para>Debian is not a company, but an organisation.</para>
- </listitem>
- <listitem>
- <para>It does not sell anything.</para>
- </listitem>
- <listitem>
- <para>Debian members are volunteers.</para>
- </listitem>
- <listitem>
- <para>Maintainers are working on the common goal:
- to build the best operating system they can achieve.
- </para>
- </listitem>
- <listitem>
- <para>Debian maintains the largest collection of ready-to-install Free
- Software on the Internet.</para>
- </listitem>
- <listitem>
- <para>There are two ways to obtain Debian GNU/Linux:</para>
- <orderedlist>
- <listitem>
- <para>Buy it from some <emphasis>other</emphasis> distributor on
- CD. Perhaps the correct term would be
- <emphasis>re</emphasis>distributor. Because Debian is free, anybody can
- build his own distribution based on it, sell CDs, and even
- add new features, such as printed documentation, more software,
- support for different installers and more.
- </para>
- </listitem>
- <listitem>
- <para>Download Debian from the web for free.</para>
- </listitem>
- </orderedlist>
- <para>The latter is the common way, and there are really great tools
- to do it this way. Certainly it is always possible to copy Debian
- from a friend.
- </para>
- </listitem>
-</itemizedlist>
-
-</para>
- </sect1>
-
-<sect1 id="Blends">
- <title>Debian Pure Blends</title>
-
-<para>
-Debian contains nearly 22.000 binary packages, and this number is
-constantly increasing. There is no single user who needs all these
-packages (even if conflicting packages are not considered).
-</para>
-<para>The normal user is interested in a subset of these packages. But
-how does the user find out which packages are really interesting?
-</para>
-<para>
-One solution is provided by the <package>tasksel</package> package.
-It provides a reasonable selection of quite general tasks that can be
-accomplished using a set of packages installed on a Debian GNU/Linux
-system. But this is not really fine grained, and does not address all
-of the needs of user groups with special interests.
-</para>
-<para>
-<emphasis>Debian Pure Blends</emphasis> - in short Blends if used clearly in the
-Debian internal context which makes "Pure" and "Debian" obvious -
-which were formerly known as Custom Debian Distributions (this name
-was confusing because it left to much room for speculation that this
-might be something else than Debian) try to provide a solution for
-<emphasis>special groups of target users with different skills and
-interests</emphasis>. Not only do they provide handy collections of specific
-program packages, but they also ease installation and configuration
-for the intended purpose.
-</para>
-<para>
-Debian Pure Blends are <emphasis>not forks</emphasis> from Debian. As the
-new name says clearly they are pure Debian and just provide a specific
-flavour. So if you obtain the complete Debian GNU/Linux distribution,
-you have all available Debian Pure Blends included.
-</para>
-<para>
-The concept of what is called <emphasis>Blend</emphasis> in Debian is also known
-in other distributions. For instance in Fedora there are
-<ulink url="http://fedoraproject.org/wiki/SIGs">Special Interest Groups (SIGs)</ulink>
-even if some SIGs in Fedora are what in Debian is known as interntal
-project because it is focussed on technical implementetions and not
-on user oriented applications.
-</para>
-</sect1>
-
-<sect1>
- <title>Difference between a Blend and a remastered system</title>
-
-<para>
-Not necessarily all currently existing Blends are actually providing
-installation media (live media or installer). The reason for this is
-that such installation media are not always necessary / wanted. You
-can just install plain Debian and install some metapackages on top of it.
-However, the metapackage approach makes the creation of installation
-media quite simple by using
-<ulink url="http://live.debian.net/">Debian Live</ulink>.
-Here are some reasons for this approach compared to a remastering
-strategy.
-</para>
-
-<sect2>
- <title>Technical</title>
- <para>
- The process for creation of a blend involves starting with a Debian or
- derivative repository and creating an image directly from that (live,
- install or otherwise) that contains a selection of material from that
- repository delivered in such a way that it is usable by a particular
- target user for a particular purpose with a minimum of effort.
- </para>
- <para>
- By contrast, the process of remastering generally involves first
- downloading an image produced by the parent distro (live, install or
- otherwise,) then tearing it apart and reassembling it with your
- customizations applied.
- </para>
-</sect2>
-
-<sect2>
- <title>Philosophical</title>
- <para>
- The blends philosophy is to work as closely with the parent distro as
- possible. If possible, the project should be done entirely within the
- distro as a subproject, containing only material supplied by the parent
- distro. We call this a "Pure Blend".
- </para>
- <para>
- The remastering philosophy (if it can be called that) seems to be
- "whatever works" and involves little or no interaction with the parent
- distro. It's a lazy approach used by people who have newly discovered
- that they can hack images to make them into custom images to make
- something uniquely theirs. Probably fine for quick-and-dirty results,
- but hard to support in the long run.
- </para>
- <para>
- The users of a blend are served better than the users of a
- remaster because of the following advantages:
- </para>
-
- <sect3>
- <title>Technical advantage</title>
- <para>
- A new version of a well-crafted blend ought to be able to be produced at
- any time directly from the repository simply by building it; the user
- has some assurance that the resulting system remains 'untainted' by
- hacking it up with scripts that 'damage' the original system by removing
- files from packages, changing files in packages, etc. something that
- hurts maintainability / support for such a system.
- </para>
- </sect3>
-
- <sect3>
- <title>Community advantage</title>
- <para>
- A blend project aims to leverage support resources from the existing
- community to serve some sub-community within it. They accomplish this by
- not violating Debian packaging policy, producing something that is
- either pure Debian (a "pure blend") or Debian + additional packages,
- rather than some frankendistro artlessly stitched together from someone
- else's distro with scripts that change things everywhere with no regard
- to policy. Thus, normal support channels can be used with a pure blend
- since what you end up with is not a derivative at all, but just Debian,
- set up and ready to go for whatever you wanted to use it for.
- </para>
- </sect3>
-
-</sect2>
-
-</sect1>
-
-</chapter>
\ No newline at end of file
diff --git a/doc/en/03_general_ideas.xml b/doc/en/03_general_ideas.xml
deleted file mode 100644
index 2d278b8..0000000
--- a/doc/en/03_general_ideas.xml
+++ /dev/null
@@ -1,270 +0,0 @@
-<chapter id="general">
- <title>General ideas</title>
- <sect1 id="lookbeyond">
- <title>Looking beyond</title>
- <para>
- Commercial Linux distributors sell certain products that try to
- address special user needs.
-
- <variablelist><varlistentry><term>Enterprise solutions</term><listitem><itemizedlist><listitem><para>Corporate Server - Mandriva</para></listitem><listitem><para>Advanced Server - RedHat</para></listitem><listitem><para>Enterprise Server - SuSE</para></listitem></itemizedlist></listitem></varlistentry><varlistentry><term>Small Office and Home Office (SOHO)</term><listitem><para>There are a couple of workstation or home editions, as well as
- office desktops built by several GNU/Linux distributors.
- </para></listitem></varlistentry><varlistentry><term>Special task products</term><listitem><variablelist><varlistentry><term>Mail server</term><listitem><para>SuSE Linux Openexchange Server</para></listitem></varlistentry><varlistentry><term>Firewall</term><listitem><para>Multi Network Firewall - Mandriva, SuSE Firewall on CD,
- ...</para></listitem></varlistentry><varlistentry><term>Cluster</term><listitem><para>Mandriva Clustering</para></listitem></varlistentry><varlistentry><term>Content Management System</term><listitem><para>RedHat</para></listitem></varlistentry><varlistentry><term>Portal Server</term><listitem><para>RedHat</para></listitem></varlistentry></variablelist></listitem></varlistentry></variablelist>
-
-This is only a small set of examples of commercial GNU/Linux
-distributors addressing specific user interests with certain products.
-</para>
- <para>
-Debian solves this problem with <emphasis>Debian Pure Blends</emphasis>.
-</para>
- </sect1>
- <sect1 id="motivation">
- <title>Motivation</title>
- <sect2 id="userprofile">
- <title>Profile of target users</title>
- <para>
-The target user of a Blend may be a specialist of a certain
-profession, (e.g. a doctor or lawyer,) a person who has not (yet)
-gathered a certain amount of computer knowledge, (e.g. a child,) or a
-person with disabilities (e.g. a visually or hearing impaired
-person.) Moreover, the customisation might deal with peculiarities of
-certain regions where users have needs that differ from Debian as a
-whole.
-</para>
- <para>
-It is not unusual for these target users to be less technically
-competent than the stereotypical Linux user. These people are often
-not interested in the computer for its own sake, but just want it to
-work for them. Imagine the frustration of a doctor who has to move
-the focus of interest from the patient to his stupid computer that
-does not work as expected.
-</para>
- <para>
-Because of limited knowledge or time, the target user is usually
-unable to install upstream programs. This means that in the first
-place, they must find out which software packages in their
-distribution might serve for a certain problem. The next step would
-be to download and install the packages they choose, perhaps requiring
-a certain amount of configuration effort. This problem is nearly
-impossible for a user with limited technical competence and perhaps
-poor English language comprehension, which prevents the user from
-understanding the installation manual.
-</para>
- <para>
-The language barrier in this field is an important issue, because we
-are targeting everyday users who are not compelled to learn English,
-like Free Software developers are, for everyday communication. So the
-installation process has to involve the least possible user
-interaction, and any such interaction has to be internationalised.
-</para>
- <para>
-Furthermore, most target users have no or little interest in
-administration of their computer. In short, the optimal situation
-would be that he would not even notice the existence of the computer,
-but just focus on using the application to accomplish the task at
-hand.
-</para>
- <para>
-Common to all groups of target users is their interest in a defined
-subset of available Free Software. None of them would like to spend
-much time searching for the package that fits his interest. Instead,
-the target user would prefer to immediately and effortlessly locate
-and access all material relevant to solving his own problems.
-</para>
- <para>
-There is an absolute need for easy usage of the programs. This is not
-to say users expect to not have to learn to use the software. Adults
-generally accept that they must spend a reasonable amount of time in
-learning how to use a piece of software before they can do something
-useful and productive with it. But a simple-to-learn environment
-greatly enhances the value of the software, and if you consider
-children as target users, they just want to start using it right away
-without reading any documentation.
-</para>
- <para>
-The more important part of the request for easy usage is a
-professional design that is functional and effective. To accomplish
-this, the programmers need expert knowledge, or at least a quick
-communication channel to experts to learn more about their
-requirements. One task for Debian Pure Blends is to bring programmers
-and experts who will use those special programs together.
-</para>
- <para>
-Last, but not least, we find certain requirements beyond just which
-packages are provided in each target user group. These may differ
-between different Blends. For instance, while a doctor has to protect
-his database against snooping by outside attackers, the privacy risk
-for a child's system are of lesser importance. Thus, the Debian
-Junior project cares more for ensuring that the user himself does not
-damage the desktop environment while playing around with it than about
-remote attacks. So we find a "defined security profile" for each
-single Blend.
-</para>
- </sect2>
- <sect2 id="adminprofile">
- <title>Profile of target administrators</title>
- <para>
-In the field that should be covered by Debian Pure Blends, we have to
-face also some common problems for system administrators. Often they
-have limited time in which they must serve quite a number of
-computers, and thus they are happy about each simplification of the
-administration process. The time required to make special adaptations
-for the intended purpose has to be reduced to a minimum.
-</para>
- <para>
-So, administrators are looking for timesaving in repetitive tasks.
-While this is a common issue for each general GNU/Linux distribution,
-this could have certain consequences in the special fields Debian Pure
-Blends want to address.
-</para>
- <para>
-Another problem administrators face is that they are often not experts in
-their clients' special field of work. Thus, they may need some specialist
-knowledge to explain the use of special programs to their users, or at
-least need to be able to communicate well with the experts about their
-special needs, and how the software can be used to address them.
-</para>
- </sect2>
- </sect1>
- <sect1 id="status">
- <title>Status of specialised Free Software</title>
- <para>
-Programs like a web server, or a mail user agent are used by many
-different users. That is why many gifted programmers feel obliged for
-this kind of Free Software - they just need it for their own. So you
-normally find a fast, growing community around Free Software packages
-that have a wide use. This is different for specialised software.
-</para>
- <para>
-In this context, the term "specialised software" refers to the kind of
-software that is needed by some experts for their job. This might be
-a practice management system that is used by doctors, a graphical
-information system (GIS) that is used by geographers, a screen reader
-that helps blind people to work with the computer, etc. The
-difference between such software and widely used software like office
-suites is that the user base is relatively small. This is also true
-for certain software that supports special localisation issues.
-
-<itemizedlist><listitem><para>
- Specialist software is used only by a limited set of users (i.e. the
- specialists). There exists a set of software tools that work
- perfectly in the environment where they were developed. If the
- developers catch the idea of Free Software, and just release this
- software as-is, people in the new, broader user community often run
- into trouble getting it to work in their environment. This happens
- because the developers did not really care about a robust installation
- process that works outside their special environment. As well,
- installation instructions are often badly written, if they exist at
- all. But these problem can be easily solved by shipping the software
- as policy-compliant binary packages, which not only ease installation,
- but also require documentation to be included. Thus, mere inclusion
- in Debian benefits the whole user base of any specialised software.
- </para></listitem><listitem><para>
- The trouble often continues in the maintenance of the installed
- software.
- </para></listitem><listitem><para>
- When it comes to the usage of the specialist software, it often
- happens that it perfectly fits the needs of the developer who wrote it
- for his own purposes, and who is familiar with its quirks, but in many
- cases such software does not comply with ergonomic standards of user
- interfaces.
- </para></listitem><listitem><para>
- Several existing programs that might be useful for specialists are not
- really free in the sense of
- the <ulink url="http://www.debian.org/social_contract#guidelines">
- Debian Free Software Guidelines (DFSG)</ulink>. Programs that are
- incompatible with the DFSG cannot be included in Debian. This is
- possibly a drawback for those programs, because they could profit by
- spreading widely on the back of Debian over the whole world.
- </para></listitem><listitem><para>
- A certain number of programs are developed at universities by students
- or graduates. Once these people leave the university, the programs
- they developed might be orphaned; <emphasis>i.e.</emphasis>, not actively
- maintained anymore. If their licenses are too restrictive, it may be
- impossible for anyone else to take over; sticking to
- <remark>AT: We should find a way to avoid printing the URL in PDF output.</remark>
- <ulink url="http://www.debian.org/social_contract#guidelines">
- DFSG</ulink>-free licenses avoids that problem.
- </para></listitem><listitem><para>
- In special fields, often "typical" (not necessarily Intel-based)
- hardware architectures are used. Debian currently runs on 11
- different architectures, and automatic build servers normally compile
- software packages as necessary. If auto-builders for other
- architectures show problems, Debian maintainers will normally fix
- them, and send the original authors a patch. Moreover, users can
- report run-time problems via the
- <ulink url="http://www.debian.org/Bugs/">Debian Bug Tracking System</ulink>.
- </para></listitem><listitem><para>
- Many programs that are written from scratch use their own non-standard
- file formats. However, it is often important for programs to be able
- to share data with each other.
- </para></listitem><listitem><para>
- Often there are several programs that try to solve identical or
- similar problems. For instance the Debian Med team faces this in the
- case of programms claiming to serve as a medical practice management
- solution. Normally, all these programs
- take very interesting approaches but all of them have certain
- drawbacks. So, joining programmers' forces might make sense here.
- </para></listitem><listitem><para>
- Sometimes the tools or back-ends used in Free Software are not
- appropriate for such applications. For instance, sometimes
- database servers that do not use transactions are used to store
- medical records, which is completely unacceptable. Other programs use web
- clients as their front-end, which is not really good for quick (mouse-less)
- usage, a great shortcoming for repetitive tasks.
- </para></listitem></itemizedlist>
-
-</para>
- </sect1>
- <sect1 id="general_problem">
- <title>General problem</title>
- <para>
-Free Software development is a kind of evolutionary process. It needs a
-critical mass of supporters, who are:
-
-<itemizedlist><listitem><para>programmers <emphasis>and</emphasis></para></listitem><listitem><para>users</para></listitem></itemizedlist>
-
-Because specialised software has a limited set of users, (specialists,)
-this results in a limited set of programmers.
-</para>
- <para>
-Debian wants to attract both groups to get it working.
-</para>
- <para>
- <emphasis>Debian is the missing link between upstream developers and users.</emphasis>
- </para>
- </sect1>
- <sect1 id="philosophy">
- <title>Debian Pure Blends from philosophical point of view</title>
- <para>
-Debian currently grows in several directions:
-
-<itemizedlist><listitem><para>Number of involved people</para></listitem><listitem><para>Number of packages</para></listitem><listitem><para>Number of architectures</para></listitem><listitem><para>Number of bugs</para></listitem><listitem><para>Number of users</para></listitem><listitem><para>Number of derivatives</para></listitem><listitem><para>Time span between releases</para></listitem></itemizedlist>
-
-So several features are changing at different rates their quantity.
-According to Hegel a change of quantity leads into a change in
-quality. That means that Debian will change at a certain point in
-time (or over a certain time span) its quality.
-</para>
- <para>
-"To determine at the right moment the critical point where
- quantity changes into quality is one of the most important and
- difficult tasks in all the spheres of knowledge." (Trotzki) This
- might mean that we just passed the point in time when Debian changed
- its quality. At one point we even observed a change once the package
- pool system was implemented to cope with the increased number of
- packages while trying to reduce the time span between releases. Even
- if the plan to increase the frequencies of releases failed Debian
- became a new quality. People started using the <filename>testing</filename>
- distribution even in production which was not really intended and in
- a consequence even security in <filename>testing</filename> was implemented
- for Sarge.
-</para>
- <para>
-According to Darwin evolution happens through quantitative
-transformations passing into qualitative. So Debian has to evolve and
-to cope with the inner changes and outer requirements to survive in
-the Linux distribution environment.
-</para>
- </sect1>
-</chapter>
diff --git a/doc/en/04_existing_blends.xml b/doc/en/04_existing_blends.xml
deleted file mode 100644
index 41c9b8a..0000000
--- a/doc/en/04_existing_blends.xml
+++ /dev/null
@@ -1,827 +0,0 @@
-<chapter id="existing">
- <title>Existing Debian Pure Blends</title>
-
- <sect1 id="debian-jr">
- <title>Debian Junior: Debian for children from 1 to 99</title>
-
-<para>
-<variablelist>
- <varlistentry>
- <term>Start</term>
- <listitem><para>beginning of 2000</para></listitem>
- </varlistentry>
-
- <varlistentry>
- <term>URL</term>
- <listitem><para><ulink url="http://www.debian.org/devel/debian-jr"></ulink></para></listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Tasks</term>
- <listitem>
- <para>
- <ulink url="http://blends.alioth.debian.org/junior/tasks">Tasks of Debian Jr.</ulink>
- </para></listitem>
- </varlistentry>
-
-<varlistentry>
- <term>Mailing list</term>
- <listitem><para><ulink url="http://lists.debian.org/debian-jr/"> debian-jr at lists.debian.org</ulink></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Initiator</term>
- <listitem><para>Ben Armstrong <email>synrg at debian.org</email></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Activity</term>
- <listitem>
- <para>
- <ulink url="http://blends.debian.net/liststats/authorstat_debian-jr.png">Activists on Debian Jr. mailing list</ulink>
- </para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Release</term>
- <listitem><para>Debian 3.0 (Woody)</para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Goals</term>
- <listitem>
- <itemizedlist>
- <listitem><para>To make Debian an OS that children of all ages will <emphasis>want</emphasis>
- to use, preferring it over the alternatives.</para></listitem>
- <listitem><para>To care for those applications in Debian suitable for children,
- and ensure their quality, to the best of our abilities.</para></listitem>
- <listitem><para>To make Debian a playground for children's enjoyment and
- exploration.</para></listitem>
- </itemizedlist>
- </listitem>
-</varlistentry>
-
-</variablelist>
-The main target is young children. By the time children are teenaged, they
-should be comfortable with using Debian without any special modifications.
-</para>
-
-<para>
-Debian Jr. was the first Blend. In fact, at the time this project was
-created, the idea behind of Debian Pure Blends was born, although
-then, we used the term "Debian Internal Project". Over time, this
-name was changed to "Custom Debian Distributions" first because it was
-too broad, as it was equally descriptive of a number of quite
-different projects, such as IPv6 and QA. The next change of names
-became necessary when it was realised that the term "Custom Debian
-Distribution" was considered as "something else than Debian" by any
-newcomer. This was so misleading that it effectively blocked a wide
-propagation of the principle.
-</para>
-
-<para>
-Debian Jr. not only provides games, but is also concerned about their
-quality from a child's perspective. Thus, games that are regarded as
-not well suited to young children are omitted. Moreover, choices are
-made about which packages are best suited for children to use for
-various other activities and tasks that interest them. This includes,
-for example, simple text processing, web browsing and drawing.
-</para>
-
-</sect1>
-
-
- <sect1 id="debian-med">
- <title>Debian Med: Debian in Health Care</title>
-
-<para>
-
-<variablelist>
-
-<varlistentry>
- <term>Start</term>
- <listitem><para><ulink url="http://lists.debian.org/debian-devel/2002/01/msg01730.html">beginning of 2002</ulink></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>URL</term>
- <listitem><para><ulink url="http://www.debian.org/devel/debian-med">Debian Med</ulink></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Tasks</term>
- <listitem><para><ulink url="http://debian-med.alioth.debian.org/tasks">Tasks of Debian Med</ulink></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Mailing list</term>
- <listitem><para><ulink url="http://lists.debian.org/debian-med/"> debian-med at lists.debian.org</ulink></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Initiator</term>
- <listitem><para>Andreas Tille <email>tille at debian.org</email></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Activity</term>
- <listitem>
- <para><ulink url="http://blends.debian.net/liststats/authorstat_debian-med.png">Activists on Debian Med mailing list</ulink></para>
- <para><ulink url="http://blends.debian.net/liststats/authorstat_debian-med-packaging.png">Activists on Debian Med developer list</ulink></para>
- <!-- authorstats not available
- <para><ulink url="http://blends.debian.net/liststats/authorstat_debian-med-commit.png">Activists on Debian Med commit list</ulink></para>
- //-->
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Release</term>
- <listitem><para>Sarge</para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Goals</term>
- <listitem>
- <itemizedlist>
- <listitem><para>To build an integrated software environment for all medical tasks.</para></listitem>
- <listitem><para>To care especially for the quality of program packages in the field of medicine
- that are already integrated within Debian.</para></listitem>
- <listitem><para>To build and include in Debian packages of medical software that are missing
- in Debian.</para></listitem>
- <listitem><para>To care for a general infrastructure for medical users.</para></listitem>
- <listitem><para>To make efforts to increase the quality of third party Free Software
- in the field of medicine.</para></listitem>
- </itemizedlist>
- </listitem>
-</varlistentry>
-
-</variablelist>
-
-</para>
-
-</sect1>
-
- <sect1 id="debian-edu">
- <title>Debian Edu: Debian for Education</title>
-
-<para>
-<variablelist>
-
-<varlistentry>
- <term>Start</term>
- <listitem><para>Summer of 2002, since 2003 merged with SkoleLinux, which is now
- synonymous with Debian Edu</para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>URL</term>
- <listitem><para><ulink url="http://wiki.debian.org/DebianEdu">Debian Edu Wiki</ulink></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Tasks</term>
- <listitem><para><ulink url="http://blends.alioth.debian.org/edu/tasks">Tasks of Debian Edu</ulink></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Mailing list</term>
- <listitem><para><ulink url="http://lists.debian.org/debian-edu/"> debian-edu at lists.debian.org</ulink></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Activity</term>
- <listitem>
- <para>
- <ulink url="http://blends.debian.net/liststats/authorstat_debian-edu.png">Activists on Debian Edu mailing list</ulink>
- </para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Responsible</term>
- <listitem><para>Petter Reinholdtsen <email>pere at hungry.com</email></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Release</term>
- <listitem><para>Sarge</para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Goals</term>
- <listitem>
- <itemizedlist>
- <listitem><para>To make Debian the best distribution available for educational
- use.</para></listitem>
- <listitem><para>Provide a ready to run classroom installation with free
- educational software. An automatically installed server
- provides net-boot services for disk-less thin clients and
- all necessary applications for educational use.</para></listitem>
- <listitem><para>To federate many initiatives around education, which are
- partly based on forks of Debian.</para></listitem>
- <listitem><para>To continue the internationalisation efforts of SkoleLinux.
- </para></listitem>
- <listitem><para>To focus on easy installation in schools.</para></listitem>
- <listitem><para>To cooperate with other education-related projects (like
- <ulink url="http://schoolforge.net/">Schoolforge</ulink>,
- <ulink url="http://www.ofset.org/">Ofset</ulink>,
- <ulink url="http://edu.kde.org/">KdeEdu</ulink>).</para></listitem>
- </itemizedlist>
- </listitem>
-</varlistentry>
-
-</variablelist>
-
-This project started with the intention to bring back into Debian a fork from
-Debian that was started by some people in France. Because they had some
-time constraints, the people who initially started this effort
-handed over responsibility to the Norwegian <ulink url="http://www.skolelinux.org">Skolelinux</ulink>,
-which is currently more or less identical to Debian Edu.
-</para>
-
-<para>
-The Debian Edu project gathered special interest in Spain because
-there are derived Debian distributions from this country that are
-intended to be used in schools. For instance there are:
- <variablelist>
- <varlistentry>
- <term><ulink url="http://www.linex.org/">LinEX</ulink></term>
- <listitem><para>A Debian derivative distribution used in all schools in
- Extremadura.</para>
- <para>Currently they are joining Debian Edu and by doing so
- becoming fully integrated into Debian. This is a really
- important move because it brings a lot of good software and
- experience back into Debian.
- </para>
- </listitem>
- </varlistentry>
-
- </variablelist>
-</para>
-
-</sect1>
-
- <sect1 id="demudi">
- <title>Debian Multimedia</title>
-
-<para>
-<variablelist>
-
-<varlistentry>
- <term>Start</term>
- <listitem>
- <para>In 2004 there was and effort by DeMuDi to become a Blend but
- this effort seems to have stalled. DeMuDi was part of the
- <ulink url="http://www.agnula.org/">Agnula</ulink> project
- (founded by European Community) and the work somehow was
- taken over by the 64 studio project.
- </para>
- <para>At DebConf 10 in the
- <ulink url="http://penta.debconf.org/dc10_schedule/events/670.en.html">Debian Multimdia BOF</ulink>
- a decision was made to use the Blends stuff for rendering
- web sentinel pages. It was furtherly mentioned that the
- people driving DeMuDi joined the Debian Multimedia packaging
- team so there is now an unique effort to tackle multimedia
- relevant packages.
- </para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>URL</term>
- <listitem><para>
- <ulink url="http://wiki.debian.org/DebianMultimedia">Debian Multimedia</ulink></para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Tasks</term>
- <listitem>
- <para><ulink url="http://blends.alioth.debian.org/multimedia/tasks">Tasks of Debian Multimedia</ulink>
- </para>
-</listitem>
-
-</varlistentry>
-
-<varlistentry>
- <term>Activity</term>
- <listitem>
- <para><ulink url="http://blends.debian.net/liststats/authorstat_pkg-multimedia-maintainers.png">Activists on Debian Multimedia maintainers mailing list</ulink></para>
- <!-- authorstat not availble
- <para><ulink url="http://blends.debian.net/liststats/authorstat_pkg-multimedia-commits.png">Activists on Debian Multimedia commits mailing list</ulink></para>
- //-->
- <para><ulink url="http://blends.debian.net/liststats/authorstat_debian-multimedia.png">Activists on Debian Multimedia user mailing list</ulink></para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Responsible</term>
- <listitem><para>Reinhard Tartler<email>siretart at tauware.de</email></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Goals</term>
- <listitem>
- <itemizedlist>
-
- <listitem><para>Oriented toward audio and video</para></listitem>
- <listitem><para>To make GNU/Linux a platform of choice for the musician
- and the multimedia artist.</para></listitem>
- <listitem><para>Join multimedia forces inside Debian</para></listitem>
-
- </itemizedlist>
-
- </listitem>
-</varlistentry>
-
-</variablelist>
-
-</para>
-</sect1>
-
-<sect1 id="debian-gis">
- <title>Debian GIS: Geographical Information Systems</title>
-
-<para>
-
-<variablelist>
-
-<varlistentry>
- <term>Start</term>
- <listitem><para>
- <ulink url="http://lists.debian.org/debian-devel-announce/2004/10/msg00007.html">October 2004</ulink>
- </para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>URL</term>
- <listitem><para><ulink url="http://wiki.debian.org/DebianGis">DebianGIS Wiki</ulink>
- </para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Tasks</term>
- <listitem>
- <para><ulink url="http://blends.alioth.debian.org/gis/tasks">Tasks of Debian GIS</ulink>
- </para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Mailing list</term>
- <listitem><para><ulink url="http://wiki.debian.org/DebianGis/MailingLists">user and developer list</ulink>
- </para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Activity</term>
- <listitem><para><ulink url="http://blends.debian.net/liststats/authorstat_debian-gis.png">Activists on Debian GIS mailing list</ulink>
- </para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Initiator</term>
- <listitem><para>Francesco P. Lovergine <email>frankie at debian.org</email></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Goals</term>
- <listitem>
- <itemizedlist>
- <listitem><para>Geographical Information Systems</para></listitem>
- <listitem><para><ulink url="http://www.openstreetmap.org">OpenStreetMap</ulink> and GPS devices</para></listitem>
- </itemizedlist>
- </listitem>
-</varlistentry>
-
-</variablelist>
-
-</para>
-
-</sect1>
-
-<sect1 id="debichem">
- <title>DebiChem: Debian for Chemistry</title>
-
-<para>
-
-<variablelist>
-
-<varlistentry>
- <term>Start</term>
- <listitem><para>October 2004</para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>URL</term>
- <listitem><para><ulink url="http://alioth.debian.org/projects/debichem/">Debichem Alioth page</ulink></para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Tasks</term>
- <listitem>
- <para><ulink url="http://blends.alioth.debian.org/debichem/tasks">Tasks of DebiChem</ulink></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Mailing list</term>
- <listitem><para>
- <ulink url="http://lists.alioth.debian.org/mailman/listinfo/debichem-users">debichem-users at lists.alioth.debian.org</ulink>
- </para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Activity</term>
- <listitem>
- <para><ulink url="http://blends.debian.net/liststats/authorstat_debichem-devel.png">Activists on DebiChem mailing list</ulink></para>
- <!-- authorstat not available
- <para><ulink url="http://blends.debian.net/liststats/authorstat_debichem-commits.png">Activists on DebiChem commits list</ulink></para>
- //-->
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Initiator</term>
- <listitem><para>Michael Banck <email>mbanck at debian.org</email></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Goals</term>
- <listitem>
- <itemizedlist>
- <listitem><para>Chemical applications in Debian</para></listitem>
- </itemizedlist>
- </listitem>
-</varlistentry>
-
-</variablelist>
-
-</para>
-
-</sect1>
-
-<sect1 id="debian-science">
- <title>Debian Science: Debian for science</title>
-
-<para>
-<variablelist>
-
-<varlistentry>
- <term>Start</term>
- <listitem><para><ulink url="http://lists.debian.org/debian-devel/2005/07/msg01555.html">July 2005</ulink>
- </para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>URL</term>
- <listitem><para><ulink url="http://wiki.debian.org/DebianScience">Debian Science Wiki</ulink></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Tasks</term>
- <listitem><para><ulink url="http://blends.alioth.debian.org/science/tasks">Tasks of Debian Science</ulink></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Mailing list</term>
- <listitem><para><ulink url="http://lists.debian.org/debian-science/">debian-science at lists.debian.org</ulink></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Activity</term>
- <listitem>
- <para><ulink url="http://blends.debian.net/liststats/authorstat_debian-science.png">Activists on Debian Science mailing list</ulink></para>
- <para><ulink url="http://blends.debian.net/liststats/authorstat_debian-science-maintainers.png">Activists on Debian Science maintainers list</ulink></para>
- <!-- authorstat not available
- <para><ulink url="http://blends.debian.net/liststats/authorstat_debian-science-commits.png">Activists on Debian Science commits list</ulink></para>
- //-->
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Responsible</term>
- <listitem><para>Sylvestre Ledru <email>sylvestre at debian.org</email></para></listitem>
-</varlistentry>
-
-</variablelist>
-</para>
-
-<para>
- While there are Debian Pure Blends that care for certain sciences
- (Debian Med deals in a main part with Biology, DebiChem for
- Chemistry and Debian GIS for geography) not all sciences are covered
- by a specific Blend. The main reason is that at the moment not
- enough people support such an effort for every science. The
- temporary solution was to build a general Debian Science Blend that
- makes use of the work of other Blends in case it exists.
-</para>
-</sect1>
-
- <sect1 id="accessibility">
- <title>Debian Accessibility Project</title>
-
-<para>
-Debian for blind and visually impaired people
-
-<variablelist>
-
-<varlistentry>
- <term>Start</term>
- <listitem><para>February 2003</para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Mailing list</term>
- <listitem><para><ulink url="http://lists.debian.org/debian-accessibility/">debian-accessibility at lists.debian.org</ulink></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>URL</term>
- <listitem><para><ulink url="http://www.debian.org/devel/debian-accessibility/">Debian Accessibility</ulink></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Tasks</term>
- <listitem><para><ulink url="http://blends.alioth.debian.org/accessibility/tasks">Tasks of Debian Accessibility</ulink></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Activity</term>
- <listitem><para><ulink url="http://blends.debian.net/liststats/authorstat_debian-accessibility.png">Activists on Debian Accessibility mailing list</ulink></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Initiator</term>
- <listitem><para>Mario Lang <email>mlang at debian.org</email></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Goals</term>
- <listitem>
- <itemizedlist>
- <listitem><para>To make Debian accessible to people with disabilities.</para></listitem>
-
- <listitem><para>To take special care for: Screen readers; Screen magnification programs;
- Software speech synthesisers; Speech recognition software; Scanner drivers
- and OCR software; Specialised software like edbrowse (web-browse in the
- spirit of line-editors)</para>
- </listitem>
- <listitem><para>To make text-mode interfaces available.</para></listitem>
- <listitem><para>To provide screen reader functionality during installation.</para></listitem>
- </itemizedlist>
- </listitem>
-</varlistentry>
-
-</variablelist>
-
-</para>
-</sect1>
-
-
-<sect1 id="stalled-blends">
- <title>Blends that were announced but development is stalled</title>
-
- <sect2 id="debian-desktop">
- <title>Debian Desktop: Debian GNU/Linux for everybody</title>
-
-<para>
-Motto: "Software that Just Works".
-
-<variablelist>
-
-<varlistentry>
- <term>Start</term>
- <listitem><para>October 2002</para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>URL</term>
- <listitem><para><ulink url="http://www.debian.org/devel/debian-desktop">Debian Desktop</ulink></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Mailing list</term>
- <listitem><para><ulink url="http://lists.debian.org/debian-desktop/"> debian-desktop at lists.debian.org</ulink></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Activity</term>
- <listitem><para><ulink url="http://blends.debian.net/liststats/authorstat_debian-desktop.png">Activists on Debian Desktop mailing list</ulink></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Initiator</term>
- <listitem><para>Colin Walters <email>walters at debian.org</email></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Goals</term>
- <listitem>
- <itemizedlist>
- <listitem><para>To try to build the best possible operating system for home
- and corporate workstation use.</para></listitem>
- <listitem><para>To ensure desktops like GNOME and KDE coexist well in Debian and
- work optimally.</para></listitem>
- <listitem><para>To balance ease of use for beginners with flexibility
- for experts.</para></listitem>
- <listitem><para>To make the system easy to install and configure (e.g. via
- hardware-detection).</para></listitem>
- </itemizedlist>
- </listitem>
-</varlistentry>
-
-</variablelist>
-
-This Blend has many common issues with other Blends. The latest move
-of Debian Desktop was to care about more up to date software that can
-be used as common base for all Debian Pure Blends. The
-common interest is described in detail in <xref linkend="new_ways_of_distribution"/>. Unfortunately since about 2004 the
-project is really silent and it might be considered dead now.
-</para>
-</sect2>
-
- <sect2 id="debian-lex">
- <title>Debian Lex: Debian GNU/Linux for Lawyers</title>
-
-<para>
-<variablelist>
-
-<varlistentry>
- <term>Start</term>
- <listitem><para>April 2003</para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>URL</term>
- <listitem><para><ulink url="http://www.debian.org/devel/debian-lex">Debian Lex</ulink></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Tasks</term>
- <listitem><para><ulink url="http://blends.alioth.debian.org/lex/tasks">Tasks of Debian Lex</ulink></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Mailing list</term>
- <listitem><para><ulink url="http://lists.debian.org/debian-lex/"> debian-lex at lists.debian.org</ulink></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Activity</term>
- <listitem><para><ulink url="http://blends.debian.net/liststats/authorstat_debian-lex.png">Activists on Debian Lex mailing list</ulink></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Initiator</term>
- <listitem><para>Jeremy Malcolm <email>Jeremy at Malcolm.id.au</email></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Goals</term>
- <listitem>
- <itemizedlist>
- <listitem><para>To build a complete system for all tasks in legal
- practice.</para></listitem>
- <listitem><para>To add value by providing customised templates for lawyers to
- existing packages like OpenOffice.org and SQL-Ledger, and
- sample database schemas for PostgreSQL.</para>
- </listitem>
- </itemizedlist>
- </listitem>
-</varlistentry>
-
-</variablelist>
-The word <emphasis>lex</emphasis> is the Latin word for law.
-</para>
-</sect2>
-
-
- <sect2 id="debian-enterprise">
- <title>Debian Enterprise</title>
-
-<para>
-Debian GNU/Linux for Enterprise Computing
-
-<variablelist>
-
-<varlistentry>
- <term>Start</term>
- <listitem><para>End of 2003</para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>URL</term>
- <listitem><para>Debian Enterprise</para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Initiator</term>
- <listitem><para>Zenaan Harkness <email>zen at iptaustralia.net</email></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Activity</term>
- <listitem><para><ulink url="http://blends.debian.net/liststats/authorstat_debian-enterprise.png">Activists on Debian Enterprise mailing list</ulink></para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Goals</term>
- <listitem>
- <itemizedlist>
- <!-- [BA] The following are stated on the web site as what Debian Enterprise
- does, and not as goals. But the goals section on the web site is hard
- to reduce to specific goals point-by-point. I believe this needs fixing,
- and perhaps could be improved by talking it over with Zenaan. -->
- <listitem><para>To apply the UserLinux Manifesto.</para></listitem>
- <listitem><para>To establish the benchmark in world class Enterprise
- operating systems engineered within an industry driven
- shared-cost development model.</para></listitem>
- <listitem><para>To vigorously defend its distinctive trademarks and
- branding.</para></listitem>
- <listitem><para>To develop extensive and professional quality
- documentation.</para></listitem>
- <listitem><para>To provide engineer certification through partner
- organisations.</para></listitem>
- <listitem><para>To certify the Debian Enterprise GNU/Linux operating system
- to specific industry standards.</para></listitem>
- <listitem><para>To pre-configure server tasks</para></listitem>
- <!-- [BA] I don't know what this point means, nor can I find it on the
- web site, so perhaps it should simply be removed.
- <listitem>To provide install-time options regarding the intended
- purpose.</listitem>
- [AT] Removed by comment
- The idea behind it was that it might be interesting to
- provide some configuration options for certain servers
- which might have connections to others. For instance Zope
- can be run behind Apache using some rewriting rules but
- this is poorly documented and a working example or
- something else could help here. It was discussed via
- E-Mail that Debian Enterprise could provide such
- "inter-package-connection" configurations as examples.
- This was badly worded above and not officially stated at
- their web site, but should not be lost out of focus and
- should remain here at least as comment. Perhaps you might
- find a better wording.
- -->
- </itemizedlist>
-
- </listitem>
-</varlistentry>
-
-</variablelist>
-
-</para>
-
-</sect2>
-
- <sect2 id="other">
- <title>Other possible Debian Pure Blends</title>
-<para>
- There are fields that could be served nicely by not yet existing
- Blends:
- <variablelist>
-
- <varlistentry>
- <term>Debian eGov</term>
- <listitem><para>Could address government issues, administration, offices of authorities,
- accounting.</para></listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Office</term>
- <listitem><para>Could cover all office issues.</para></listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Accounting</term>
- <listitem><para>Could integrate accounting systems into Debian.</para></listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Biology</term>
- <listitem><para>Could perhaps take over some stuff from Debian Med.</para></listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Physics</term>
- <listitem><para>Might look after simulation software.</para></listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Mathematics</term>
- <listitem>
- <para>There is even already a live CD - see Quantian in <xref linkend="liveCD"/></para></listitem>
- </varlistentry>
-
- <varlistentry>
- <term>???</term>
- <listitem><para>There are a lot more potential Blends.</para></listitem>
- </varlistentry>
-
- </variablelist>
-</para>
-</sect2>
-
-</sect1>
-
-</chapter>
\ No newline at end of file
diff --git a/doc/en/05_inside.xml b/doc/en/05_inside.xml
deleted file mode 100644
index 03005f9..0000000
--- a/doc/en/05_inside.xml
+++ /dev/null
@@ -1,286 +0,0 @@
-<chapter id="inside">
- <title>Distributions inside Debian</title>
-
- <sect1 id="fork">
- <title>To fork or not to fork</title>
-
-<para>
-There are many distributions that decided to fork from a certain
-state of Debian. This is perfectly all right because Debian is
-completely free and everybody is allowed to do this. People who
-built those derived distributions had certain reasons to proceed
-this way.
-</para>
-
- <sect2 id="commercialfork">
- <title>Commercial forks</title>
-
-<para>
-If Debian should be used as the base for a commercial distribution
-like
- <ulink url="http://www.linspire.com/">Linspire</ulink> (formerly Lindows),
- <ulink url="http://www.libranet.com/">Libranet</ulink> or
- <ulink url="http://www.xandros.com/">Xandros</ulink>, there is no other
-choice than forking because these companies normally add some stuff
-that is non-free. While Debian Pure Blends might be interesting in
-technical terms for those commercial distributions by making it easier
-to build a separate distribution, these non-free additions are not
-allowed to be integrated into Debian, and thus integration into Debian
-is impossible.
-</para>
- </sect2>
-
- <sect2 id="noncommercialfork">
- <title>Non-commercial forks</title>
-
-<para>
-As a completely free distribution Debian GNU/Linux is quite often a
-welcome starting point for derived distributions with a certain
-purpose that are as free as Debian but had certain reasons to fork.
-One main reason for a fork was that Debian was not flexible enough for
-certain purposes and some needed features had to be added. One reason
-for the Debian Pure Blends effort is to increase flexibility and to
-make the reason mentioned above void (if it is not yet void because of
-the general develoment of Debian). Some examples of forks from Debian
-that are probably now able to integrate back into Debian as a Debian
-Pure Blend are:
-
-<variablelist>
-
-<varlistentry>
- <term><ulink url="http://www.skolelinux.org">SkoleLinux</ulink></term>
- <listitem><para>Mentioning SkoleLinux in the category of forks is more or less
- history. The merge back into Debian started with the
- SkoleLinux people really doing a great job to enhance Debian
- for their own purposes in the form of their work on
- debian-installer, and culminated with the formal merging of
- the Blend Debian Edu and SkoleLinux, so that they are now
- virtually equivalent. This is the recommended way for derived
- distributions, and the reasons for this recommendation are
- given below.</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>DeMuDi</term>
- <listitem><para>The <ulink url="http://www.agnula.org/">Agnula</ulink> project, which is founded by the
- European Community, (and in fact is the first Free Software project
- that was founded by the EU at all,) forked for the
- following reasons:</para>
-
- <variablelist>
-
- <varlistentry>
- <term>Technical</term>
- <listitem><para>They had some special requirements for the kernel and
- configuration. This is more or less solved in the
- upcoming Debian release.</para></listitem>
- </varlistentry>
-
- <varlistentry>
- <term>License</term>
- <listitem><para>When DeMuDi started, not enough free programs in this
- field existed. This situation is better now.</para></listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Organisational</term>
- <listitem><para>Because of the founded status of the project, an extra
- distribution had to be developed. To accomplish this
- requirement, Debian Pure Blends plan to build common tools to
- facilitate building separate CDs with the contents of only a
- single distribution.</para></listitem>
- </varlistentry>
-
- </variablelist>
-
- <para>
- This shows that there is no longer a real need for a fork, and
- in fact, the organiser of the DeMuDi project was in contact to
- start bringing DeMuDi back into Debian. That is why DeMuDi is
- mentioned in the list of Debian Pure Blends above.
- Unfortunately the effort to merge back has stalled but it
- might be an interesting project to apply Blends techniques to
- support multimedia experts who want to use Debian.</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>LinEx</term>
- <listitem><para>LinEx is the very successful distribution for schools in the
- Region Extremadura in Spain. The work of the LinEx people
- perhaps made Debian more popular than any other distribution.
- The project was founded by the local government of
- Extremadura, and each school in this region is running this
- distribution. While this is a great success, the further
- development of LinEx has to face the problems that will be
- explained below. Because the creators of LinEx are aware of
- this fact they started joining the educational part of LinEx
- with Debian Edu which in turn leaded to an even stronger
- position of this Blend.</para>
- </listitem>
-</varlistentry>
-
-</variablelist>
-
-</para>
-
-<para>
-If developers of a non-commercial fork consider integrating back into
-Debian in the form of a Debian Pure Blend, it might happen that their
-field is covered already by an existing Blend. For instance, this
-would be the case for LinEx, which has the same group of target users
-as Debian Edu as explained above. On the other hand, some special
-adaptations might be necessary to fit the requirements of the local
-educational system. The specific changes that might be necessary
-would be called <emphasis>flavours</emphasis> of a Blend.
-</para>
- </sect2>
-
- <sect2 id="disadvantages">
- <title>Disadvantages of separate distribution</title>
-
-<para>
-In general, a separate distribution costs extra effort. Because it is
-hardly possible to hire enough developers who can double the great
-work of many volunteer Debian developers, this would be a bad idea for
-economical reasons. These people would have to deal with continuous
-changes to keep the base system, installer, etc. up to date with the
-current Debian development. It would be more sane to send patches that
-address their special requirements to Debian instead of
-maintaining a complete Debian tree containing these patches.
-</para>
-
-<para>
-Debian is well known for its strong focus on security. Security is
-mainly based on manpower and knowledge. So the best way to deal with
-security issues would be to base it on the Debian infrastructure,
-instead of inventing something new.
-</para>
-
-<para>
-New projects with special intentions often have trouble to become
-popular to the user group they want to address. This is a matter of
-attaining the critical mass that was explained in <xref linkend="general_problem"/>.
-</para>
-<para>
-Larger Free Software projects need certain infrastructure like
-web servers, ftp servers, (both with mirrors,) a bug tracking system,
-etc. It takes a fair amount of extra effort to build an entire infrastructure
-that is already available for free in Debian.
-</para>
-<para>
-<emphasis>Forking would be a bad idea.</emphasis>
-</para>
- </sect2>
-
- <sect2 id="advantages">
- <title>Advantages of integration into Debian</title>
-
-<para>
-Debian has a huge user base all over the world. Any project that is
-integrated within Debian has a good chance to become popular on the back
-of Debian if the target users of the project just notice that it
-enables them to solve their problems. So there is no
-need for extra research on the side of the users, and no need for
-advertising for a special distribution. This fact has been
-observed in the Debian Med project, which is well known for many
-people in medical care. It would not have gained this popularity if
-it had been separated from Debian.
-</para>
-
-<para>
-You get a secure and stable system without extra effort for free.
-</para>
-
-<para>
-Debian offers a sophisticated Bug Tracking System for free, which is a
-really important resource for development.
-</para>
-
-<para>
-There is a solid infrastructure of web servers, ftp servers with
-mirrors, mail servers, and an LDAP directory of developers with a strongly
-woven web of trust (through gpg key signing) for free.
-</para>
-
-</sect2>
-
- <sect2>
- <title>Enhancing Debian</title>
-
-<para>
-By making changes to some packages to make them fit the needs of a target
-user group, the overall quality of Debian can be enhanced. In this way,
-enhancing Debian by making it more user friendly is a good way for
-the community to give back something to Debian. It would be a shame
-if somebody would refuse all the advantages to keeping a project
-inside Debian, and instead would decide to try to cope with the disadvantages
-because he just does not know how to do it the right way, and that it is
-normally easy to propogate changes into Debian. For instance, see
-<xref linkend="howto_itp"/>. This section explains how you can ask for
-a certain piece of software to be included in Debian.
-The next section describes the reason why Debian is flexible enough
-to be adapted to any purpose.
-</para>
-
-</sect2>
-
-</sect1>
-
- <sect1>
- <title>Adaptation to any purpose</title>
-
-<para>
-Debian is developed by about 1000 volunteers. Within this large group,
-the developers are encouraged to care for their own interests in packages
-they have chosen to look after. Thus, Debian is not bound to commercial
-interests.
-</para>
-
-<para>
-Those who might fear this amount of freedom given to every single developer
-should realize that there are very strict rules, as laid out in
-<ulink url="http://www.debian.org/doc/debian-policy/">Debian's policy</ulink>,
-which glue everything together. To keep their packages in each new
-release, every developer must ensure that their packages abide by that policy.
-</para>
-
-<para>
-One common interest each individual developer shares is to make the
-best operating system for himself. This way, people with similar
-interests and tasks profit from the work of single developers. If
-users, in turn, work together with the developers by sending patches or
-bug reports for further enhancement, Debian can be improved also for
-special tasks.
-</para>
-
-<para>
-For instance, developers may have children, or may work in some
-special fields of work, and so they try to make the best system for
-their own needs. For children, they contribute to Debian Jr. or
-Debian Edu. For their field of work, they contribute to the
-appropriate Blend: Debian Med, Debian Science, and so forth.
-</para>
-
-<para>
-In contrast to employees of companies, every single Debian developer
-has the freedom and ability to realize his vision. He is not bound to
-decisions of the management of his company. Commercial distributors
-have to aim their distributions at gaining a big market share. The
-commercial possibilities in targeting children's PCs at home are
-slight, so distributions comparable to Debian Junior are not attractive
-for commercial distributors to make.
-</para>
-
-<para>
-Thus, single developers have influence on development - they just have
-to <emphasis>do</emphasis> it, which is a very different position compared
-with employees of a commercial distributor. This is the reason for the
-flexibility of Debian that makes it adaptable for any purpose. In
-the Debian world, this kind of community is called
-"<emphasis><emphasis>Do</emphasis>ocracy</emphasis>" - the one who does, rules.
-</para>
- </sect1>
-
-</chapter>
\ No newline at end of file
diff --git a/doc/en/06_technology.xml b/doc/en/06_technology.xml
deleted file mode 100644
index 41f7b65..0000000
--- a/doc/en/06_technology.xml
+++ /dev/null
@@ -1,986 +0,0 @@
-<chapter id="technology">
- <title>Technology</title>
-
- <sect1 id="metapackages">
- <title>Metapackages</title>
-
- <sect2 id="defmetapackages">
- <title>Metapackage definition</title>
-
-<para>
-A metapackage, as used by Blends, is a Debian package that contains:
-
-<itemizedlist>
- <listitem><para>Dependencies on other Debian packages (essential)</para>
- <variablelist>
-
- <varlistentry>
- <term>Depends</term>
- <listitem><para>Use "Depends" for packages that are definitely needed
- for all basic stuff of the Blend in question.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Recommends</term>
- <listitem><para>The packages that are listed as "Recommends" in the
- tasks file should be installed on the machine where the
- metapackage is installed and which are needed to work
- on a specific task.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Suggests</term>
- <listitem><para>Use "Suggests" for others of lesser importance that
- might be possibly useful, or non-free packages. When a
- package is not available for the target distribution at
- metapackage build time the "Recommends" is turned into
- a "Suggests" to enable a flawless installation of the
- metapackage.</para>
- </listitem>
- </varlistentry>
- </variablelist>
- </listitem>
- <listitem><para>Menu entries (recommended)</para>
- <itemizedlist>
- <listitem>
- <para>Place these in <filename>/etc/blends/</filename><varname><blend></varname>
- <varname>/menu/</varname><varname><pkg-name></varname>
- </para>
- </listitem>
- <listitem><para>Maintain these via role based tools</para></listitem>
- </itemizedlist>
- </listitem>
- <listitem>
- <para>Configuration stuff (optional)</para>
- <itemizedlist>
- <listitem><para><orgname>debconf</orgname> questions or pre-seeding</para></listitem>
- <listitem><para><orgname>cfengine</orgname> scripts (or similar see <xref linkend="EnhancingTechnology"/>)</para></listitem>
- </itemizedlist>
- </listitem>
- <listitem><para>Special metapackages:</para>
- <itemizedlist>
- <listitem><para><varname><blend></varname>-<package>tasks</package>:
- Contains information for <orgname>tasksel</orgname></para></listitem>
- <listitem><para><varname><blend></varname>-<package>config</package>:
- Special configurations, basic stuff for user menus</para></listitem>
- </itemizedlist>
- </listitem>
-</itemizedlist>
-
-</para>
-
-<para>
-Metapackages are small packages with nearly no contents. The main
-feature of this type of package is its dependencies on other
-packages. The naming of metapackages follows the pattern
-<varname><blend></varname>-<varname><task></varname>
-where <varname><blend></varname> stands for the short name of a Debian
-Pure Blend, e.g. <package>junior</package> for Debian
-Jr. or <package>med</package> for Debian Med,
-and <varname><task></varname> means the certain task inside the Blend,
-e.g. puzzle or bio.
-</para>
-
-<para>
-
-Examples:
-<variablelist>
-
-<varlistentry>
- <term><package>junior-puzzle</package></term>
- <listitem><para>Debian Jr. Puzzles</para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term><package>education-tasks</package></term>
- <listitem><para>Tasksel files for SkoleLinux systems</para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term><package>med-bio</package></term>
- <listitem><para>Debian Med micro-biology packages</para></listitem>
-</varlistentry>
-
-</variablelist>
-</para>
-
-</sect2>
- <sect2 id="collection">
- <title>Collection of specific software</title>
-
-<para>
-When using metapackages, no research for available software inside Debian is
-necessary. It would not be acceptable for normal users to have to browse the
-descriptions of the whole list of the 20000 packages in Debian to find
-everything they need. So, metapackages are an easy method to help users to
-find the packages that are interesting for their work quickly.
-</para>
-<para>
-If the author of a metapackage includes several packages with similar
-functionality, an easy comparison between software covering the same task is
-possible.
-</para>
-<!-- This is not true any more since we turn Depends into Recommends
- to explicitely *enable* users to remove certain packages.
-
-Moreover, the installation of a metapackage ensures that no package
-that is necessary for the intended task can be removed without
-explicit notice that also the metapackage has to be removed. This
-helps non specialist administrators to keep the installation fit for
-the specialized users.
- -->
-<para>
-By defining conflicts with some other packages inside the metapackage,
-it is possible to ensure that a package that might conflict for some
-reasons for the intended task can not be installed at the same time as
-the metapackage is installed.
-</para>
-<para>
-All in all, metapackages enable an easy installation from scratch, and
-keep the effort required for administration low.
-</para>
-
-</sect2>
- <sect2 id="categorisation">
- <title>Packages showing up in more than one metapackage</title>
-
-<para>
-This seems to be an FAQ: If a package <package>A</package> is in the list of
-dependencies of metapackage <package>m</package> is it allowed or reasonable to
-add it to the list of dependencies of metapackage <package>n</package>?
-</para>
-<para>
-The answer is: Why not?
-</para>
-<para>
-The "overlap" is no problem because we do not want to build
-an exclusive categorisation which might be hard to understand for our
-users. Metapackages are like "normal" packages: Nobody
-would assume that because package <package>x</package> depends from package
-<package>libc</package> no other package is allowed to add <package>libc</package> to its
-depends. So why not adding a dependency to more than one metapackage if
-it is just useful for a certain task?
-</para>
-
-<para>
-The important thing is to support our users. A specific user wants to
-solve a certain task (and thus installs a certain metapackage). The
-question whether some Dependencies are also mentioned in a different
-metapackage is completely useless for this task. So in fact we do
-<emphasis>not</emphasis> build a categorisation tree but build pools of useful
-software for certain tasks which can definitely have overlaps.
-</para>
-
-<para>
-To give a certain example which was asked by a member of Debian
-Multimedia team: A user who is seeking for his optimal sound player is
-not served best if we "hide" an application from his view by
-including it into sound recorders exclusively. While chances might be
-good that a sound recorder is not as lightweight as a pure player the
-user will find out this quickly if he is looking for only a
-lightweight player - but perhaps he becomes happy later about the
-"added value" of his favourite player if it also is able to record
-sound.
-</para>
-
- </sect2>
-
- <sect2 id="configuration">
- <title>Adapted configuration inside metapackages</title>
-
-<para>
-Besides the simplification of installing relevant packages by
-dependencies inside metapackages, these packages might contain special
-configuration for the intended task. This might either be
-accomplished by pre-seeding <orgname>debconf</orgname> questions, or by
-modifying configuration files in a <package>postinst</package> script. It
-has to be ensured that no changes that have been done manually by the
-administrator will be changed by this procedure. So to speak, the
-<package>postinst</package> script takes over the role of a local
-administrator.
-<!-- FIXME:
- An improved version of the pre-seeding scripts are included in newer
- debconf versions. I just replaced the debian-edu scripts with the
- scripts from debconf. Look at debconf-set-selections and
- debconf-get-selections.
- -->
-</para>
-
- </sect2>
-
- <sect2 id="documentation">
- <title>Documentation packages</title>
-
-<para>
-A "traditional" weakness of Free Software projects is missing
-documentation. To fix this, Debian Pure Blends try to provide
-relevant documentation to help users to solve their problems. This
-can be done by building <package>*-doc</package> packages of existing
-documentation, and by writing extra documentation, like manpages, etc.
-By supplying documentation, Debian Pure Blends fulfil their role in
-addressing the needs of specialised users, who have a great need for
-good documentation in their native language.
-</para>
-<para>
-Thus, translation is a very important thing to make programs more
-useful for the target user group. Debian has established
-a <ulink url="http://ddtp.debian.net/">Debian Description
-Translation Project</ulink>, which has the goal to translate package
-descriptions. There is a good chance this system could also be used
-for other types of documentation, which might be a great help for
-Debian Pure Blends.
-</para>
-
- </sect2>
- </sect1>
-
- <sect1 id="mp_handling">
- <title>Handling of metapackages</title>
-
-<para>
-<!-- [BA] I think we need to qualify what 'handle' means, because there
- certainly are other tools that 'handle' them (e.g. synaptic) if that term
- is taken in its broadest sense.
- [AT] ACK, here that we have to define 'handle'. The term
- 'nicely' was intended to be the keyword because metapackages are
- currently handled as any other package which is fine, but no help
- for users who do not know anything about metapackages. We need
- special tools to gain all profits we could have. Could you set
- this into good English???
- -->
-In short, there are no special tools available to handle metapackages
-nicely. But there are some tricks that might help, for the moment.
-</para>
-
- <sect2 id="cmdline">
- <title>Command line tools</title>
-
-<para>
-<variablelist>
-
-<varlistentry>
- <term><orgname>apt-cache</orgname></term>
- <listitem><para>
- The program <orgname>apt-cache</orgname> is useful to search for
- relevant keywords in package descriptions. With it, you could search
- for a certain keyword connected to your topic (for instance
- "<package>med</package>") and combine it reasonably with <package>grep</package>:</para>
- <informalexample>
- <programlisting>
-~> apt-cache search med | grep '^med-'
-med-bio - Debian Med micro-biology packages
-med-bio-dev - Debian Med micro-biology development packages
-med-doc - Debian Med documentation packages
-med-imaging - Debian Med imaging packages
-med-imaging-dev - Debian Med packages for medical image develop...
-med-tools - Debian Med several tools
-med-common - Debian Med Project common package
-med-cms - Debian Med content management systems
-</programlisting>
- </informalexample>
- <para>
- This is <emphasis>not really straightforward</emphasis>, and
- absolutely unacceptable for end users.
- </para>
-
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term><package>grep-dctrl</package></term>
- <listitem><para>
- The program <package>grep-dctrl</package> is a grep for Debian package
- information, which is helpful for extracting specific package details
- matching certain patterns:</para>
- <informalexample>
- <programlisting>
-~> grep-dctrl ': med-' /var/lib/dpkg/available | \
- grep -v '^[SIMAVF]' | \
- grep -v '^Pri'
-Package: med-imaging
-Depends: paul, ctsim, ctn, minc-tools, medcon, xmedcon, med-common
-Description: Debian Med imaging packages
-
-Package: med-bio
-Depends: bioperl, blast2, bugsx, fastdnaml, fastlink, garlic...
-Description: Debian Med micro-biology packages
-
-Package: med-common
-Depends: adduser, debconf (>= 0.5), menu
-Description: Debian Med Project common package
-
-Package: med-tools
-Depends: mencal, med-common
-Description: Debian Med several tools
-
-Package: med-doc
-Depends: doc-linux-html | doc-linux-text, resmed-doc, med-co...
-Description: Debian Med documentation packages
-
-Package: med-cms
-Depends: zope-zms
-Description: Debian Med content management systems
-
-Package: med-imaging-dev
-Depends: libgtkimreg-dev, ctn-dev, libminc0-dev, libmdc2-dev...
-Description: Debian Med packages for medical image development
-
-Package: med-bio-contrib
-Depends: clustalw | clustalw-mpi, clustalx, molphy, phylip, ...
-Description: Debian Med micro-biology packages (contrib and ...
-</programlisting>
- </informalexample>
- <para>
- This is, like the <package>apt-cache</package> example, <emphasis>also
- a bit cryptic</emphasis>, and again is not acceptable for end users.
- </para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term><package>auto-apt</package></term>
- <listitem><para>
- The program <package>auto-apt</package> is really cool if you are
- running a computer that was installed from scratch in a hurry, and
- are sitting at a tradeshow booth preparing to do a demo. If you had
- no time to figure out which packages you needed for the demo were missing
- so you could install all of them in advance, you could use
- <package>auto-apt</package> in the following manner to guarantee that you
- have all of the files or programs you need:</para>
- <informalexample>
- <programlisting>
-~> sudo auto-apt update
-put: 880730 files, 1074158 entries
-put: 903018 files, 1101981 entries
-~> auto-apt -x -y run
-Entering auto-apt mode: /bin/bash
-Exit the command to leave auto-apt mode.
-bash-2.05b$ less /usr/share/doc/med-bio/copyright
-Reading Package Lists... Done
-Building Dependency Tree... Done
-The following extra packages will be installed:
- bugsx fastlink readseq
-The following NEW packages will be installed:
- bugsx fastlink med-bio readseq
-0 packages upgraded, 4 newly installed, 0 to remove and 183 ...
-Need to get 0B/1263kB of archives. After unpacking 2008kB wi...
-Reading changelogs... Done
-Selecting previously deselected package bugsx.
-(Reading database ... 133094 files and directories currently...
-Unpacking bugsx (from .../b/bugsx/bugsx_1.08-6_i386.deb) ...
-Selecting previously deselected package fastlink.
-Unpacking fastlink (from .../fastlink_4.1P-fix81-2_i386.deb) ...
-Selecting previously deselected package med-bio.
-Unpacking med-bio (from .../med-bio_0.4-1_all.deb) ...
-Setting up bugsx (1.08-6) ...
-
-Setting up fastlink (4.1P-fix81-2) ...
-
-Setting up med-bio (0.4-1) ...
-
-localepurge: checking for new locale files ...
-localepurge: processing locale files ...
-localepurge: processing man pages ...
-This package is Copyright 2002 by Andreas Tille <tille at debian.org>
-
-This software is licensed under the GPL.
-
-On Debian systems, the GPL can be found at /usr/share/common-...
-/usr/share/doc/med-bio/copyright
-</programlisting>
- </informalexample>
-
- <para>
- Just do your normal business - in the above example, <filename>less
- /usr/share/doc/med-bio/copyright</filename> - and if the necessary
- package is not yet installed, <package>auto-apt</package> will care for
- the installation and proceed with your command. While this is
- really cool, this is <emphasis>not really intended for a production
- machine</emphasis>.
- </para>
-
- </listitem>
-</varlistentry>
-
-</variablelist>
-
-The short conclusion here is: <emphasis>There are no sophisticated tools
-that might be helpful to handle metapackages as they are used in
-Debian Pure Blends - just some hacks using the powerful tools inside
-Debian.</emphasis>
-</para>
-
- </sect2>
-
- <sect2 id="text_ui">
- <title>Text user interfaces</title>
-<para>
-
-<variablelist>
-
-<varlistentry>
- <term><orgname>tasksel</orgname></term>
- <listitem>
- <para>
- The Debian task installer <package>Tasksel</package> is the first
- interface for package selection that is presented to the user when
- installing a new computer. The <package>End-user</package> section should
- contain an entry for each Debian Pure Blend.
- Unfortunately, there are some issues that prevent Blends
- from being included in the <package>tasksel</package> list,
- because the dependencies of this task can affect what appears on
- the first installation CD. This problem would be even greater if
- all Blends were added, and so a different solution has
- to be found here. (See <ulink url="http://bugs.debian.org/186085">#186085</ulink>.)
- In principle, <package>tasksel</package> is a good
- tool for easy installation of Blends.
- </para>
- <para>
- As a workaround for this problem the <package>blends-dev</package>
- framework creates a package <package>BLEND-tasks</package> which contains
- a <package>tasksel</package> control file. If you install this package
- all tasks of the Blend will be added to the default list of tasks
- inside <package>tasksel</package>. So a solution for Blend specific
- installation media might be to just remove the default tasksel
- list and provide the Blends own tasks exclusively.
- </para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term><package>aptitude</package></term>
- <listitem><para>
- This is a better replacement for <package>dselect</package>, and has
- some useful support for searching for and grouping of packages.
- While this is not bad, it was not intended for the purpose of
- handling Debian Pure Blends, and thus there could be some better
- support to handle metapackages more cleverly.</para>
- </listitem>
-</varlistentry>
-
-</variablelist>
-
-Short conclusion: <emphasis>There is a good chance metapackages could be
-handled nicely by the text based Debian package administration tools,
-but this is not yet implemented.</emphasis>
-</para>
-
- </sect2>
-
- <sect2 id="gui">
- <title>Graphical user interfaces</title>
-<para>
-Debian <emphasis>Woody</emphasis> does not contain a really nice graphical
-user interface for the Debian package management system. But the
-efforts to support users with an easy to use tool have increased, and
-so there there will be some usable options in Sarge.
-
-<variablelist>
-
-<varlistentry>
- <term><package>gnome-apt</package></term>
- <listitem><para>This is the native GNOME flavour of graphical user interfaces
- to apt. It has a nice <package>Search</package> feature that can be
- found in the <package>Package</package> menu section. If for instance
- the packages of the Debian Jr. project come into the focus of
- interest a search for "<package>junior-*</package>" will show
- up all related packages including their descriptions. This
- will give a reasonable overview about metapackages of the
- project.</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term><package>synaptic</package></term>
- <listitem><para>Even more sophisticated and perhaps the best choice for users
- of Debian Pure Blends. <package>Synaptic</package> has a nice
- filter feature, which makes it a great tool here.
- Moreover <package>synaptic</package> is currently the only user
- interface that supports Debian Package Tags
- (see <xref linkend="debtags"/> ).</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term><package>kpackage</package></term>
- <listitem><para>This is the user interface of choice for KDE lovers.
- Regarding its features (with exception of Debian Package Tags)
- it is similar to both above.</para>
- </listitem>
-</varlistentry>
-
-</variablelist>
-
-Short conclusion: <emphasis>As well as the text based user interfaces
-these tools are quite usable but need enhancements to be regarded as
-powerful tools for Debian Pure Blends.</emphasis>
-</para>
- </sect2>
-
- <sect2 id="web_if">
- <title>Web interfaces</title>
-
-<para>
-
-<variablelist>
-
-<varlistentry>
- <term>Tasks pages</term>
- <listitem><para>The tasks pages probably provide the best overview about
- the actual work which is done in a Debian Pure Blend. These
- pages are automatically generated by reading the tasks files
- (see <xref linkend="debian_control"/> ) and verifying the existence
- of the packages that are mentioned as dependencies. On the
- resulting web page the packages are listed with some meta
- information and the description of the package. As user
- oriented pages they are translated into more than 10
- languages while translated means, the navigation text of the
- page generating code is using <package>gettext</package> which
- enables translation (the work is not yet completely done for
- all languages) but even more importantly the descriptions of
- the packages are translated as well by using the information
- from
- <ulink url="http://ddtp.debian.net/">Debian Description Translation Project</ulink>.
- </para>
- <para>These tasks pages are available via
- <informalexample>
- <programlisting>
- http://blends.alioth.debian.org/BLEND/tasks
- </programlisting>
- </informalexample>
- where <package>BLEND</package> has to be replaced by the name of the
- Blend. Currently these pages are available for the Blends:
- <informalexample>
- <programlisting>
- accessibility, edu, gis, junior, lex, science, debichem
- </programlisting>
- </informalexample>
- The tasks pages are available for Debian Med as well but for
- historical reasons the URL for these pages is
- <informalexample>
- <programlisting>
- http://debian-med.alioth.debian.org/tasks
- </programlisting>
- </informalexample>
- In short: If you want to know more about a specific Blend
- go to its task page and have a look what is listed there.
- </para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Bugs pages</term>
- <listitem><para>The more developer oriented bugs pages try to match the
- scope of the tasks pages mentioned above but there is no
- description of the packages given but rather the bugs that
- are reported in the Debian Bug Tracking System (BTS) are
- listed there. This is a quite valuable source of information
- if somebody is interested in increasing the quality of a
- Blend: Fixing bugs is always welcome and listing all relevant
- bugs at a single place is a nice way to detect problems
- quickly.
- </para>
- <para>These bugs pages are available via
- <informalexample>
- <programlisting>
- http://blends.alioth.debian.org/BLEND/bugs
- </programlisting>
- </informalexample>
- where <package>BLEND</package> has to be replaced by the name of the
- Blend. Currently these pages are available for the Blends:
- <informalexample>
- <programlisting>
- accessibility, edu, gis, junior, lex, science, debichem
- </programlisting>
- </informalexample>
- The bugs pages are available for Debian Med as well but for
- historical reasons the URL for these pages is
- <informalexample>
- <programlisting>
- http://debian-med.alioth.debian.org/bugs
- </programlisting>
- </informalexample>
- In short: If you want to help enhancing the quality of a
- specific Blend go to its bug page and start working on the
- bugs listed there.
- </para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term><ulink url="http://packages.debian.org/">Web search</ulink></term>
- <listitem><para>Debian has a web interface that can be used to search for certain substrings
- in package names. For instance if you are searching the meta
- packages of Debian Med you could point your favourite Browser
- to</para>
- <para>
-<remark>FIXME: & is sometimes broken!!!
-<ulink url="http://packages.debian.org/cgi-bin/search_packages.pl?keywords=med-&subword=1"/>
- ^^^^^
-</remark>
-<ulink url="http://packages.debian.org/cgi-bin/search_packages.pl?keywords=med-&subword=1"/>
- </para>
- <para>
- As a result you will get a list of all Debian Med packages.</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term><ulink url="http://qa.debian.org/developer.php">Package Tracking System</ulink></term>
- <listitem><para>
- The Package Tracking System is a really great tool that
- provides essential information about packages. Most Debian
- Pure Blends are using a mailing list address as Maintainer of
- their key packages which includes the metapackages. This so
- called team maintenance of packages is on one hand very handy
- from a developers point of view on the other hand it enables
- using the Package Tracking System to get a quick overview:
- </para>
- <variablelist>
- <varlistentry>
- <term>Debian Jr:</term>
- <listitem><para>
- <ulink url="http://qa.debian.org/developer.php?login=debian-jr@lists.debian.org"/>
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Debian Med:</term>
- <listitem> <para>
- <ulink url="http://qa.debian.org/developer.php?login=debian-med-packaging@lists.alioth.debian.org"/>
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Debian Edu:</term>
- <listitem><para>
- <ulink url="http://qa.debian.org/developer.php?login=debian-edu@lists.debian.org"/>
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Debian Science:</term>
- <listitem><para>
- <ulink url="http://qa.debian.org/developer.php?login=debian-science-maintainers@lists.alioth.debian.org"/>
- </para>
- </listitem>
- </varlistentry>
-
- </variablelist>
- <para>
- Hint: If you append the option <package>&ordering=3</package> you
- might get some sectioning of this page according to the
- metapackage categories. This result is approached by a tool
- which subscribes all dependent packages to the group
- maintenance address and adds a section according to a
- metapackage name.
- </para>
- <para>
- The other way to use the Package Tracking System is to search
- for packages starting with a certain letter:
- <variablelist>
- <varlistentry>
- <term>Debian Jr:</term>
- <listitem><para>
- <ulink url="http://packages.qa.debian.org/j"/></para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Debian Med:</term>
- <listitem><para>
- <ulink url="http://packages.qa.debian.org/m"/></para>
- </listitem>
- </varlistentry>
-
- </variablelist>
- But the list that is obtained by this method is much larger
- than it would be useful for a good overview.
- </para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term><package>list-junior.sh</package></term>
- <listitem><para>The package <package>junior-doc</package> contains a script
- <filename>/usr/share/doc/junior-doc/examples/scripts/list-junior.sh</filename>
- that checks for the installed packages of a Blend and builds
- a simple web page describing these packages. (The BTS
- contains a patch to let this script work also for other
- Blends.)</para>
- </listitem>
-</varlistentry>
-
-</variablelist>
-
-Short conclusion: <emphasis>The Debian Pure Blends provide some nice web
- tools for a whole set of packages for a certain working field that
- provide a better overview than the usual Debian tools that are
- basically dealing with single packages..</emphasis>
-</para>
- </sect2>
-
- <sect2 id="future_handling">
- <title>Future handling of metapackages</title>
-
-<para>
-Obviously there are no nifty tools as you might know them from Debian
-available yet. The user interfaces for <package>apt-get</package> have to be
-enhanced drastically to make them easy enough to make them useful in
-the hands of an end user. This might implicitly mean that we need
-some additional control fields in <package>dpkg</package> to implement
-reasonable functionality. The following items are target of future
-development:
-<itemizedlist>
- <listitem><para>Searching for existing metapackages</para></listitem>
- <listitem><para>Overview about dependencies of these metapackages</para></listitem>
- <listitem><para>Enhancing tools like <package>aptitude</package>,
- <package>synaptic</package>, etc.</para></listitem>
- <listitem><para>Special <package>tasksel</package> section</para></listitem>
- <listitem><para>Web tools that keep metapackage information up to
- date</para></listitem>
-</itemizedlist>
-
-</para>
-
-<para>
-Furthermore it is necessary to find a set of keywords for each Debian
-Pure Blend and write a tool to search these keywords comfortable. The
-best way to accomplish this might be to make use of Debian Package
-Tags, which is a quite promising technique.
-</para>
-
-<para>
-Tools that grep the apt cache directly for metapackages have to be
-written or rather the available tools for this should be patched for
-this actual functionality.
-</para>
- </sect2>
- </sect1>
-
- <sect1 id="userroles">
- <title>User roles</title>
-
-<para>
-As stated above specialists have only interest in a subset of the
-available software on the system they are using. In an ideal world, this
-would be the only software that is presented in the menu. This would
-allow the user to concentrate on his real world tasks instead of
-browsing large menu trees with entries he does not understand.
-</para>
-
-<para>
-To accomplish this, a technique has to be implemented that allows to
-define a set of users who get a task-specific menu while getting rid
-of the part of software they are not interested in. Moreover this has
-to be implemented for certain groups of users of one Blend, which are
-called "roles". There are several techniques available to manage user
-roles. Currently in the field of Debian Pure Blends a UNIX group
-based role system is implemented. This means, that a user who belongs
-to a certain group of a Blend is mentioned in
-the <filename>/etc/group</filename> file in the appropriate group and gets a
-special user menu that is provided for exactly this group.
-</para>
-
-<para>
-Strictly speaking it is not the best solution to conflate a
-configuration mechanism, which users see with menus, with access
-control, i.e. unix groups. It might be confusing, and wastes the limited
-number of groups to which a user can belong. On the other hand this
-is a solution that works for the moment, and has no real negative
-impact on the general use of the system. The benefit of using unix
-groups is that there is a defined set of tools provided to handle user
-groups. This makes life much easier; there is no
-<emphasis>practical</emphasis> limit to the number of groups to which a user may
-belong for the existing Debian Pure Blends at this time.
-</para>
-<para>
-In the long run, this role system might even be enhanced to certain
-"<emphasis>levels</emphasis>" a user can have and here the UNIX groups approach
-will definitely fail and has to be replaced by other mechanisms. This
-will include the possibility to enable the user adjust his own level
-("novice", "intermediate", "expert") while only the administrator is
-able to access the UNIX groups. On the other hand such kind of user
-level maintenance is not only a topic for Debian Pure Blends but might
-be interesting for Debian in general.
-</para>
-
-<para>
-Another point that speaks against using UNIX groups for role
-administration is the fact that local administrators are not in all
-cases competent enough to understand the UNIX role concept as a
-security feature and thus a real role concept including tools to
-maintain roles are needed in the future.
-</para>
-
-<para>
-The handling of the user menus according to the groups is implemented
-in a flexible plugin system and other ways of handling groups
-(i.e. LDAP) should be easy to implement.
-</para>
-
- <sect2 id="menu_tools">
- <title>User menu tools</title>
-
- <sect3 id="user-menus">
- <title>Using the Debian menu system</title>
-<para>
-The Debian menu system cares for menu updates after each package
-installation. To enable compliance with the <emphasis>role</emphasis> based menu
-approach it is necessary to rebuild the user menu after each package
-installation or after adding new users to the intended role. This can
-be done by using the
-<citerefentry><refentrytitle>blend-update-menus</refentrytitle>
- <manvolnum>8</manvolnum></citerefentry> (see
-<xref linkend="blend-update-menus"/>) script from
-<package>blends-common</package>. It has to be said that using
-<orgname>blend-update-menus</orgname> is not enough to change the menu of a
-user. To accomplish this a call of the general
-<orgname>update-menu</orgname> script for every single user of a Blend is
-necessary if this is not done by the
-<filename>postinst</filename> script of a metapackage. This can easily been
-done if the configuration file of a Debian Pure Blend
-<filename>/etc/blends/</filename><varname><blend></varname>/<varname><blend></varname><filename>.conf</filename> contains the
-line
-<informalexample>
-<programlisting>
- UPDATEUSERMENU=yes
- </programlisting>
-</informalexample>
-
-</para>
-<para>
-It is strongly suggested to use the
-package <package>blends-dev</package> to build metapackages of a
-Debian Pure Blend that will move all necessary files right into place
-if there exists a
-<filename>menu</filename> directory with the menu entries. Note, that the users
-<filename>${HOME}/.menu</filename> directory remains untouched.
-</para>
- </sect3>
-
- <sect3 id="user-debconf">
- <title>Managing Debian Pure Blend users with <orgname>debconf</orgname></title>
-
-<para>
-Using <package>blends-dev</package> it is very easy to build a
-<varname>blend</varname><package>-config</package> package that contains
-<orgname>debconf</orgname> scripts to configure system users who should
-belong to the group of users of the Debian Pure Blend <varname>blend</varname>.
-For example see the <package>med-common</package> package.
-
- <informalexample>
- <programlisting>
-~> dpkg-reconfigure med-common
-
-Configuring med-common
-----------------------
-
-Here is a list of all normal users of the system. Now you can select those users who
-should get a Debian Med user menu.
-
- 1. auser (normal user A) 6. fmeduser (med user F)
- 2. bmeduser (med user B) 7. glexuser (lex user G)
- 3. cjruser (jr user C) 8. hmeduser (med user H)
- 4. djruser (jr user D) 9. iadmin (administrator I)
- 5. eadmin (administrator E) 10. juser (normal user J)
-
-(Enter the items you want to select, separated by spaces.)
-
-:-! Please specify the Debian Med users! 2 8
-</programlisting>
- </informalexample>
-This example shows the situation when you
-<package>dpkg-reconfigure</package> <package>med-common</package> if
-<varname>med user B</varname> and <varname>med user H</varname> were defined as users
-of Debian Med previously and <varname>med user F</varname> should be added to
-the group of medical staff. (For sure it is more convenient to use the
-more comfortable interfaces to <package>debconf</package> but the used
-SGML DTD <ulink url="http://bugs.debian.org/140684">does not yet
- support screen shots</ulink>.)
-</para>
- </sect3>
- </sect2>
- </sect1>
-
- <sect1 id="devtools">
- <title>Development tools</title>
-
-<para>
-Building a metapackage is more or less equal for each meta
-package. This was the reason to build a common source package
-<package>blend</package> that builds into two binary packages
-<variablelist>
-
-<varlistentry>
- <term><package>blends-dev</package></term>
- <listitem><para>Helpful tools to build metapackages from a set of template
- files. These tools are interesting for people who want to
- build metapackages in the style Debian Edu and Debian Med
- are currently doing this. The purpose of this package is to
- make maintenance of metapackages as easy as possible.</para>
- <para>This package is described in detail in appendix <xref
- linkend="blends-dev"/>.</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term><package>blends-common</package></term>
- <listitem><para>This package provides some files that are common to meta
- packages of Debian Pure Blends especially those that were
- built using the tools of the package
- <package>blends-dev</package>. It introduces a method to handle
- system users in a group named according to the name of the
- Blend. The user menu approach is explained in detail
- in <xref linkend="userroles"/>.</para>
- <para>This package is described in detail in appendix <xref
- linkend="blends-common"/>.</para>
- </listitem>
-</varlistentry>
-
-</variablelist>
-
-The usage of the tools that are contained in these packages are
-described now in detail.
-</para>
-
-</sect1>
- <sect1 id="othertools">
- <title>Other interesting tools</title>
-
- <sect2 id="simple-cdd">
- <title>Simple-CDD</title>
-
-<para>
-The tool <package>simple-cdd</package> is a limited though relatively easy
-tool to create a customized debian-installer CD.
-</para><para>
-It includes simple mechanisms to create "profiles" that define common
-system configurations, which can be selected during system
-installation. <package>Simple-cdd</package> also makes it easy to build CDs
-with language and country settings pre-configured, or to use a 2.6
-kernel by default.
-</para><para>
-This can be used to create a crude "Debian Pure Blend" using
-packages from Debian, with pre-configuration of packages that use
-<orgname>debconf</orgname>. Custom configuration scripts can be specified
-to handle packages that don't support <orgname>debconf</orgname>
-pre-configuration.
-</para><para>
-Testing CD images with <package>qemu</package> is also made simple with a
-provided script.
-</para><para>
-It has only been tested with <package>debian-cd</package> from Etch (other
-than <package>debpartial-mirror</package>), so if using a new
-<package>debian-cd</package> or <package>debian-installer</package>, it may
-require some tweaks.
-</para>
- </sect2>
- </sect1>
-
-</chapter>
diff --git a/doc/en/07_starting.xml b/doc/en/07_starting.xml
deleted file mode 100644
index 32c8cac..0000000
--- a/doc/en/07_starting.xml
+++ /dev/null
@@ -1,413 +0,0 @@
-<chapter id="starting">
- <title>How to start a Debian Pure Blend</title>
-
-<para>
-This chapter is based on the Debian Subproject HOWTO, which was
-written by Ben Armstrong <email>synrg at debian.org</email>.
-</para>
-
- <sect1 id="planning">
- <title>Planning to form a Debian Pure Blend</title>
-
- <para>
- In this section, issues to think about before starting a Debian Pure
- Blend will be discussed. It is important to have a clear idea where
- to head and how to get there before launching into this adventure.
- </para>
-
- <sect2 id="leadership">
- <title>Leadership</title>
- <para>
- The existing Debian Pure Blends have clearly shown that they depend
- on a person who keeps things running. If anybody wants to start a
- project at first, he has to answer the question:
- <emphasis>"Am I the right person for the job?"</emphasis> Surely this is a
- question that may be faced with some amount of uncertainty. The way
- Debian Pure Blends started in the past was for the person with the
- idea for the project to just start doing the work. After some time
- using this approach, it became clear that if the project lacked a
- person to take leadership, the project would become stale. So the
- initiator has to answer the question clearly, whether or not he is
- able to continue in the <emphasis>job</emphasis> of leader, considering the
- amount of time he will have to spend, and the technical and social
- skills which are needed.
- </para>
- </sect2>
-
- <sect2 id="defining_scope">
- <title>Defining the scope of the Blend</title>
- <para>
- It is as important to decide what your group is not going to do as
- it is what it is going to do. A clear borderline is essential for
- the development of the project. Without it, outsiders might
- either expect more from the project than it can accomplish, or may ignore
- the project, finding it not helpful because they are
- not able to find out the purpose.
- </para>
- <para>
- By maintaining a good relationship with other Free Software projects,
- some common tasks can be done very effectively. When efforts can be
- shared, the amount of work for each project can be reduced.
- </para>
- <para>
- Checking for cooperation with other Debian Pure Blends is always a
- good idea. In technical terms, this is obvious, but sometimes there
- are possibilities to share efforts when the goals of two projects
- have parts in common.
- </para>
- <para>
- The one who decides to start a Debian Pure Blend takes on a
- responsibility for this project. It has to be for the good of
- Debian as a whole, and should bring an extra reputation to our
- common goal to build the best operating system.
- </para>
- </sect2>
-
- <sect2 id="initial_discussion">
- <title>Initial discussion</title>
- <para>
- By the time you have begun to think about forming the subproject,
- have made the commitment to lead it, and have sketched out a
- bit of where you want to go and how you'll get there, you have
- likely already done some informal discussion with your peers.
- It is time, if you haven't already, to take these ideas to the
- broader Debian developer community, opening discussion on the
- creation of your group.
- </para>
-
- <sect3 id="calling_all_developers">
- <title>Calling all developers</title>
- <para>
- At this stage, you will want to reach as broad an audience as possible.
- You have carefully thought out what you're going to do, and are able
- to articulate it to Debian as a whole. Let everyone know through
- the <email>debian-devel-announce at lists.debian.org</email> mailing
- list, setting the <emphasis>Reply-to:
- </emphasis><email>debian-devel at lists.debian.org</email> and listen to what
- everyone has to say about your idea. You may learn some valuable
- things about pitfalls that may lie ahead for your group. Maybe even
- show-stoppers at that. You may also find a number of like-minded
- individuals who are willing to join your group and help get it
- established.
- </para>
- </sect3>
-
- <sect3 id="steering_the_discussion">
- <title>Steering the discussion</title>
- <para>
- It's all too easy to get lost in ever-branching-out sub-threads at
- this point. Many people will be firing off ideas left, right and
- centre about what your group should do. Don't worry too much about
- containing the discussion and keeping it on track with your main
- idea. You would rather not squelch enthusiasm at this point. But
- do try to steer the discussion a bit, focusing on the ideas that
- are central to your subproject and not getting lost in the details.
- </para>
- <para>
- At some point, you'll decide you've heard enough, and you're ready
- to get down to the business of starting your group.
- </para>
- </sect3>
-
- </sect2>
-
-</sect1>
-
-<sect1 id="setting_up">
- <title>Setting up</title>
-
-<sect2>
- <title>Mailing list</title>
- <para>
- It is fairly important to enable some means for communication for
- the project. The most natural way to do this is with a mailing
- list.
- </para>
- <para>
- Creating a new mailing list starts with a wishlist bug against
- <package>lists.debian.org</package>. The format of this
- bug has to follow
- <ulink url="http://www.debian.org/MailingLists/HOWTO_start_list">certain rules</ulink>.
- </para>
- <para>
- Before your list can be created, the listmasters will want assurance
- that creation of the list is, in fact, necessary. So for this
- reason, don't wait for your list to be created. Start discussing
- your new project on <email>debian-devel at lists.debian.org</email>
- immediately. To help distinguish your project's posts from the
- large amount of traffic on this list, tag them in the Subject field
- with an agreed-upon tag. An example bug report to create the
- relevant list is bug
- <ulink url="http://bugs.debian.org/237017">#237017</ulink>.
- </para>
- <para>
- When sufficient discussion on the developer's list has
- taken place and it is time to move it to a subproject list,
- add to your wishlist bug report some URLs pointing to these
- discussions in the archives as justification for creation of
- your list.
- </para>
-</sect2>
-
-<sect2>
- <title>Web space</title>
- <para>
- A simple possibility, and one which is fairly attractive because it
- facilitates collaborative web site creation and maintenance, is to
- put a page on the <ulink url="http://wiki.debian.org">Wiki</ulink>.
- There is a
- special <ulink url="http://wiki.debian.org/index.cgi?DebianPureBlends">
- Wiki page for Debian Pure Blends</ulink>.
- </para>
- <para>
- A good place to put static web pages or even PHP code is the common
- place on Alioth for all
- Blends: <ulink url="http://blends.alioth.debian.org"/>. There is a
- subdirectory for each Blend and it is very easy to create a simple
- index page there which points to the automatically generated web
- pages which are mentioned in <xref linkend="web_if"/>. Following this
- strategy is quite cheap and has a big effect when using the tools
- provided by the Debian Pure Blends effort.
- </para>
- <para>
- Sooner or later a Debian Pure Blend will establish an own project at
- <ulink url="http://alioth.debian.org">alioth.debian.org</ulink>, since
- this enables many features for group maintaining packages, create
- mailing lists for different purposes, maintain a version control
- system like SVN or Git etc. The Alioth project enables to provide
- web sites as well and the Debian Med project is using this since a
- long time.
- </para>
- <para>
- Finally, the best way is to have a page
- under <ulink url="http://www.debian.org/devel"/>. While not as
- straightforward as any of the other options, this approach has its
- advantages. First, the site is mirrored everywhere. Second, the
- Debian web site translators translate pages into many different
- languages, reaching new potential audiences for your Debian Pure
- Blend, and improving communication with other members of your
- project and interested parties for whom English is not their most
- comfortable language. Third, a number of templates are available to
- make your site more integrated with the main web site, and to assist
- with incorporating some dynamic content into your site. Before you
- join the Debian Web team you
- should <ulink url="http://www.debian.org/devel/website">learn
- more about building Debian web pages</ulink>.
- </para>
- <para>
- Once this is done, the Debian web pages team should be contacted via
- the mailing list <email>debian-www at lists.debian.org</email> to add the
- project to the <ulink url="http://www.debian.org/intro/organization">organisation page</ulink>.
- </para>
-</sect2>
-
-<sect2>
- <title>Repository</title>
- <para>
- On <ulink url="http://alioth.debian.org/">alioth.debian.org</ulink> a
- <ulink url="http://gforge.org/">Gforge</ulink>-site is running to host
- all Debian related project work. Creating a project on Alioth is a
- good idea to start teamwork on the code a Debian Pure Blend is
- releasing.
- </para>
-</sect2>
-
-<sect2>
- <title>Formal announcement</title>
- <para>
- Once there is a list, or at least enough preliminary discussion on
- debian-devel to get started, and there is some information about the
- newly planned Debian Pure Blend available on the web, it is time to
- send a formal announcement to
- <email>debian-devel-announce at lists.debian.org</email>. The
- announcement should include references to past discussions, any web
- pages and code which might already exist, and summarise in a well thought
- out manner what the project is setting out to achieve. Enlisting the
- help of fellow developers on irc or in private email to look over
- the draft and work out the final wording before it is sent out is
- always a good idea.
- </para>
- <para>
- Emails to <email>debian-devel-announce at lists.debian.org</email> have to
- be signed by the GPG key of an official Debian developer. However, it
- should not be a very hard task if somebody wants to support Debian
- while not yet being a developer to find a developer who volunteers
- to sign an announcement of a reasonable project. It might be
- reasonable to send this announcement also to other relevant non-Debian
- lists. If your announcement is well done, it will draw a number
- of responses from many outsiders, and will attract people to Debian.
- </para>
-</sect2>
-
-<sect2>
- <title>Explaining the project</title>
- <para>
- Now the real work starts. People who are involved in the project
- should be aware that they have to answer questions about the project
- whenever they show up at conferences or at an exhibition booth. So
- being prepared with some flyers or posters is always a good idea.
- </para>
-</sect2>
-</sect1>
-
-<sect1 id="structure">
- <title>Project structure</title>
-
-<sect2 id="subsetting_debian">
- <title>Sub-setting Debian</title>
- <para>
- While there are a variety of different kinds of work to be done in
- Debian, and not all of them follow this pattern, this document
- describes one particular kind of project. Our discussion about
- Debian Pure Blends concerns sub-setting Debian. A sub-setting
- project aims to identify, expand, integrate, enhance, and maintain a
- collection of packages suitable for a particular purpose by a
- particular kind of user.
- </para>
- <para>
- Now, strictly speaking, a subset of packages could be more general
- than described above. A subset could be a broad category like
- "audio applications" or "network applications". Or it could be more
- specific, such as "web browsers" or "text editors". But what a
- sub-setting project such as Debian Jr. aims to do is not focus on the
- kind of package, but rather the kind of user. In the case of Debian
- Jr. it is a young child.
- </para>
- <para>
- The sort of user the project looks after, and which of the needs the
- project hopes to address are defined by the project's goals.
- <remark>BA: I had a bit of trouble deciding how to punctuate the following
- passage. I considered and rejected the advice given here in response to
- Kirsten's question about punctuating a list of questions:
- http://www.udel.edu/eli/g20.html, instead following the advice found
- elsewhere on the Web that double punctuation should be avoided.</remark>
- Thus, Debian Jr. first had to decide which children the project
- would reach: "What age?" "English speaking children only, or
- other languages as well?" Then the project had to determine
- how and where they would be using Debian: "At home?" "In school?"
- "Playing games?" "On their own systems?" "On their parents' systems?"
- </para>
- <para>
- The answers to all of these questions are not straightforward. It is
- very much up to the project to choose some arbitrary limits for the
- scope of their work. Choose too broad a focus, or one which duplicates
- work already done elsewhere, and the energy of the project dissipates,
- making the project ineffective. Choose too narrow a focus and the
- project ends up being marginal, lacking the critical mass necessary
- to sustain itself.
- </para>
- <para>
- A good example was the request to split the microbiology
- related packages out of Debian Med into a Debian Bio project. This
- is reasonable in principle, and should really be done. In fact, the
- initiator of Debian Med would support this idea. So he gave the
- answer: "Just start the Debian Bio project to take over all related
- material. Until this happens, Debian Med will cover medical material
- that deals with sequence analysis and so forth." Unfortunately,
- there was silence from the Debian Bio proponents after this answer.
- </para>
- <para>
- Of course, it sometimes turns out that you start working on a project
- thinking you know what it is about, only to find out later that you
- really had no idea what it would become until the user base has grown
- beyond the small community of developers that started it. So, none of
- the decisions you make about your project's scope at the beginning
- should be taken as set in stone. On the other hand, it is your project,
- and if you see it veering off in directions that are contrary to your
- vision for it, by all means steer it back on course.
- </para>
-</sect2>
-
-<sect2 id="tasksel">
- <title>Using tasksel and metapackages</title>
-<para>
- According to the plan of the project, the first metapackages (<xref
- linkend="metapackages"/>) should be developed. It is not always easy to
- decide what should be included, and which metapackages should be
- built. The best way to decide on this point is to discuss on the
- mailing list some well thought out proposals.
-</para>
-<para>
- Section <xref linkend="text_ui"/> mentions <package>tasksel</package> as a tool
- to select a Debian Pure Blend, and explains why it is currently not
- possible to get a Blend included into the task selection list.
-</para>
- </sect2>
-
-</sect1>
-
-<sect1 id="first_release">
- <title>First release</title>
-
-<sect2 id="release_announcement">
- <title>Release announcement</title>
- <para>
- Beyond the release announcement for Debian itself, it is necessary
- to put some thought and work into a release announcement for the
- first release of a Debian Pure Blend. This will not only
- be directed at the Debian developer community, but also at the users.
- This will include potential new Debian users abroad, who may not be
- on a Debian mailing list. Here, the same principle applies as for
- the first announcement of the project: it is important to consider
- sending the information to other relevant forums.
- </para>
-</sect2>
-
-<sect2 id="users">
- <title>Users of a Debian Pure Blend</title>
- <para>
- By this time, people have newly installed Debian along with the
- material in the Blend, or have installed the metapackages on their
- existing Debian systems. Now comes the fun part, building
- relationships with the user community.
- </para>
-
-<sect3 id="user_support">
- <title>Devoting resources to the users</title>
- <para>
- Users are a mixed blessing. In the first development phase there are
- some developers who are users, and some intrepid "early adopters."
- But once it is released, the first version is "out there," and the
- project will certainly attract all kinds of users who are not
- necessarily as technically savvy as your small development user
- community. Be prepared to spend some time with them. Be patient
- with them. And be listening carefully for the underlying questions
- beneath the surface questions. As draining as it can be to deal
- with users, they are a very key component to keeping your
- development effort vital.
- </para>
-</sect3>
-
-<sect3 id="devel_vs_user_list">
- <title>Developer vs. user mailing list</title>
- <para>
- Should a user list be created? It's not as cut-and-dried as it
- might at first appear. When user help requests start coming in,
- you might at first see them as a distraction from the development
- effort. However, you don't necessarily want to "ghettoize" the
- user community into a separate list early. That's a
- recipe for developers to get out of touch very quickly with the
- users. Tolerate the new user questions on the developer list
- for a while. Once a user list is finally set up, courteously
- redirect user questions to the user list. Treat your users as
- the valuable resource about how your project is working "in the
- field" that they are.
- </para>
-</sect3>
-
-<sect3 id="user_support_beyond_debian">
- <title>User support beyond Debian</title>
- <para>
- Fortunately, we're not in the business of supporting users alone.
- Look beyond Debian for your allies in user support: Linux user
- groups (LUGs) and the users themselves. Develop an awareness of who
- has stakes in seeing your project succeed, and enlist their help
- in getting a strong network of support established for your work.
- </para>
-</sect3>
-
-</sect2>
-
-</sect1>
-
-</chapter>
diff --git a/doc/en/08_websentinel.xml b/doc/en/08_websentinel.xml
deleted file mode 100644
index 0648a3a..0000000
--- a/doc/en/08_websentinel.xml
+++ /dev/null
@@ -1,491 +0,0 @@
-<chapter id="sentinel">
- <title>The web sentinel</title>
-
- <sect1 id="packageslist">
- <title>Existing and prospective packages</title>
-
-<para>
-The so called tasks pages probably give the most interesting overview
-about what a Blend is actually doing for newcomers as well as a nice
-quality assurance tool for developers. If you want to see examples
-for tasks pages just have a look at the
-<ulink url="http://blends.alioth.debian.org/">list of all Blends</ulink>
-using this technique and follow the links to the tasks pages once you
-selected one specific Blend.
-</para>
-<para>
-If a Debian Pure Blend should be presented one of the first questions
-is, what packages are available. The next question might be which
-packages are on the todo list for inclusion in Debian to make Debian
-even more attractive for people the Blend is targeting at. Both
-questions can be answered if you point people to the dynamically
-created tasks page. The page is rebuild daily to stay up to date
-according to recent developments of the Blend. The build process works
-as follows:
- <itemizedlist>
- <listitem><para>Read dependency information of the <filename>tasks</filename> files.</para></listitem>
- <listitem><para>Verify whether there is really a package with this name and
- print the description of this package.</para></listitem>
- <listitem><para>If there is no such package in Debian try to parse
- the <filename>tasks</filename> file whether there is some information
- given and mark the result as prospective package for further
- inclusion.</para></listitem>
- </itemizedlist>
-</para>
-<para>
-The rationale behind this is to provide as much as possible
-information about packages that might be interesting for the target
-user of the Blend. Moreover the page can provide useful information for
-developers about things that might be a useful help for the project to
-work down the todo list and build Debian packages for software that is
-not yet included in Debian.
-</para>
-</sect1>
- <sect1 id="edittasksfiles">
- <title>Tasks files controling web sentinel content</title>
-
-<para>
-
-The content of the tasks files that are used to build the metapackage
-content of a Blend is also used to determine the content of the web
-sentinel pages. Thus you can influence the tasks pages by simply
-editing the tasks files inside the VCS of the sources of the Blends
-metapackages. The canonical location of these tasks files inside the
-sources is (with the exception of Debian Edu that is locatet in Debian
-Edu SVN repositories) the Blends VCS at
-<informalexample>
- <programlisting>
- svn://svn.debian.org/svn/blends/projects/BLEND/trunk/SRCPKG/tasks
- </programlisting>
-</informalexample>
-or when using Git which is possible as well
-<informalexample>
- <programlisting>
- git://git.debian.org/git/blends/projects/BLEND.git
- </programlisting>
-</informalexample>
-Here you can add or remove additional Dependencies to existing packages
-or you can add additional information about so called prospective
-packages. The syntax how to do this is explained below.
-</para>
-
-<para>
-To get the todo list builded it is necessary to add some additional
-information to the task files which are the main database of information
-for the Blend. The information is following the RFC822 syntax as all
-Debian control files do and is kept quite simple:
-<variablelist>
-
-<varlistentry>
- <term>Depends / Recommends / Suggests</term>
- <listitem><para>Even if there is no Debian package available for the moment
- the names of prospective packages are given as if they would
- exists. The rationale behind is that once such a package
- might exist the source of the metapackage does not have to
- be changed and will work out of the box after rebuilding.</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Ignore</term>
- <listitem><para>The Ignore key should be the favourite way to use for
- specifying prospective packages in case the packages should be
- evaluated once it appears in the Debian package pool. If
- "Depends", "Recommends" or "Suggests" are used for not yet
- existing packages they will be turned into the list of Suggests
- of the metapackage and thus might be possible to become
- installed on a users machine if the user decides to install all
- suggested packages. If some evaluation should be done first the
- "Ignore" tag is your friend.</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Homepage</term>
- <listitem><para>This is the URL to the software that should be packaged.</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>WNPP</term>
- <listitem><para>In case there might be a WNPP bug filed for this software the
- bug number is given here. This helps to keep track of the
- ongoing effort to package the software.</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Responsible</term>
- <listitem><para>In case some developer claimed to care for the software
- (perhaps by issuing the WNPP bug report) the e-mail address of
- this developer is given here to enable an easy way to contact
- this person.</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>License</term>
- <listitem><para>Debian cares always about the license. This information
- about prospective packages should be easily available.</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Vcs-Svn</term>
- <listitem><para>If there is some Debian packaging stuff available this
- can be addressed in this field. Unofficial packages which
- have this field set are rendered in a separate section with
- links to the packaging SVN.
- </para><para>
- The usage for this field is the same as it is described in
- <ulink url="http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-vcs"
- > paragraph 6.2.5 of Debian developers reference</ulink>
- </para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Vcs-Git</term>
- <listitem><para>If there is some Debian packaging stuff available this
- can be addressed in this field. Unofficial packages which
- have this field set are rendered in a separate section with
- links to the packaging Git.
- </para><para>
- The usage for this field is the same as it is described in
- <ulink url="http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-vcs"
- >paragraph 6.2.5 of Debian developers reference</ulink>
- </para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Vcs-Browser</term>
- <listitem><para>If there is some Debian packaging stuff available this
- can be addressed in this field. Unofficial packages which
- have this field set are rendered in a separate section above
- unofficial packages outside the official Debian mirrors.
- If you have set <filename>Vcs-Svn</filename> or <filename>Vcs-Git</filename>
- there is no need to set <filename>Vcs-Browser</filename> explicitely
- because it is obtained automatically from the other fields.
- But you might override this automatically generated URL if
- needed.
- </para><para>
- The usage for this field is the same as it is described in
- <ulink url="http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-vcs"
- >paragraph 6.2.5 of Debian developers reference</ulink>
- </para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Pkg-URL</term>
- <listitem><para>In some cases there are unofficial packages for some software
- which are prepared by a third party. It helps our users if
- they could install such a package and thus the URL to it might
- be a helpful hint. This is also true for developers because
- they might have a look at this packaging before they start from
- scratch. Often packages are available
- at <ulink url="http://mentors.debian.net/"
- >mentors.debian.net</ulink> and prepared by people who do not
- yet have an official Debian maintainer status and thus are not
- able to upload packages to the Debian mirror. The packages at
- mentors are waiting for sponsoring of an official Debian
- maintainer and if such a package shows up in the Blend tasks list
- it might speed up the inclusion into official Debian
- distribution.</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Pkg-Description</term>
- <listitem><para>This tag should give reasonable information about the
- software as it normally is done in <filename>debian/control</filename>
- files. It can be either a copy of the description of the WNPP
- bug or could be used to file a WNPP bug and thus helps to
- simplify the packaging work.</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Remark</term>
- <listitem><para>In some cases it makes perfectly sense to add a remark on
- behalf of the Blends team to a package which is visible on the
- tasks page. This can be done using the Remark field. It can
- be used in the same syntax as a Description field in Debian
- control files.</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Registration</term>
- <listitem><para>Sometimes, specifically in the case of scientific software,
- the project authors ask for registration of their software to
- get numbers of users of their software. These numbers enable
- them to ask for further funding of their project. To support
- this intend of authors the tasks pages can feature a link to
- this registration page if the link is given in the tasks file
- in the Registration field.</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Published-* (deprecated)</term>
- <listitem>
- <para>These tags were previouosely used to specify scientific
- publications. Its use is now deprecated and you rather
- should use the file <filename>debian/upstream</filename> as documented in
- <ulink url="http://wiki.debian.org/UpstreamMetadata">Debian
- Wiki</ulink>. The <filename>debian/upstream</filename> files will be gathered
- in their state in SVN - so changes become effective after some
- delay caused by cron jobs. This new way to handle publications
- prevents code duplication and can be used more flexible by single
- maintainers and is also useful for other purposes than only for
- Blends sentinel.
- </para>
- </listitem>
-</varlistentry>
-
-</variablelist>
-</para>
-
-<sect2 id="webconf">
-<title>Configuring Web Sentinel pages per Blend</title>
-
-<para>
-To set some typical values for the web sentinel per Blend each Blend
-has to provide a configuration file. These files are formatted in
-RFC822 files and
-<ulink url="http://svn.debian.org/wsvn/blends/blends/trunk/webtools/webconf/"
- >maintained in SVN</ulink>. The following values can be set:
-<variablelist>
-
-<varlistentry>
- <term>Blend</term>
- <listitem><para>Id of the Blend (for instance debian-edu, debian-med, etc.)</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>ProjectName</term>
- <listitem><para>Name the Blend in correct spelling. Please note that English
- spelling is without a dash and it is "Debian Edu" (not
- Debian-Edu) and Debian Med (not Debian-Med)</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>ProjectUrl</term>
- <listitem><para>URL to technical information about the Blend</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Homepage</term>
- <listitem><para>URL to the user oriented homepage of the Blend</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>AliothUrl</term>
- <listitem><para>URL of the Alioth project of the Blend (might be identical to
- ProjectUrl)</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>LogoUrl</term>
- <listitem><para>URL to a logo image of the Blend</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>ProjectList</term>
- <listitem><para>E-Mail address of a mailing list where developers and users
- of the Blend are communicating</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>PkgList</term>
- <listitem><para>E-Mail address of a mailing list where developers of the
- Blend are discussing technical details of packaging</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>OutputDir</term>
- <listitem><para>Directory where to put the rendered HTML pages. The Blends
- pages are hosted on Alioth and usually stored
- at <filename>/var/lib/gforge/chroot/home/groups/blends/htdocs/<ProjectName></filename>
- </para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>DataDir</term>
- <listitem><para>Directory where the rendering code stores temporary data like
- SVN checkout of tasks files etc. This is usually set to
- <filename>/var/lib/gforge/chroot/home/groups/blends/data/<ProjectName></filename>
- </para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>VcsDir</term>
- <listitem><para>Path to tasks files in Blends SVN
- <filename>/svn/blends/projects/science/trunk/<ProjectName></filename>
- </para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>CSS</term>
- <listitem><para>In case a CSS file different from the default Blend CSS is
- wanted for a specific Blend a (relative) path to this file can be specified.</para>
- </listitem>
-</varlistentry>
-
-</variablelist>
-</para>
-
-</sect2>
-
- <sect2 id="ddtp">
- <title>Debian Description Translation Project</title>
-
-<para>
-The <ulink url="http://ddtp.debian.net/">Debian Description
-Translation Project</ulink> (see <xref linkend="documentation"/> ) provides users of
-non English languages with information about Debian packages. The
-sense of supporting especially the translations of descriptions which
-are in the focus of a Blend is to make the Blend even more usable for our
-target users. Moreover people interested in the special field of the
-Blend are most probably able to provide good translations if it comes to
-texts that are specific to their field of knowledge. Thus there is a
-web page automatically created that parses the tasks packages for
-package names and verifies the translation status of the package
-descriptions.
-</para>
-<para>
-Finally the DDTP descriptions are used to create internationalised
-pages of existing packages which might help users with insufficient
-skills in English to easily find their software of interest. If the
-browser locale is properly set the user will get translated
-descriptions of existing packages - provided that the DDTP
-translations for all these packages are existing.
-</para>
-
- </sect2>
-
- <sect2>
- <title>Features of the web sentinel tasks pages</title>
-<para>
- For so called prospective packages - packages which are not yet in
- Debian as discussed above - only the information given explicitely in
- the tasks file can be provided. For official packages the Debian
- infrastructure provides a lot of metadata, that is collected in the
- Ultimate Debian Database (UDD). The script which is creating the web
- sentinel pages collects all this data from UDD and tries to provide
- the most comprehensive overview over a set of packages for a given
- task of a Blend. The following list gives an overview over the
- metadata of packages belonging to the tasks of a Blend.
-</para>
-<para>
-
-<variablelist>
-
-<varlistentry>
- <term>Short and long Description</term>
- <listitem><para>If there is a DDTP translation the descriptions are translated.</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Homepage</term>
- <listitem><para>The Homepage field is taken from
- the <filename>debian/control</filename> file. If this information is
- missing for some package on the tasks page it might be a sign
- that the package is not properly maintained and deserves a
- wishlist bug report to add this information (at least for
- non-native Debian packages.</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Maintainer / last Uploader</term>
- <listitem><para>Both are provides as mailto-links. If the latest Uploader is
- different from the Maintainer this information is given as well.
- This is specifically interesting for group maintained packages -
- actually a tendency in Blends to maintain packages as Blends team
- - where the maintainer is the Blends team and the Uploader is the
- name of the actual developer who uploaded the package.</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Popularity contest</term>
- <listitem><para>The popularity contest database contains different values.
- The tasks page is presenting the most relevant of them: the
- number of people who really use this package regularly and the
- number of people who upgraded this package recently</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Versions and architectures</term>
- <listitem><para>A button can be used to uncover the versions of this package
- in the Debian package pool as well as the architectures for which
- this version exists. The button is coloures in yellow if there
- is a new upstream version available which enables the Blends
- packaging team to easily detect work items to do.</para>
- </listitem>
-</varlistentry>
-
-</variablelist>
-</para>
- </sect2>
- </sect1>
-
- <sect1 id="bugs">
- <title>Bugs overview</title>
-<para>
-The goal of a Blend is to support their user as best as possible. So a
-feature to have a quick overview about all packages in our focus might
-be helpful. This is solved by the bugs overview page. To create this
-page the <filename>tasks</filename> files are parsed for the listed
-dependencies. Then the Debian Bug Tracking System is consulted about
-known bugs of these packages. All bugs are listed and marked with
-different colours according to their severity. So the developers can
-easily check this page in case they plan to fix some bugs that are
-relevant for the Blend.
-</para>
-<para>
-If you want to see examples for those bugs pages just have a look at the
-<ulink url="http://blends.alioth.debian.org/">list of all Blends</ulink>
-using this technique and follow the links to the bugs pages once you
-selected one specific Blend.
-</para>
-
- </sect1>
-
- <sect1 id="svnoverview">
- <title>SVN overview</title>
-<para>
-This page gives a recent overview about the current development
-activities of the Blend developers.
-</para>
- </sect1>
-
- <sect1 id="qareport">
- <title>Quality assurance report</title>
-
-<para>
-The Debian Quality Assurance group does a decent job in watching the
-status o f Debian packages. If a package features a
-valid <filename>debian/watch</filename> the tool <package>uscan</package> is able to
-verify the upstream source location for newer versions. The QA report
-page reports issues about the packages that are relevant for a Blend.
-</para>
- </sect1>
-
-</chapter>
diff --git a/doc/en/09_todo.xml b/doc/en/09_todo.xml
deleted file mode 100644
index eccdbc2..0000000
--- a/doc/en/09_todo.xml
+++ /dev/null
@@ -1,499 +0,0 @@
-<chapter id="todo">
- <title>To do</title>
-
- <sect1 id="communication">
- <title>Establishing and using communication platforms</title>
-
-<para>
-Each Debian Pure Blend has an own mailing list for discussion of
-specific development issues. Because there are several common issues
-between all Blends also a common mailing list was created. People who
-are interested in working on common issues like building metapackages,
-technical issues of menu systems or how to create CDs for Blends
-could <ulink url="http://lists.debian.org/debian-blends/">subscribe
-to this list or read the list archive</ulink>.
-</para>
-<para>
-Moreover the project <ulink url="http://alioth.debian.org/projects/blends/">
-Blends</ulink> on Alioth exists to organise the cooperation of developers.
-The <ulink url="http://svn.debian.org/wsvn/blends/">subversion repository</ulink>
-can be browsed or checked out by by
-<informalexample>
- <programlisting>
- svn checkout svn://svn.debian.org/svn/blends blends
-</programlisting>
-</informalexample>
-<programlisting>
-for anonymous users. Developers should check out via
-</programlisting>
-<informalexample>
- <programlisting>
- svn checkout svn+ssh://<varname>username</varname>@svn.debian.org/svn/blends blends
-</programlisting>
-</informalexample>
-<programlisting>
-The current layout for the repository is as follows:
-</programlisting>
-<informalexample>
- <programlisting>
- blends -+- blends
- | |
- | +- tags -----+- blends -+- 0.3 [older versions of blends tools]
- | | | +- 0.3.1
- | | | ...
- | | | +- <varname><latest></varname>
- | | |
- | | +- doc -+- 0.1 [older versions of this doc]
- | | +- 0.2
- | | +- 0.3
- | | [Since 0.4.1 the doc is in blends directory]
- | |
- | +- trunk ----blends [code in development for blends source package]
- | |
- | +-- doc [this document = blends-doc package]
- |
- +- projects -+--- med ---+- tags
- | |
- | +- trunk [development version of Debian Med]
- |
- +- science -+- tags
- | |
- | +- trunk [development version of Debian Science]
- |
- +- ...
- |
- ...
- </programlisting>
-</informalexample>
-There is
-a <ulink url="http://lists.alioth.debian.org/mailman/listinfo/blends-commits">
-mailing list</ulink> with subversion changes and
-a <ulink url="http://cia.navi.cx/stats/project/debian-custom">CIA
-system</ulink> for tracking changes in the Debian Pure Blends projects in
-real-time.
-</para>
- </sect1>
-
- <sect1 id="visibility">
- <title>Enhancing visibility</title>
-
-<para>
-If a user installs Debian via official install CDs the first chance to
-do a package selection to customise the box is <package>tasksel</package>.
-The first Debian Pure Blend Debian Junior is mentioned in the
-task selection list and thus it is clearly visible to the user who
-installs Debian.
-</para>
-<para>
-In bug <ulink url="http://bugs.debian.org/186085">#186085</ulink> a
-request was filed to include Debian Med in the same manner. The
-problem with the <package>tasksel</package>-approach is that all included
-packages should be on the first install CD. This would immediately
-have the consequence that the first install CD would run out of space
-if all Blends would be included in the task selection list.
-</para>
-<para>
-How to enhance visibility of Debian Pure Blends for the user who
-installs Debian from scratch?
-<variablelist>
-
-<varlistentry>
- <term>Change <package>tasksel</package> policy.</term>
- <listitem><para>If the <emphasis>packages must be on the first CD</emphasis> feature of
- <package>tasksel</package> would be dropped all Blends could be
- listed under this topic in the task selection list.</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Debian Pure Blends information screen.</term>
- <listitem><para>Alternatively a new feature could be added to
- <package>tasksel</package> or in addition to <package>tasksel</package>
- in the installation procedure which presents a screen which
- gives some very short information about Debian Pure Blends
- (perhaps pointing to this document for further reference) and
- enables the user to select from a list of the available
- Blends.</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Provide separate install CDs</term>
- <listitem><para>By completely ignoring the installation of the official
- installation CD each Blend can offer a separate installation
- CD. This will be done anyway for certain practical reasons
- (see for instance the Debian Edu - SkoleLinux approach). But
- this is really no solution we could prefer because this does
- not work if the user wants to install more than one Blend on
- one computer.</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Change overall distribution philosophy of Debian.</term>
- <listitem><para>This way is concerned to some ideas from Debian developers
- who took part in Open Source World Conference in Malaga and
- is explained in Detail
- in <xref linkend="new_ways_of_distribution"/>. This would save the
- problem of making Debian Pure Blends visible to users in a
- completely different way because in this case Debian would be
- released as its various flavours of Blends.</para>
- </listitem>
-</varlistentry>
-</variablelist>
-</para>
-<para>
-Whichever way Debian developers will decide to go it is our vital
-interest to support users and <emphasis>show</emphasis> our users the tools we
-invented to support them.
-</para>
- <sect2 id="webpages">
- <title>Debian Pure Blends web pages</title>
-<para>
-Some Blends maintain their own web space under
-<package>http://www.debian.org/devel/BLEND-name</package> to provide general
-information which will be translated by the Debian web team. This is a
-good way to inform users about the progress of a project. This page
-should link to the apropriate autogenerated pages as described
-in <xref linkend="web_if"/> to make sure that the content of the page remains
-up to date at any time.
-</para>
- </sect2>
- </sect1>
-
- <sect1 id="debtags">
- <title>Debian Package Tags</title>
-
-<para>
-<ulink url="http://debtags.alioth.debian.org/">Debian
-Package Tags</ulink> is a work to add more metadata to Debian packages.
-At the beginning it could be seen as a way to allow to specify
-multiple sections (called "tags") per package where now only one can
-be used.
-</para>
-<para>
-However, the system has evolved so that tags are organised in
-"facets", which are separate ontologies used to categorise the
-packages under different points of view.
-</para>
-<para>
-This means that the new categorisation system supports tagging
-different facets of packages. There can be a set of tags for the
-"purpose" of a package (like "chatting", "searching", "editing"),
-a set of tags for the technologies used by a package (like "html",
-"http", "vorbis") and so on.
-</para>
-<para>
-Besides being able to perform package selection more efficiently by
-being able to use a better categorisation, one of the first outcomes
-of Debian Package Tags for Blends is that every Blend could maintain
-its own set of tags organised under a "facet", providing
-categorisation data which could be used by its users and which
-automatically interrelates with the rest of the tags.
-</para>
-<para>
-For example, Debian Edu could look for "edu::administration" packages
-and then select "use::configuring". The "edu::administration"
-classification would be managed by the Debian Edu people, while
-"use::configuring" would be managed by Debian. At the same time, non
-Debian Edu users looking for "use::configuring" could have a look at
-what packages in that category are suggested by the Debian Edu
-community.
-</para>
-<para>
-It is not excluded that this could evolve in being able to create a
-Blend just by selecting all packages tagged by "edu::*" tags, plus
-dependencies; however, this option is still being investigated.
-</para>
-<para>
-Please write to the
-list <email>deb-usability-list at lists.alioth.debian.org</email> for
-more information about Debian Package Tags or if you want to get
-involved in Debian Package Tags development.
-</para>
- </sect1>
-
- <sect1 id="EnhancingTechnology">
- <title>Enhancing basic technologies regarding Debian Pure Blends</title>
-
-<para>
-In section <xref linkend="future_handling"/> several issues where raised how
-handling of metapackages should be enhanced.
-</para>
-<para>
-Currently there is no solution to address the special configuration
-issue has to be addressed. In general developers of metapackages
-should provide patches for dependent packages if they need a certain
-configuration option and the package in question does feature a
-<orgname>debconf</orgname> configuration for this case. Then the
-metapackage could provide the needed options by pre-seeding the
-<orgname>debconf</orgname> database while using very low priority questions
-which do not came to users notice.
-</para>
-<para>
-If the maintainer of a package which is listed in a metapackage
-dependency and needs some specific configuration does not accept such
-kind of patch it would be possible to go with a <package>cfengine</package>
-script which just does the configuration work. According to the
-following arguing this is no policy violation: A local maintainer can
-change the configuration of any package and the installation scripts
-have to care for these changes and are not allowed to disturb these
-adaptations. In the case described above the <package>cfengine</package>
-script takes over the role of the local administrator: It just handles
-as an
-"automated-<package>cfengine</package>-driven-administrator-robot".
-</para>
-<para>
-If there is some agreement to use <package>cfengine</package> scripts to
-change configuration - either according to <orgname>debconf</orgname>
-questions or even to adapt local configuration for Debian Pure Blend
-use in general - a common location for this kind of stuff should be
-found. Because these scripts are not configuration itself but
-substantial part of a metapackage the suggestion would be to store
-this stuff under
-<informalexample>
- <programlisting>
- /usr/share/blends/#BLEND#/#METAPACKAGE#/cf.#SOMETHING#
- </programlisting>
-</informalexample>
-</para>
-<para>
-There was another suggestion at the Valencia workshop: Make use of
-<package>ucf</package> for the purpose mentioned above. This is a topic
-for discussion. At least currently Debian Edu seems to have good
-experiences with <package>cfengine</package> but perhaps it is worth comparing
-both.
-</para>
-<para>
-A further option might be
-<ulink url="http://freedesktop.org/Software/CFG">Config4GNU</ulink> from
-freedesktop.org but it is not even yet packaged for Debian.
-</para>
- </sect1>
-
- <sect1 id="liveCD">
- <title>Building Live CDs of each Debian Pure Blend</title>
-
-<para>
-The first step to convince a user to switch to Debian is to show him
-how it works while leaving his running system untouched.
-<ulink url="http://www.knoppix.org/">Knoppix</ulink> - <emphasis>the "mother" of
-all Debian-based live CDs</emphasis> - is a really great success and it is a
-fact that can not be ignored that Debian gains a certain amount of
-popularity because people want to know what distribution is working
-behind the scenes of Knoppix.
-</para>
-<para>
-But Knoppix is a very common demonstration and its purpose is to work
-in everyday live. There is no room left for special applications and
-thus people started to adopt it for there special needs. In fact
-there exist so many Debian based Live CDs that it makes hardly sense
-to list them all here. The main problem is that most of them
-containing special applications and thus are interesting in the Blends
-scope are out of date because they way the usually were builded was a
-pain. One exception is
-perhaps <ulink url="http://dirk.eddelbuettel.com/quantian.html">
-Quantian</ulink> which is quite regularly updated and is intended for
-scientists.
-</para>
-<para>
-The good news is that the problem of orphaned or outdated Live CDs can
-easily solved by debian-live and the <package>live-helper</package>.
-This package turns all work to get an up to date ISO image for a Live
-CD into calling a single script. For the Blends tools this would
-simply mean that the tasks files have to be turned into a live-helper
-input file and the basic work is done. This will be done in a future
-<package>blends-dev</package> version.
-</para>
-
- </sect1>
-
- <sect1 id="new_ways_of_distribution">
- <title>New way to distribute Debian</title>
-
-<para>
-<emphasis>This section is kind of "Request For Comments" in the sense that
-solid input and arguing is needed to find out whether it is worth
-implementing it or drop this idea in favour of a better solution.</emphasis>
-</para>
-<para>
-At Open Source World Conference in Malaga 2004 there was a workshop of
-Debian Developers. Among other things the topic was raised how the
-distribution cycle or rather the method of distribution could be
-changed to increase release frequency and to better fit user interests.
-</para>
-<para>
-There was a suggestion by Bdale Garbee <email>bdale at gag.com</email> to
-think about kind of sub-setting Debian in the following way: Debian
-developers upload their packages to <package>unstable</package>. The normal
-process which propagates packages to <package>testing</package> and releasing a
-complete <package>stable</package> distribution also remains untouched. The new
-thing is that the package pool could be enhanced to store more package
-versions which belong to certain subsets alias Debian Pure Blends
-which all have a set of <package>tested inside the subset</package> distribution
-which leads to a <package>stable</package> subset release. The following graph
-might clarify this:
-
-<informalexample>
- <programlisting>
-DD -> unstable --> testing --> stable
- |
- +---> BLEND_A testing --> stable BLEND_A
- |
- +---> BLEND_B testing --> stable BLEND_B
- |
- +---> ...
- </programlisting>
-</informalexample>
-
-where <package>BLEND_A</package> / <package>BLEND_B</package> might be something like
-<package>debian-edu</package> / <package>debian-med</package>. To implement this
-sub-setting the following things are needed:
-<variablelist>
-
-<varlistentry>
- <term>Promotion rules</term>
- <listitem><para>There was a general agreement that technical implementation
- of this idea in the package pool scripts / database is not too
- hard. In fact at LinuxTag Chemnitz 2004 Martin Loschwitz
- <email>madkiss at debian.org</email> announced exactly this as
- "nearly implemented for testing purpose" which should solve
- the problem of outdated software for desktop users as a goal
- of the <package>debian-desktop</package> project. Unfortunately this
- goal was not realised finally.</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Reasonable subsets</term>
- <listitem><para>Once the promotion tools are able to work with sub-setting,
- reasonable subsets have to be defined and maintained. A
- decision has to be made (if this will be implemented at all)
- whether this sub-setting should be done according to the
- Blend layout or if there are better ways to find subsets.</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>BTS support</term>
- <listitem><para>The Bug Tracking System has to deal with different package
- versions or even version ranges to work nicely together with
- the sub-setting approach.</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Security</term>
- <listitem><para>As a consequence of having more than only a single
- <package>stable</package> each Blend team has to form a security team
- to care for those package versions that are not identically
- with the "old" <package>stable</package>.</para>
- </listitem>
-</varlistentry>
-
-</variablelist>
-</para>
-<para>
-A not so drastically change would be to find a <emphasis>common</emphasis> set of
-packages which are interesting for all Debian Pure Blends which will
-obtained from the "releasable set" of testing (i.e. no
-RC-bugs). This would make the structure above a little bit more flat:
-
-<informalexample>
- <programlisting>
-DD -> unstable --> testing --> releasable --> stable
- |
- +---> stable BLEND_A
- |
- +---> stable BLEND_B
- |
- +---> ...
- </programlisting>
-</informalexample>
-<programlisting>
-A third suggestion was given at Congreso Software Libre Comunidad
-Valenciana:
-</programlisting>
-<informalexample>
-<programlisting>
- testing_proposed_updated
- |
- |
- v
-DD -> unstable --> testing --> stable
- |
- +---> stable BLEND_A
- |
- +---> stable BLEND_B
- |
- +---> ...
-</programlisting>
-</informalexample>
-
-The rationale behind these testing backports is that sometimes a
-Debian Pure Blend is able to reduce the set of releasable
-architectures. Thus some essential packages could be moved much
-faster to testing and these might be "backported" to testing
-for this special Blend. For instance this might make sense for Debian
-Edu where usually neither mainframes nor embedded devices are used.
-</para>
-<para>
-All these different suggestions would lead to a modification of the
-package pool scripts which could end up in a new way to distribute
-Debian. This might result from the fact that some Debian Pure Blends
-need a defined release cycle. For instance the education related
-distributions might trigger their release by the start-end-cycle of
-the school year. Another reason to change the package pool system is
-the fact that some interested groups, who provide special service for
-a certain Blend, would take over support only for the subset of
-packages which is included in the metapackage dependencies or
-suggestions but they refuse to provide full support for the whole
-range of Debian packages. This would lead to a new layout of the file
-structures of the Debian mirrors:
-
-<informalexample>
-<programlisting>
- debian/dists/stable/binary-i386
- /binary-sparc
- /binary-...
- /testing/...
- /unstable/...
- debian-BLEND_A/dists/stable/binary-[supported_architecture1]
- /binary-[supported_architecture2]
- /...
- /testing/...
- debian-BLEND_B/dists/testing/...
- /stable/...
- ...
- pool/main
- /contrib
- /non-free
-</programlisting>
-</informalexample>
-To avoid flooding the archive with unnecessarily many versions of
-packages for each single Debian Pure Blend a common base of all these
-Blends has to be defined. Here some LSB conformance statement comes
-into mind: The base system of all currently released (stable) Debian
-Pure Blends is compliant to LSB version x.y.
-</para>
-<para>
-Regarding to security issues there are two ways: Either one Debian
-Pure Blend goes with the current stable Debian and thus the
-<filename>Packages.gz</filename> is just pointing to the very same versions
-which are also in debian/stable. Then no extra effort regarding to
-security issues is need. But if there would be a special support team
-which takes over maintenance and security service for the packages in
-a certain Blend they should be made reliable for this certain subset.
-</para>
-<para>
-This reduced subset of Debian packages of a Debian Pure Blend would
-also make it easier to provide special install CDs at is it currently
-done by Debian Edu.
-</para>
- </sect1>
-</chapter>
-
-<!--
- line 82,90,99-106,234-243 package was prgn
- lines 326-390 package elements where tt : need to find a replacement for this element
--->
diff --git a/doc/en/A_devel.xml b/doc/en/A_devel.xml
deleted file mode 100644
index 8da6172..0000000
--- a/doc/en/A_devel.xml
+++ /dev/null
@@ -1,837 +0,0 @@
- <appendix id="DevelDescription">
- <title>Description of development tools</title>
- <sect1 id="blends-dev">
- <title>Package <package>blends-dev</package></title>
-
-<para>
-If metapackages are builded using the tools inside the
-<package>blends-dev</package> package it can be ensured that the
-resulting metapackages will work nicely with the same version of
-<package>blends-common</package> package. The goal is to keep
-necessary changes for the source of the metapackages of a Debian Pure
-Blend as low as possible when the version of the
-<package>blends</package> source package changes. Thus it is
-strongly recommended to use the tools described below.
-</para>
-<para>
-The usage of the tools in the <package>blends-dev</package> package might
-introduce a versioned dependency in the
-<varname><blend></varname>-<package>config</package> package from which
-all other metapackages of the <varname>Blend</varname> in question will
-depend. This <varname><blend></varname>-<package>config</package> package
-instantiates the <varname>Blend</varname> in the common registry for all Blends in
-<filename>/etc/blends</filename>.
-</para>
-
-<para>
-The version <package>0.7.0</package> of <package>blends-dev</package> uses
-<ulink url="https://wiki.debian.org/UltimateDebianDatabase">UDD</ulink>
-to generate Blends' metapackages. Currently all Blends' info is stored into UDD.
-Information such as VCs, description, homepage etc for a Blend can be found into the
-<ulink url="http://udd.debian.org/schema/udd.html#public.table.blends-metadata">blends_metadata</ulink>
-UDD table. All the info about Blends' tasks and their package dependencies are also stored
-into the <ulink url="http://udd.debian.org/schema/udd.html#public.table.blends-tasks">blends_tasks</ulink> and
-<ulink url="http://udd.debian.org/schema/udd.html#public.table.blends-dependencies-alternatives">
-blends_dependencies_alternatives</ulink>
-tables. Having the latter in combination with other UDD tables
-(such as a table with info about all Debian available packages)
-provides the ability to check whether a package exists for an architecture or not thus
-<package>blends-dev</package> can generate architecture dependent metapackages.
-</para>
-
-<para>
-The best idea to use the tools provided by the
-<package>blends-dev</package> is to put a <filename>Makefile</filename> into the
-build directory containing one single line
-
-<informalexample>
- <programlisting>
- include /usr/share/blends-dev/Makefile
- </programlisting>
-</informalexample>
-
-(see <filename>/usr/share/doc/blends-dev/examples/Makefile</filename>).
-Users using <package>blends-dev 0.7.0</package> on existing Blends
-which have more than one releases might encouter some <filename>Makefile</filename>
-errors for more info see <xref linkend="statusdump"/> and <xref linkend="changelogentry"/>.
-
-Using this <filename>Makefile</filename> all tools that were contained in
-<package>blends-dev</package> package versions before 0.4. These tools
-are moved to <filename>/usr/share/blends-dev/</filename> because there is no need
-to call them directly. Here is a list of the <filename>make</filename> targets.
-</para>
-
-<sect2 id="blends-tasks.desc">
- <title>Blend<package>-tasks.desk</package></title>
-
-<para>
-This target generates a <package>task-description.template</package> file.
-The template can be converted to a proper description file that is used in
-<package>tasksel</package> to enable selecting the tasks belonging to the Blend.
-The initial template contains all the needed package dependencies
-for a Blend. But because some packages might not be available for a(or multiple)
-architectures the template uses the following syntax when specifying packages:
-<informalexample><programlisting> package1 [!arch1 arch2]</programlisting></informalexample>
-
-That says do not include the package1 in the
-taskdescription file when arch1 or arch2 is used.
-When a Blends' <package>orig.tar.gz</package> is generated,
-the initial template gets converted
-from the <package>blends-dev rules</package> file to a proper taskdescription file.
-The convertion is filtering out the packages which are not available for the
-host's (where the <package>orig.tar.gz</package> is generated) architecture.
-This make sure that the taskdescription file will not include package which are
-not available for the target architecture.
-Finally the file will be moved to the
-<varname>blend</varname><package>-tasks</package>. All information
-about Blends package dependencies is obtained from the UDD.
-</para>
-
-</sect2>
-<sect2 id="debian_control">
- <title><filename>debian/control</filename></title>
-
-<para>
-The <filename>debian/control</filename> file of a Blend metapackage source
-archive is auto generated out of dependencies that are specified in so
-called <filename>tasks</filename> files. The rationale behind this is to
-enhance flexibility about changes inside the Debian package pool where
-new packages might appear and others might be renamed.
-The <filename>tasks</filename> just define which dependencies the Blend
-maintainer group wants to be fulfilled and the
-script <package>blend-gen-control</package> using UDD verifies whether these
-dependencies exist in a specified package pool. A
-package pool can be considered as the packages available for a
-combination of distribution, component and release values. By default when
-creating metapackages debian,main,testing values are used to "create" a package pool from UDD.
-Once a Blends' dependencies are verified the <filename>debian/control</filename> file is generated
-according to the available packages. This does not only work for the Debian package pool
-containing the distributions stable, testing and unstable. You can
-even build your metapackages against a different package pool of a
-Debian based distribution. This is for instance used to create the
-SkoleLinux metapackages.
-</para>
-
-<para>
-As mentioned in the previous section, using UDD in Blends' tools provides the ability to generate
-architecture dependent metapackages. Thus the generated
-<package>debian/control</package> specifies for every task source target as architecture value:
-<informalexample>
- <programlisting>Architecture: any</programlisting></informalexample>
-
-Specifying <package>any</package> indicates that the source package isn't dependent
-on any particular architecture and should compile fine on any one. To fulfil this
-in case of missing packages <package>control</package> file uses the following syntax:
-
-<informalexample>
- <programlisting>Depends: package1 [!arch1 !arch2]</programlisting></informalexample>
-
-If a package is not available for a specific arch, exclude it from it. So the above example says:
-depend on package1 but not when architecture arch1 or arch2 is used. More info about
-<package>debian/control</package> syntax can be found in
-<ulink url="http://www.debian.org/doc/debian-policy/">Debian Policy Manual</ulink>
-</para>
-
-<para>
-The syntax of the <filename>tasks</filename> files which serve as the central
-database for the information in the <filename>debian/control</filename> file
-is defined by RFC822. Some of the tags were mentioned formerly in
-<xref linkend="packageslist"/> to explain how the <filename>tasks</filename> files
-can be used to create the web sentinel pages. Now the tags that
-influence the creation of the <filename>debian/control</filename> file are given.
-</para>
-<para>
- <variablelist>
-
- <varlistentry>
- <term>Depends</term>
- <listitem><para>Will be turned to "Recommends" in the
- resulting <filename>debian/control</filename> file. The
- rationale behind this is to enable installing the
- metapackage even if a package belonging to this task is
- missing for whatever reason. It also allows finally to
- remove the metapackage. This makes even more
- sense since <package>apt-get</package> considers "Recommends"
- as default installation targets.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Recommends</term>
- <listitem><para>The packages that are listed as "Recommends" in the
- tasks file should be installed on the machine where the
- metapackage is installed and which are needed to work
- on a specific task.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Suggests</term>
- <!-- [BA] Why would we suggest non-free? Doesn't policy allow a non-free
- package to specify "Enhances" to avoid this problem?
- [AT] I have to admit that "Enhances" is new to me. When
- reading policy I think this field is out of control of
- the metapackage developer because it has to be included
- by the package maintainer. I'm not really convinced that
- this is a good solution - but I would follow the suggestions
- of others in this issue.
- -->
- <listitem><para>Use "Suggests" for packages of lesser importance that
- might be possibly useful, or non-free packages.</para>
- <para>
- If a package is not available in the package pool of the
- target distribution when creating
- the <filename>debian/control</filename> file inside the meta
- package source archive any "Depends" or "Recommends" are
- turned into "Suggests" to enable a flawless installation
- of the metapackage. Generally packages are concerned as missing if
- they do not exist into Debian main component(default is testing release).
- Packages that are specified with
- "Suggests" will not be taken over to
- the <package>tasksel</package> control file
- (Blend<filename>-tasks.desk</filename>,
- see <xref linkend="blends-tasks.desc"/>) but only to the list of
- suggested packages of the according metapackage.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Ignore</term>
- <listitem><para>The "Ignore" key can be used as kind of "Soft-Suggests"
- to put a package on the radar of the Blend. Packages that
- are tagged with Ignore will not be taken over into the
- list of dependencies inside
- the <filename>debian/control</filename> file of the resulting
- metapackage neither to the Blend<filename>-tasks.desk</filename>
- control file for <package>tasksel</package> but will be taken
- over onto the installation medium of a Blend in case there
- is some space left. This key becomes especially
- important for specifying not yet packaged software that
- might be packaged in the future (prospective packages).
- This is explained in detail in the paragraph about the
- web sentinel (see <xref linkend="packageslist"/>).</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Avoids</term>
- <listitem><para>The "Avoids" key specifies existing packages that will
- be listed in the the <filename>debian/control</filename> file as
- "Recommends" or "Suggests" but, should not go to a
- installation medium (CD, DVD, etc.) that might be
- produced by the Blend. A reason to avoid a package might
- be that it belongs to the non-free section.</para>
- </listitem>
- </varlistentry>
-
- </variablelist>
-</para>
-</sect2>
-
-<sect2 id="statusdump">
- <title><package>statusdump</package></title>
-
-<para>
-This target generates a json file containing the latest package dependencies
-for the selected Blend. It parses the files from the <package>tasks</package> directory
-and generates a <varname>blend</varname><package>_version.json</package> into a <package>dependency_data</package>
-directory. As <package>version</package> it gets the latest version specified in the Blend's
-<package>debian/changelog</package> file. In case the <package>dependency_data</package> directory
-does not exist into a Blend's root directory it automatically creates it.
-</para>
-
-<para>
-A user can also generate a json dependencies file manually
-using the <package>tasks_diff</package> script. The script can be called
-from a Blend's root directory:
-
-<informalexample>
- <programlisting>
- /usr/share/blends-dev/task_diff --status-dump --tasks . --output blend_version.json
-</programlisting>
-</informalexample>
-If the user does not specify the output argument the script by default
-will generate the json file under the <package>tasks.json</package> name in the
-current directory.
-</para>
-
-<para>
-Note: in case a user needs to generate a json file for a previous release
-(rather than the latest) to get the <package>changelogentry</package>
-(see <xref linkend="changelogentry"/>) target to work, must keep the following thing in mind:
-
-The user must provide to <package>task_diff</package> script the <emphasis>root</emphasis> directory of a previous Blend release
-(through the --task(-t) argument). He should also save the output into the <package>dependency_data</package>
-directory into the latest Blend release providing manually
-the name <varname>blend</varname><package>_version.json</package> (through the --output(-o) argument:
-
-<informalexample>
- <programlisting>
-/usr/share/blends-dev/task_diff --status-dump -t blend/tags/previous/ -o latest_blend/dependency_data/blend_version.json
-</programlisting>
-</informalexample>
-
-For example if the name of the Blend is <package>myblend</package> and the release is <package>0.2.0</package>
-then the json file must have the name <package>myblend_0.2.0.json</package>
-</para>
-
-</sect2>
-
-<sect2 id="changelogentry">
- <title>changelogentry</title>
-
-<para>
-This target compares the latest and the previous Blend release and dumps the tasks'
-package differences. It reports the added/removed packages
-per task (or added/removed task files)
-between releases. This "report" is automatically
-added into the <filename>debian/changelog</filename>
-in the latest relase section under the file's manual changes.
-In case a previous difference report
-exists, it overrides it. In case a Blend does not have more than release
-(initial release) then this target is ignored.
-</para>
-
-<para>
-In order the comparison to be properly performed the
-<varname>blend</varname><filename>_version.json</filename> files for the two latest releases
-must exist under the <filename>dependency_data</filename> directory. In case any of the
-previous files is missing then the target will fail with an error
-(specifying the missing version_file). The json file for the latest
-release is automatically generated from the <package>statusdump</package> target
-so it this will not cause the problem.
-</para>
-
-<para>
-This changelog entry is a new feature so the problem of this target failing
-(because of a missing json file) will appear for existing Blends which have
-more than one releases and do not have a <varname>blend</varname><filename>_version.json</filename>
-for the previous release under their <filename>dependency_data</filename> directory.
-Usually Blend's releases are tagged into the VCs, so the previous problem
-can be solved by generating the dependency json file for the previous
-release (using a previous VCs tag). This can be done by calling manually
-the <package>task_diff</package> script (see <xref linkend="statusdump"/>)
-</para>
-
-</sect2>
-
-<sect2>
- <title>Apt <filename>sources.list</filename> files in <filename>/etc/blends/</filename></title>
-<para>
-These files are used by <citerefentry><refentrytitle>blend-gen-control</refentrytitle>
- <manvolnum>1</manvolnum></citerefentry> to
-build valid <filename>debian/control</filename> files that contain only
-available packages in their dependencies. This enables building meta
-packages for <package>stable</package>, <package>testing</package>, <package>unstable</package> or
-even a completely different distribution that has valid
-<filename>sources.list</filename> entries. The file
-<filename>/etc/blends/control.list</filename> is used as default for
-<citerefentry><refentrytitle>blend-gen-control</refentrytitle>
- <manvolnum>1</manvolnum></citerefentry> and usually is a symbolic link
-(see <citerefentry><refentrytitle>ln</refentrytitle>
- <manvolnum>1</manvolnum></citerefentry>) to
-<filename>sources.list.</filename><varname>distribution</varname>. It might be
-changed using the <package>-s </package><varname>dist</varname> option of <citerefentry><refentrytitle>blend-gen-control</refentrytitle>
- <manvolnum>1</manvolnum></citerefentry>.
-</para>
-<para>
-<emphasis>TODO:</emphasis> <emphasis>Either parse the available
-<filename>/etc/apt/sources.list</filename> or use a sane <orgname>debconf</orgname>
-question to use the "nearest" mirror.</emphasis>
-</para>
-</sect2>
-
-<sect2>
- <title>Templates in <filename>/usr/share/blends/templates</filename></title>
-<para>
-The directory <filename>/usr/share/blends/templates</filename> contains templates
-that can be used to build a <varname><blend></varname><package>-config</package>,
-which uses the tools that are contained in the
-<package>blends-common</package> package, and are useful to manage
-<varname><blend></varname> user groups (see <xref linkend="userroles"/>).
-</para>
-</sect2>
-</sect1>
-
-<sect1 id="blends-common">
- <title>Package <package>blends-common</package></title>
-
-<para>
-This package creates a common registry for all Blends in
-<filename>/etc/blends</filename>. Each Blend should put the files that are used
-into a subdirectory named like the Blend of <filename>/etc/blends</filename>. The
-<package>blends-common</package> package installs a common configuration
-file <filename>/etc/blends/blends.conf</filename>, which can be used to influence the
-behaviour of the tools described below.
-</para>
-
-<sect2>
- <title><citerefentry><refentrytitle>blend-role</refentrytitle>
- <manvolnum>8</manvolnum></citerefentry></title>
-<para>
-<variablelist>
-<varlistentry>
- <term>NAME</term>
- <listitem><para>
- <package>blend-role</package> - add/remove roles in registered Debian Pure Blend
- </para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>SYNOPSIS</term>
- <listitem><para>
- <package>blend-role</package> <varname>add|del</varname> <varname>Blend</varname>
- [<varname>Role</varname>]</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>DESCRIPTION</term>
- <listitem><para>Add/remove (register/unregister) <varname>Role</varname> for the
- specified <varname>Blend</varname>. If <varname>Role</varname> is not specified, it's
- assumed to be named like <varname>Blend</varname>.</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>OPTIONS</term>
- <listitem>
- <variablelist>
- <varlistentry>
- <term><varname>Blend</varname></term>
- <listitem><para>A registered Blend in /etc/blends, for example
- one of <package>med</package>, <package>junior</package>,
- <package>edu</package> or <package>science</package></para>
- </listitem>
- </varlistentry>
- </variablelist>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>AUTHOR</term>
- <listitem><para>Andreas Tille <email>tille at debian.org</email>,
- Cosimo Alfarano <email>kalfa at debian.org</email>.</para></listitem>
-</varlistentry>
-
-</variablelist>
-
-</para>
-</sect2>
-
-<sect2 id="blend-update-menus">
- <title><citerefentry><refentrytitle>blend-update-menus</refentrytitle>
- <manvolnum>8</manvolnum></citerefentry></title>
-<para>
-<variablelist>
-
-<varlistentry>
- <term>NAME</term>
- <listitem><para>
- <package>blend-update-menus</package> - add menu of metapackage to all Blend users</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>SYNOPSIS</term>
- <listitem><para>
- <package>blend-update-menus</package> [<varname>--blend Blend</varname> | <varname>--user
- user</varname>]</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>DESCRIPTION</term>
- <listitem>
- <para>
- blend-update-menus behaves differently depending on who run the
- command:
- </para>
-
- <para>
- If it is called by a user, it adds, and keeps updated, menu
- entries for the user who runs it.
- </para>
-
- <para>
- If it is called by root, it adds and keeps updated user's menu
- entries (see menu package for users' menus) for all users who
- belong to the group of the specified Blend, or only for a specified
- user, depending on which parameter is passed to the script.
- </para>
- </listitem>
- </varlistentry>
-
-<varlistentry>
- <term>OPTIONS</term>
- <listitem>
- <variablelist>
- <varlistentry>
- <term><varname>Blend</varname></term>
- <listitem><para>one of the installed Blends, listed in /etc/blends/, for example
- (if installed: <package>med</package>, <package>junior</package>,
- <package>edu</package> or <package>science</package>.</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><varname>user</varname></term>
- <listitem><para>system user</para></listitem>
- </varlistentry>
- </variablelist>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>AUTHOR</term>
- <listitem><para>Andreas Tille <email>tille at debian.org</email>,
- Cosimo Alfarano <email>kalfa at debian.org</email>.</para></listitem>
-</varlistentry>
-
-</variablelist>
-
-</para>
-</sect2>
-
-<sect2>
- <title><citerefentry><refentrytitle>blend-user</refentrytitle>
- <manvolnum>8</manvolnum></citerefentry></title>
-<para>
-
-<variablelist>
-
-<varlistentry>
- <term>NAME</term>
- <listitem><para>
- <package>blend-user</package> - add/remove user to Role of a registered Blend</para>
-
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>SYNOPSIS</term>
- <listitem><para>
- <package>blend-user</package> <varname>add|del</varname> <varname>Blend</varname> <varname>user</varname> [<varname>Role</varname>]
- </para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>DESCRIPTION</term>
- <listitem><para>Add/remove user to a <varname>Role</varname> of the specified <varname>Blend</varname>.
-
- If <varname>Role</varname> is not specified, it's assumed to be named like
- <varname>Blend</varname></para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>OPTIONS</term>
- <listitem>
- <variablelist>
- <varlistentry>
- <term><varname>Blend</varname></term>
- <listitem><para>A registered Blend in /etc/blends, for example
- one of <package>med</package>, <package>junior</package>,
- <package>edu</package> or <package>science</package>.</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><varname>user</varname></term>
- <listitem><para>user to add</para></listitem>
- </varlistentry>
- <varlistentry>
- <term><varname>Role</varname></term>
- <listitem><para>the role in the <varname>Blend</varname> that <varname>user</varname> will
- assume</para></listitem>
- </varlistentry>
- </variablelist>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>AUTHOR</term>
- <listitem><para>Andreas Tille <email>tille at debian.org</email>,
- Cosimo Alfarano <email>kalfa at debian.org</email>.</para></listitem>
-</varlistentry>
-</variablelist>
-</para>
-</sect2>
-
-<sect2>
- <title><citerefentry><refentrytitle>blends.conf</refentrytitle>
- <manvolnum>5</manvolnum></citerefentry></title>
-<para>
-
-<variablelist>
-
-<varlistentry>
- <term>NAME</term>
- <listitem><para>
- <filename>blends.conf</filename> - configuration for Debian Pure Blends registry
- </para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>DESCRIPTION</term>
- <listitem><para>This file is sourced from shell scripts inside the Debian
- Pure Blends package <package>blends-common</package> and thus
- it has to follow shell syntax. The variables that are set
- inside this configuration file can be overriden by special
- Blend configration files
- <filename>/etc/blends/</filename><varname>Blend></varname>/<varname>Blend></varname><filename>.conf</filename>
- for each single Blend.</para></listitem>
-</varlistentry>
-
-<varlistentry>
- <term>SYNTAX</term>
- <listitem><para>The following variables can be set:</para>
- <variablelist>
- <varlistentry>
- <term><package>DBBACKEND</package></term>
- <listitem><para>Set the backend for the user role management system.
- Currently the only implemented role management system is
- <package>unixgroups</package> but others might be implemented
- later. Unsetting this variable leads to use no roles at all.</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><package>UPDATEUSERMENU</package></term>
- <listitem><para>If this is set to <package>yes</package>, the user menus of meta
- packages can be created automatically at install time of
- the package if the postinst script of the package allows
- this. It is suggested to use this option in the specific
- configuration files of a special Debian Pure Blend that
- override the settings of the general configuration file.</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><package>SHAREDIR</package></term>
- <listitem><para>Set the base directory for the user role management
- system. While this is more or less a feature for
- debugging this might be also used otherwise. </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><package>DRYRUN</package></term>
- <listitem><para>This variable can be set for debugging. Normally it
- should be left unset (<emphasis>NOT</emphasis> set to <package>false</package>
- or anything else!). If set to <package>true</package> a dry run of
- the tools is performed or <package>echo DRYRUN:</package> would
- print debugging information. </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><package>DEBUG</package></term>
- <listitem><para>If set to <package>1</package> debugging mode is switched on.</para></listitem>
- </varlistentry>
-
- </variablelist>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>SEE ALSO</term>
- <listitem><para>
- <citerefentry><refentrytitle>blend-role</refentrytitle>
- <manvolnum>8</manvolnum></citerefentry>, <citerefentry><refentrytitle>blend-update-menus</refentrytitle>
- <manvolnum>8</manvolnum></citerefentry>,
- <citerefentry><refentrytitle>blend-user</refentrytitle>
- <manvolnum>8</manvolnum></citerefentry></para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>AUTHOR</term>
- <listitem><para>Andreas Tille <email>tille at debian.org</email>,
- Cosimo Alfarano <email>kalfa at debian.org</email>.</para></listitem>
-</varlistentry>
-
-</variablelist>
-</para>
-</sect2>
-
-</sect1>
-
-
-<sect1 id="svn">
- <title>Working with the source repository (<filename>svn</filename> in process of moving to <filename>git</filename>)</title>
-<para>
- Sometimes it might be interesting for developers to check out the
- latest code of the Blend tools or a special Blend code for the meta
- packages. In <xref linkend="communication"/> the directory layout of the
- <filename>svn</filename>-directory was described. How to derive the
- Debian packages from this layout?
-<variablelist>
-
-<varlistentry>
- <term>Checkout</term>
- <listitem><para>
- For the Blend tools and this documentation
-<informalexample>
-<programlisting>
- git clone git+ssh://<varname>username</varname>@git.debian.org/git/blends/blends.git
-</programlisting>
-</informalexample>
-
- or for the Debian Pure Blend <varname>BLEND-name</varname>
-
-<informalexample>
- <programlisting>
- svn checkout svn+ssh://<varname>username</varname>@svn.debian.org/svn/blends/projects/<varname>BLEND-name</varname>/trunk
-</programlisting>
-</informalexample>
-
- Note: This will be moved to Git (at least) soon after Wheezy release.</para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Build source package</term>
- <listitem><para>
- Change into the created directory and type
-<informalexample>
- <programlisting>
- make -f debian/rules get-orig-source
-</programlisting>
-</informalexample>
-
- This creates a <filename>tar.gz</filename> source archive of the packages
- you want to build. For your personal comfort you can create a
- file <filename>Makefile</filename> in your package source directory containing
-
-<informalexample>
- <programlisting>
- #!/usr/bin/make -f
- include /usr/share/blends-dev/Makefile
-</programlisting>
-</informalexample>
-<programlisting>
- Which enables you to simply say
- </programlisting>
-<informalexample>
- <programlisting>
- make dist
- </programlisting>
-</informalexample>
-
- to create the source tarball.
- </para>
- </listitem>
-</varlistentry>
-
-<varlistentry>
- <term>Build Debian packages</term>
- <listitem><para>
- Unpack the created source tarball and proceed like you build
- Debian packages normally.</para>
- </listitem>
-</varlistentry>
-
-</variablelist>
-</para>
-<para>
-The current Debian Med packages provide a working example how to use
-the tools described below.
-</para>
-</sect1>
-
- <sect1 id="webpagecreation">
- <title>How to create tasks and bugs pages of web sentinel</title>
-
-<para>
-In <xref linkend="sentinel"/> the creation of so called tasks
-pages <xref linkend="packageslist"/> and bugs pages <xref linkend="bugs"/> was
-described. These pages are automatically build by a cron job on Alioth
-from the current state of the tasks files in the SVN repository.
-If you have commited changes to the tasks pages and want to see the
-effect immediately the steps to do are as follows:
-</para>
-<para>
-<orderedlist>
- <listitem><para>Login to <package>alioth.debian.org</package></para></listitem>
- <listitem><para><filename>cd /var/lib/gforge/chroot/home/groups/blends/webtools/</filename></para></listitem>
- <listitem><para><filename>./tasks.py <blend-name></filename></para></listitem>
-</orderedlist>
-</para>
-<para>
-To know what a valid <package><blend-name></package> might be have a look
-into
-<filename>/var/lib/gforge/chroot/home/groups/blends/webtools/webconf</filename>.
-Each Blend has an according config file there. Leave out
-the <filename>.conf</filename> extension and you have a
-valid <package><blend-name></package>.
-</para>
-<para>
-In case you are planing some more experimental changes there is
-another host which was kindly sponsored by Frédéric Hébert for Debian
-Med called <package>blends.debian.net</package> which is running a copy of
-UDD and also hosts the latest development snapshot of the Blends web
-tools. Just ask Andreas Tille <email>tille at debian.org</email> in case
-you like a login on this host.
-</para>
-<para>
-The code which builds web and tasks pages is available in Git at
-<filename>git://git.debian.org/git/blends/website.git</filename>. It is
-using the <ulink url="http://genshi.edgewall.org/">Genshi
-templating system</ulink> which enables influencing the layout of the pages
-by editing the templates in the
-<filename>templates</filename> directory.
-You can also influence some parameters of the web pages in the
-configuration files in the <filename>webconf</filename> directory.
-Last but not least you can provide translations for the web pages in
-the <filename>po</filename> directory.
-</para>
-<para>
-Once something on the web pages was changed you can activate the
-changes as follows:
-</para>
-<para>
-<orderedlist>
- <listitem><para>Login to <package>alioth.debian.org</package> or <package>blends.debian.net</package></para></listitem>
- <listitem><para><filename>cd /var/lib/gforge/chroot/home/groups/blends/webtools/</filename></para></listitem>
- <listitem><para><filename>git pull</filename></para></listitem>
-</orderedlist>
-</para>
-<para>
-Please note that the <filename>css</filename> and <filename>js</filename> files which are
-influencing the layout of the automatically created pages are in
-the same area as the static web pages (see below <xref linkend="staticwebpages"/>).
-</para>
-</sect1>
-
- <sect1 id="staticwebpages">
- <title>Editing static web pages of Blends on Alioth</title>
-<para>
-A very simple entry page is created for each Blend which is linked
-from the
-<ulink url="http://blends.alioth.debian.org/">list of all Blends</ulink>.
-Most probably the maintainers of a Blend want to enhance this page a
-bit. It is actually intended that this simple template will be
-enhanced as it is done for instance for the
-<ulink url="http://debian-med.alioth.debian.org">Debian Med
-project</ulink> which has a quite complex PHP driven web with a lot of other
-features than just linking to the tasks and bugs pages. Maintainers
-of a Blend should care for this index page which currently is just
-featuring links to the automatically updated pages as well as an image
-which shows the activity of the
-<ulink url="http://people.debian.org/~tille/talks/200808_lightning/liststats.pdf">
- relevant mailing list</ulink>. Maintaining these static pages is
-not a "service" which is done for you. The maintainers of a Blend
-should care for this!
-</para>
-<para>
-The static pages are maintained in Git at
-<filename>git://git.debian.org/git/blends/website.git</filename> in the
-<filename>websites</filename> directory.
-Once you have changed the content of the pages you can activate
-the changes by doing:
-</para>
-<para>
-<orderedlist>
- <listitem><para>Login to <package>alioth.debian.org</package> or <package>blends.debian.net</package></para></listitem>
- <listitem><para><filename>cd /var/lib/gforge/chroot/home/groups/blends/webtools/</filename></para></listitem>
- <listitem><para><filename>git pull</filename></para></listitem>
-</orderedlist>
-</para>
-</sect1>
- </appendix>
diff --git a/doc/en/B_quickintro.xml b/doc/en/B_quickintro.xml
deleted file mode 100644
index 7367b3a..0000000
--- a/doc/en/B_quickintro.xml
+++ /dev/null
@@ -1,237 +0,0 @@
- <appendix id="QuickIntro">
- <title>Quick intro into building metapackages</title>
-
-<para>
-There are several descriptions available how to build Debian packages
-in general. The main resource might be the repository of
-<ulink url="http://www.debian.org/doc/packaging-manuals/">
- Debian packaging manuals</ulink> (especially
-<ulink url="http://www.debian.org/doc/packaging-manuals/developers-reference/best-pkging-practices.html">
- developers reference chapter 6, best packaging practices</ulink>).
-There are several external packaging HOWTOs for example the one from
-<ulink url="http://www-106.ibm.com/developerworks/linux/library/l-debpkg.html">
- Joe 'Zonker' Brockmeier</ulink>.
-</para>
-
- <sect1 id="Dependencies">
- <title>Defining dependencies for metapackages</title>
-
-<para>
-This howto describes the building of metapackages by using the
-<package>blends-dev</package> package. It is perfectly possible to
-build a metapackage as any other normal Debian package but this HOWTO
-has the only purpose to describe the profit you might gain by using
-these tools.
-
- <informalexample>
- <programlisting>
-~> cp -a /usr/share/doc/blends-dev/examples/tasks .
-~> cat tasks/README
-~> edit tasks/task1
-Description: <varname>short description
- long description as in any debian/control file</varname>
-
-Depends: <varname>dependency1, dependency2, ...</varname>
-</programlisting>
- </informalexample>
-
-For each metapackage this skeleton of a <filename>debian/control</filename>
-entry is needed. All necessary information is available in the
-directory <filename>/usr/share/doc/blends-dev/examples/tasks</filename>.
-</para>
- </sect1>
-
- <sect1 id="Packaging">
- <title>The packaging directory</title>
-
-<para>
-To build any Debian package you always need a directory named
-<filename>debian</filename>, which contains a certain set of files. The
-package <package>blends-dev</package> provides a complete set of example
-files that only have to be copied and after editing some place
-holders are ready to use.
-<informalexample>
- <programlisting>
-~> cp -a /usr/share/doc/blends-dev/examples/debian .
-~> cat debian/README
-~> edit debian/control.stub
-</programlisting>
-</informalexample>
-Now the variables in the file <filename>control.stub</filename> change the
-variables named <varname>_BLEND_</varname>, <varname>_MAINTAINER_</varname> etc. to
-match the names of the Debian Pure Blend to be built. Please note
-that the file <filename>debian/control</filename> is and has to be a symbolic
-link to <filename>control.stub</filename> to let the
-<package>blends-dev</package> tools work.
-
-<informalexample>
- <programlisting>
-~> edit debian/rules
-</programlisting>
-</informalexample>
-
-Also in the <filename>debian/rules</filename> the name of the Blend has to be
-inserted where the template contains
-<varname>_BLEND_</varname>. Depending from the way the
-<filename>sources.list</filename> should be scanned the options for the
-<package>gen-control</package> call can be adjusted.
-</para>
-<para>
-You have to build the tarball using the command
-<informalexample>
- <programlisting>
-~> make -f debian/rules get-orig-source
-</programlisting>
-</informalexample>
-For your comfort you might like to create a file
-<filename>Makefile</filename> containing
-<informalexample>
- <programlisting>
-#!/usr/bin/make -f
-include /usr/share/blends-dev/Makefile
-</programlisting>
-</informalexample>
-which enables you to simply use
-<informalexample>
- <programlisting>
-~> make dist
-</programlisting>
-</informalexample>
-to build the source tarball. This tarball has to be moved to a location
-where the metapackages will be built.
-Unpack the tarball there and start the build process
-using for instance
-<informalexample>
- <programlisting>
-~> debuild
-</programlisting>
-</informalexample>
-</para>
-<para>
-That's all for the very simple case when the metapackages should not
-contain user menus. Even if user menus are suggested they are not
-necessary. The following paragraphs describe how to use the
-<package>blends-dev</package> tools to support these menus.
-</para>
-
- </sect1>
-
- <sect1 id="common-metapackage">
- <title>The common metapackage</title>
-
-<para>
-The creation of a common package is optional, but suggested, because it
-adds some special features like menus, user groups, and probably more
-in the future. It is automatically built by
-<filename>blend-install-helper</filename>, which is called in
-<filename>debian/rules</filename>, if the <filename>common</filename> directory exists.
-The easiest way to create this is as follows:
-<informalexample>
- <programlisting>
-~> cp -a /usr/share/doc/blends-dev/examples/common .
-~> cat common/README
-~> edit common/conf common/control common/common.1
-</programlisting>
-</informalexample>
-The variables (<varname>_BLEND_</varname>) in these three files have to be
-adjusted to the name of the Debian Pure Blend in question.
-This <filename><varname>blend</varname>-config</filename> cares for the initialisation
-of the role based menu system and might contain adjustments of the
-general configuration inside the <package>blends-common</package>.
-</para>
-<para>
-If the metapackage <varname>blend</varname>-<package>config</package> will be
-created according to these rules all other metapackages will depend
-automatically from this common package. For the friends of
-<package>auto-apt</package>, a helper
-<filename>/usr/bin/</filename><varname><metapackage-name></varname> will be
-installed as well, which just prints some information about the meta
-package. All in all, the usage of the common package is strongly
-suggested to have a common registry for stuff like user roles and
-possibly other things that will be implementd in the future.
-</para>
- </sect1>
- <sect1 id="metapackage-menus">
- <title>The metapackage menus</title>
-
-<para>
-As explained in <xref linkend="menu_tools"/> the metapackages can contain
-user menus. This optional feature can be implemented easily by using
-the template from the <package>blends-dev</package> in the following way:
-
-<informalexample>
- <programlisting>
-~> cp -a /usr/share/doc/blends-dev/examples/menu .
-~> cat menu/README
-~> edit menu/task1
- <varname>Edit the example to legal menu entries of the
- dependencies of this metapackage</varname>
-~> cp menu/task1 menu/<varname><metapackage name></varname>
-</programlisting>
-</informalexample>
-
-A menu file for each task should be created containing valid menu
-entries for each dependant package. The easiest way to obtain those
-menu entries is to simply copy the original menu entry files that are
-contained in the packages on which the metapackage will depend.
-The only thing that has to be changed in these menu entries is the
-<package>package</package> field, which has to be changed from
-<package><dependent package></package> to
-<varname>blend</varname>-<package>task</package>. All other entries
-might remain unchanged. This is a good point to check whether the
-menu entries of the packages you depend from are formated nicely and
-print the necessary information (for instance make use of "hints").
-Here the metapackage maintainer has a good chance for quality
-assurance work, which is also part of the Debian Pure Blends
-issue.
-</para>
-<para>
-In principle these menu items could be created automatically either at
-metapackage build time or even better in the <filename>postinst</filename>
-script of the metapackage because it is granted that the needed menu
-files are installed on the system, which is not really necessary on
-the metapackage build machine. This might be implemented in later
-versions of <package>blends-dev</package>. Currently the policy is that
-we like to have a little bit of control about the menu entries for the
-quality assurance issue mentioned above. Last, but not least, there are
-packages that do not provide a menu entry. If this is the case
-because the package maintainer just forgot it a bug report should be
-filed. On the other hand, there are packages with programs that
-provide a command line interface that does not allow a reasonable
-menu entry. A solution for this case is provided in the next
-paragraph.
-</para>
-
- </sect1>
- <sect1 id="any-dependency--menus">
- <title>Menu for any dependency</title>
-
-<para>
-The idea of the metapackage menu is to provide the user with easily
-viewable traces of any installed package that helps solving everyday
-tasks. So if there are packages that do not contain a menu, a screen
-with relevant documentation should be provided in a viewer by the
-creator of the metapackage. Such documentation can be created using
-the following templates:
-
-<informalexample>
- <programlisting>
-~> cp -a /usr/share/doc/blends-dev/examples/docs .
-~> cat docs/README
-~> edit docs/task1/dep1
- <varname>Provide information about a package <dep1> that is
- a dependency of the metapackage <task1>, but does not
- contain a useful menu entry.</varname>
-~> cp docs/task1/dep1 docs/task1/<varname><dependent pkg></varname>
-~> cp -a docs/task1 docs/<varname><metapackage name></varname>
-</programlisting>
-</informalexample>
-
-This ensures that our users become aware of all interesting packages
-on their system. The documentation files should contain hints to man
-pages to read, URLs that should be visited to learn more about the
-package or some short introduction how to get started.
-</para>
-</sect1>
- </appendix>
-
diff --git a/doc/en/C_bts.xml b/doc/en/C_bts.xml
deleted file mode 100644
index c1e4c83..0000000
--- a/doc/en/C_bts.xml
+++ /dev/null
@@ -1,54 +0,0 @@
- <appendix id="bts">
- <title>Using the Bug Tracking System</title>
-
- <sect1 id="howto_itp">
- <title>How to ask for packages which are not yet included</title>
-
-<para>
-A very frequently asked question in mailing list is, whether
-<package>program_xy</package> can be integrated into a Debian Pure Blend.
-As long as there is an official package of this program it is an easy
-task. But mostly users ask for software which is not yet integrated
-into Debian.
-</para>
-<para>
-There is a <ulink url="http://www.debian.org/devel/wnpp/#l1">
-detailed description</ulink> how anybody can ask for including a
-certain piece of software into Debian. It explains how to use the
-program <package>reportbug</package> for this purpose.
-</para>
-<para>
-In Debian Pure Blends some house keeping of interesting packages is done
-and once an ITP is issued it should be mentioned at the relevant tasks
-page to keep other team members informed. To make this happen it is a
-minimum requirement to at least foreward the ITP mail to the relevant
-mailing list crossing fingers that somebody feels responsible to enter
-this information into the according tasks file. It is even better if
-you just include the information yourself (see <xref linkend="packageslist"/>
-for more details).
-</para>
- </sect1>
-
- <sect1 id="howto_file_bugs">
- <title>How to report problems</title>
-
-<para>
-Debian has a very useful Bug Tracking System (BTS) but unfortunately
-users seldom know about this fact and how to use it right. This is
-the reason why users sometimes become angry about errors because they
-do not know what to do next and just install a different distribution
-instead of trying to solve the problem.
-</para>
-<para>
-A <ulink url="http://www.debian.org/Bugs/Reporting">detailed
-explanation how to report errors</ulink> is helpful in these cases. While
-the program <package>reportbug</package> fetches other reports from BTS
-before creating the bug report it is always a good idea to search
-<ulink url="http://bugs.debian.org">
- http://bugs.debian.org/_package_</ulink> for known problems and
-probably suggested solutions before calling <package>reportbug</package>.
-</para>
-
-</sect1>
-
-</appendix>
--
Git repository for blends-gsoc code
More information about the Blends-commit
mailing list