[Blends-commit] [SCM] blends-dev branch, master, updated. 137472b6b84d3ffa46e9aa08fb900f986e929fb6
Andreas Tille
tille at debian.org
Sun Nov 24 09:21:10 UTC 2013
The following commit has been merged in the master branch:
commit 137472b6b84d3ffa46e9aa08fb900f986e929fb6
Author: Andreas Tille <tille at debian.org>
Date: Sun Nov 24 10:20:52 2013 +0100
Use Emmanouil's XML converted docs
diff --git a/debian/blends-doc.docs b/debian/blends-doc.docs
index 37414f2..3509e59 100644
--- a/debian/blends-doc.docs
+++ b/debian/blends-doc.docs
@@ -1,2 +1,2 @@
-doc/debian-blends.en.pdf
-doc/debian-blends.en.txt
+doc/en/pdf/debian-blends.en.pdf
+doc/en/txt/debian-blends.en.txt
diff --git a/debian/blends-doc.install b/debian/blends-doc.install
index 780f7ac..bcec9aa 100644
--- a/debian/blends-doc.install
+++ b/debian/blends-doc.install
@@ -1 +1 @@
-doc/debian-blends.html/* usr/share/doc/blends-doc/html
+doc/en/html/*.html usr/share/doc/blends-doc/html
diff --git a/debian/changelog b/debian/changelog
index e621f21..f5d2074 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+blends (0.6.99) UNRELEASED; urgency=low
+
+ [ Emmanouil Kiagias ]
+ * Documentation converted to XML
+
+ [ Andreas Tille ]
+ * debian/control: Adapt Build-Depends to XML version of docs
+
+ -- Andreas Tille <tille at debian.org> Sun, 24 Nov 2013 09:11:44 +0100
+
blends (0.6.16.4) unstable; urgency=low
* devtools/blend-gen-control: Apply patch from Felipe Sateler
diff --git a/debian/control b/debian/control
index e3ef289..bd11f4e 100644
--- a/debian/control
+++ b/debian/control
@@ -6,14 +6,12 @@ Uploaders: Petter Reinholdtsen <pere at debian.org>,
Andreas Tille <tille at debian.org>,
Cosimo Alfarano <kalfa at debian.org>,
José L. Redrejo Rodríguez <jredrejo at debian.org>,
- Jonas Smedegaard <dr at jones.dk>
+ Jonas Smedegaard <dr at jones.dk>,
+ Emmanouil Kiagias <e.kiagias at gmail.com>
Build-Depends: debhelper (>= 9)
-Build-Depends-Indep: debiandoc-sgml,
- texlive-latex-base,
- texlive-latex-extra,
- texlive-latex-recommended,
- texlive-fonts-recommended,
- ghostscript
+Build-Depends-Indep: xmlto,
+ dblatex,
+ w3m
Standards-Version: 3.9.4
Vcs-Browser: http://git.debian.org/?p=blends/blends.git
Vcs-Git: git://git.debian.org/git/blends/blends.git
diff --git a/doc/Makefile b/doc/Makefile
index de5d49c..fd5669b 100644
--- a/doc/Makefile
+++ b/doc/Makefile
@@ -1,23 +1,26 @@
## ----------------------------------------------------------------------
-## Makefile : makefile for debiandoc-sgml-doc
+## Makefile : makefile for docbook-xml
## ----------------------------------------------------------------------
## ----------------------------------------------------------------------
## Document definitions
doc_lang := en
doc_name := debian-blends
-doc_sgml := $(doc_name).$(doc_lang).sgml
-doc_pdf := $(doc_name).$(doc_lang).pdf
-doc_ps := $(doc_name).$(doc_lang).ps
-doc_dvi := $(doc_name).$(doc_lang).dvi
-doc_txt := $(doc_name).$(doc_lang).txt
-doc_info := $(doc_name).$(doc_lang).info
-doc_html := $(doc_name).html
-pkg := blends-doc
+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)
-## ----------------------------------------------------------------------
-## Package definitions
-pkg_lang := en
+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
@@ -27,47 +30,71 @@ LOCALE := unset LC_ALL; unset LANG; unset LANGUAGE;
## ----------------------------------------------------------------------
# this can and will be overriden by a higher level makefile
-PUBLISHDIR := alioth.debian.org:/srv/home/groups/blends/htdocs/blends
+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 := letter
+PAPERSIZE := a4
## ----------------------------------------------------------------------
## Targets
all: html
-validate: $(doc_sgml)
- # nsgmls -ges -wall $(doc_sgml)
- nsgmls -wall -E20 -gues $^
+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
-html $(doc_html): $(doc_sgml)
- $(LOCALE) debiandoc2html -l $(doc_lang) -b $(doc_name) -c $^
- $(LN) index.$(pkg_lang).html $(doc_html)/index.html
+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
-txt $(doc_txt): $(doc_sgml)
- debiandoc2text -l $(doc_lang) $^
-ps $(doc_ps): $(doc_sgml)
- debiandoc2latexps -l $(doc_lang) -p$(PAPERSIZE) $^
+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
-pdf $(doc_pdf): $(doc_sgml)
- $(LOCALE) debiandoc2latexpdf -l $(doc_lang) -p$(PAPERSIZE) $^
- $(RMR) $(doc_name).$(doc_lang).tpt
-dvi $(doc_dvi): $(doc_sgml)
- debiandoc2latexdvi -l $(doc_lang) -p$(PAPERSIZE) $^
- $(RMR) $(doc_name).$(doc_lang).out
+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
-info $(doc_info): $(doc_sgml)
- debiandoc2info -l $(doc_lang) $^
-publish: html pdf
- rsync -azult --delete $(doc_html)/* $(PUBLISHDIR)
- [ -s debian-blends.en.pdf ] && rsync -azult $(doc_pdf) $(PUBLISHDIR)
+publish: $(doc_html_en) $(doc_pdf_en)
+ rsync -azult --delete $(doc_html_en)/*.html $(PUBLISHDIR)
+ rsync -azult $(doc_pdf_en) $(PUBLISHDIR)
clean:
- $(RMR) $(doc_html) $(doc_pdf) $(doc_txt) $(doc_ps) $(doc_dvi) $(doc_info)
- $(RMR) $(doc_name).$(doc_lang).tpt $(doc_name).$(doc_lang).out
- find . -name "*~" -exec $(RMR) \{\} \;
+ 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
diff --git a/doc/debian-blends.en.sgml b/doc/debian-blends.en.sgml
deleted file mode 100644
index 77cb39d..0000000
--- a/doc/debian-blends.en.sgml
+++ /dev/null
@@ -1,62 +0,0 @@
-<!DOCTYPE debiandoc public "-//DebianDoc//DTD DebianDoc//EN"
-[
- <!-- textual data entities -->
- <!entity titletoc system "en/00_titletoc.sgml">
- <!entity ch-introduction system "en/01_introduction.sgml">
- <!entity ch-about system "en/02_about.sgml">
- <!entity ch-general-ideas system "en/03_general_ideas.sgml">
- <!entity ch-existing-blends system "en/04_existing_blends.sgml">
- <!entity ch-inside system "en/05_inside.sgml">
- <!entity ch-technology system "en/06_technology.sgml">
- <!entity ch-starting system "en/07_starting.sgml">
- <!entity ch-websentinel system "en/08_websentinel.sgml">
- <!entity ch-todo system "en/09_todo.sgml">
- <!entity ap-devel system "en/A_devel.sgml">
- <!entity ap-quickintro system "en/B_quickintro.sgml">
- <!entity ap-bts system "en/C_bts.sgml">
-]
->
-
-<debiandoc>
-
- <book id="debiandoc-sgml">
-
- &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>
-
-</debiandoc>
-
-<!-- Keep this comment at the end of the file
-Local variables:
-mode: sgml
-sgml-omittag:nil
-sgml-shorttag:t
-sgml-namecase-general:t
-sgml-general-insert-case:lower
-sgml-minimize-attributes:nil
-sgml-always-quote-attributes:t
-sgml-indent-step:2
-sgml-indent-data:nil
-sgml-parent-document:nil
-sgml-declaration:nil
-sgml-exposed-tags:nil
-sgml-local-catalogs:nil
-sgml-local-ecat-files:nil
-End:
--->
-
diff --git a/doc/debian-blends.en.xml b/doc/debian-blends.en.xml
new file mode 100644
index 0000000..6a2733c
--- /dev/null
+++ b/doc/debian-blends.en.xml
@@ -0,0 +1,40 @@
+<?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
new file mode 100644
index 0000000..ede2348
--- /dev/null
+++ b/doc/debian-blends.xsl
@@ -0,0 +1,13 @@
+<?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.sgml b/doc/en/00_titletoc.sgml
deleted file mode 100644
index f510e60..0000000
--- a/doc/en/00_titletoc.sgml
+++ /dev/null
@@ -1,90 +0,0 @@
-<titlepag>
-
- <title>Debian Pure Blends</title>
- <!-- subtitle> Preparing Debian for special user groups </subtitle -->
-
-<author>
- <name>Andreas Tille</name>
- <email>tille at debian.org</email>
-</author>
-
-<version><date></version>
-
-<abstract>
-This paper is intended for people who are interested in the philosophy
-of Debian Pure Blends (in short "Blends" if it is used clearly in
-internal Debian context), and the technique that is used to manage
-those projects. For those who are familiar with the concept of Custom
-Debian Distributions: We just found a new name for this concept
-because the old name just not expressed what actually is done. It is
-explained in detail why Blends are not forks from Debian, but reside
-completely inside the Debian GNU/Linux distribution, and which
-advantages can be enjoyed by taking this approach. The concept of
-metapackages and user role based menus is explained. In short: This
-document describes why Debian Pure Blends are important to the
-vitality and quality of Debian.
-</abstract>
-
- <copyright>
- <copyrightsummary>
- Copyright © 2004 - 2011 Andreas Tille, Ben Armstrong
- </copyrightsummary>
-
- <p>
- 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.
- </p>
-
- <p>
- This is distributed in the hope that it will be useful, but
- <em>without any warranty</em>; without even the implied warranty
- of merchantability or fitness for a particular purpose. See the
- GNU General Public License for more details.
- </p>
-
- <p>
- A copy of the GNU General Public License is available
- on the World Wide Web at <url
- id="http://www.gnu.org/copyleft/gpl.html" name="&urlname">. You
- can also obtain it by writing to the Free Software Foundation,
- Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110, USA.
- </p>
-
- <p>
- You can find the source of this article
- <url id="http://git.debian.org/?p=blends/blends.git;a=tree;f=doc/en"
- name="in the Git repository at git.debian.org">.
- It is also available as Debian package <package>blends-doc</package>.
- </p>
-
- <p>
- A <url id="debian-blends.en.pdf"
- name="printable version in PDF format"> will be built
- from time to time.
- </p>
-
- </copyright>
-</titlepag>
-
-<toc detail="sect">
-
-
-<!-- Keep this comment at the end of the file
-Local variables:
-mode: sgml
-sgml-omittag:nil
-sgml-shorttag:t
-sgml-namecase-general:t
-sgml-general-insert-case:lower
-sgml-minimize-attributes:nil
-sgml-always-quote-attributes:t
-sgml-indent-step:2
-sgml-indent-data:t
-sgml-parent-document:("../debian-blends.en.sgml" "book" "chapt")
-sgml-exposed-tags:nil
-sgml-local-catalogs:nil
-sgml-local-ecat-files:nil
-End:
--->
diff --git a/doc/en/00_titletoc.xml b/doc/en/00_titletoc.xml
new file mode 100644
index 0000000..4022394
--- /dev/null
+++ b/doc/en/00_titletoc.xml
@@ -0,0 +1,78 @@
+<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.sgml b/doc/en/01_introduction.sgml
deleted file mode 100644
index 58e373f..0000000
--- a/doc/en/01_introduction.sgml
+++ /dev/null
@@ -1,73 +0,0 @@
-<chapt id="introduction">
- <heading>Introduction</heading>
-<p>
- 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.
-</p>
-<p>
-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.
-</p>
-<p>
-To clarify the relation between a Blend and a derivative which is
-frequently mixed up Ben Armstrong said in a
-<url id="http://lists.debian.org/debian-blends/2011/07/msg00010.html"
- name="discussion on the Blends mailing list">:
-"While a Blend strives to mainstream with Debian, a derivative
- strives to differentiate from Debian."
-</p>
-<p>
-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.
-</p>
-<p>
-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.
-</p>
-<p>
-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.
-</p>
-</chapt>
-
-<!-- Keep this comment at the end of the file
-Local variables:
-mode: sgml
-sgml-omittag:nil
-sgml-shorttag:t
-sgml-namecase-general:t
-sgml-general-insert-case:lower
-sgml-minimize-attributes:nil
-sgml-always-quote-attributes:t
-sgml-indent-step:2
-sgml-indent-data:t
-sgml-parent-document:("../debian-blends.en.sgml" "book" "chapt")
-sgml-exposed-tags:nil
-sgml-local-catalogs:nil
-sgml-local-ecat-files:nil
-End:
--->
diff --git a/doc/en/01_introduction.xml b/doc/en/01_introduction.xml
new file mode 100644
index 0000000..ea903de
--- /dev/null
+++ b/doc/en/01_introduction.xml
@@ -0,0 +1,63 @@
+<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
new file mode 100644
index 0000000..df8f57f
--- /dev/null
+++ b/doc/en/02_about.xml
@@ -0,0 +1,365 @@
+<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.sgml b/doc/en/03_general_ideas.sgml
deleted file mode 100644
index d4d222c..0000000
--- a/doc/en/03_general_ideas.sgml
+++ /dev/null
@@ -1,344 +0,0 @@
-<chapt id="general">
- <heading>General ideas</heading>
-
-
- <sect id="lookbeyond">
- <heading>Looking beyond</heading>
-
- <p>
- Commercial Linux distributors sell certain products that try to
- address special user needs.
-
- <taglist>
- <tag>Enterprise solutions</tag>
- <item>
- <list>
- <item>Corporate Server - Mandriva</item>
- <item>Advanced Server - RedHat</item>
- <item>Enterprise Server - SuSE</item>
- </list>
- </item>
- <tag>Small Office and Home Office (SOHO)</tag>
- <item>There are a couple of workstation or home editions, as well as
- office desktops built by several GNU/Linux distributors.</item>
- <tag>Special task products</tag>
- <item>
- <taglist>
- <tag>Mail server</tag>
- <item>SuSE Linux Openexchange Server</item>
- <tag>Firewall</tag>
- <item>Multi Network Firewall - Mandriva, SuSE Firewall on CD,
- ...</item>
- <tag>Cluster</tag>
- <item>Mandriva Clustering</item>
- <tag>Content Management System</tag>
- <item>RedHat</item>
- <tag>Portal Server</tag>
- <item>RedHat</item>
- </taglist>
- </item>
-</taglist>
-
-This is only a small set of examples of commercial GNU/Linux
-distributors addressing specific user interests with certain products.
-</p>
-<p>
-Debian solves this problem with <strong>Debian Pure Blends</strong>.
-</p>
-
- </sect>
-
- <sect id="motivation">
- <heading>Motivation</heading>
-
- <sect1 id="userprofile">
- <heading>Profile of target users</heading>
-
-<p>
-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.
-</p>
-<p>
-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.
-</p>
-<p>
-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.
-</p>
-<p>
-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.
-</p>
-<p>
-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.
-</p>
-<p>
-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.
-</p>
-<p>
-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.
-</p>
-<p>
-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.
-</p>
-<p>
-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.
-</p>
-</sect1>
-
- <sect1 id="adminprofile">
- <heading>Profile of target administrators</heading>
-
-<p>
-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.
-</p>
-<p>
-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.
-</p>
-<p>
-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.
-</p>
-</sect1>
-
-</sect>
-
-<sect id="status">
- <heading>Status of specialised Free Software</heading>
-
-<p>
-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.
-</p>
-<p>
-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.
-<list>
- <item>
-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.
-</item>
-<item>
-The trouble often continues in the maintenance of the installed
-software.
-</item>
-<item>
-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.
-</item>
-<item>
-Several existing programs that might be useful for specialists are not
-really free in the sense of
-the <url id="http://www.debian.org/social_contract#guidelines"
-name="Debian Free Software Guidelines (DFSG)">. 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.
-</item>
-<item>
-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; <em>i.e.</em>, not actively
-maintained anymore. If their licenses are too restrictive, it may be
-impossible for anyone else to take over; sticking to
-<comment>AT: We should find a way to avoid printing the URL in PDF output.</comment>
-<url id="http://www.debian.org/social_contract#guidelines"
-name="DFSG">-free licenses avoids that problem.
-</item>
-<item>
-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
-<url id="http://www.debian.org/Bugs/" name="Debian Bug Tracking System">.
-</item>
-<item>
-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.
-</item>
-<item>
-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.
-</item>
-<item>
-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.
-</item>
-</list>
-</p>
-</sect>
-
- <sect id="general_problem">
- <heading>General problem</heading>
-<p>
-Free Software development is a kind of evolutionary process. It needs a
-critical mass of supporters, who are:
-<list>
- <item>programmers <em>and</em></item>
- <item>users</item>
-</list>
-Because specialised software has a limited set of users, (specialists,)
-this results in a limited set of programmers.
-</p>
-<p>
-Debian wants to attract both groups to get it working.
-</p>
-<p>
-<strong>Debian is the missing link between upstream developers and users.</strong>
-</p>
-</sect>
-
- <sect id="philosophy">
- <heading>Debian Pure Blends from philosophical point of view</heading>
-<p>
-Debian currently grows in several directions:
-
-<list>
- <item>Number of involved people</item>
- <item>Number of packages</item>
- <item>Number of architectures</item>
- <item>Number of bugs</item>
- <item>Number of users</item>
- <item>Number of derivatives</item>
- <item>Time span between releases</item>
-</list>
-
-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.
-</p>
-<p>
-"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 <file>testing</file>
- distribution even in production which was not really intended and in
- a consequence even security in <file>testing</file> was implemented
- for Sarge.
-</p>
-<p>
-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.
-</p>
-</sect>
-</chapt>
-
-<!-- Keep this comment at the end of the file
-Local variables:
-mode: sgml
-sgml-omittag:nil
-sgml-shorttag:t
-sgml-namecase-general:t
-sgml-general-insert-case:lower
-sgml-minimize-attributes:nil
-sgml-always-quote-attributes:t
-sgml-indent-step:2
-sgml-indent-data:t
-sgml-parent-document:("../debian-blends.en.sgml" "book" "chapt")
-sgml-exposed-tags:nil
-sgml-local-catalogs:nil
-sgml-local-ecat-files:nil
-End:
--->
diff --git a/doc/en/03_general_ideas.xml b/doc/en/03_general_ideas.xml
new file mode 100644
index 0000000..2d278b8
--- /dev/null
+++ b/doc/en/03_general_ideas.xml
@@ -0,0 +1,270 @@
+<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
new file mode 100644
index 0000000..41c9b8a
--- /dev/null
+++ b/doc/en/04_existing_blends.xml
@@ -0,0 +1,827 @@
+<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.sgml b/doc/en/05_inside.xml
similarity index 71%
rename from doc/en/05_inside.sgml
rename to doc/en/05_inside.xml
index f4fc80c..03005f9 100644
--- a/doc/en/05_inside.sgml
+++ b/doc/en/05_inside.xml
@@ -1,39 +1,39 @@
-<chapt id="inside">
- <heading>Distributions inside Debian</heading>
+<chapter id="inside">
+ <title>Distributions inside Debian</title>
- <sect id="fork">
- <heading>To fork or not to fork</heading>
+ <sect1 id="fork">
+ <title>To fork or not to fork</title>
-<p>
+<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.
-</p>
+</para>
- <sect1 id="commercialfork">
- <heading>Commercial forks</heading>
+ <sect2 id="commercialfork">
+ <title>Commercial forks</title>
-<p>
+<para>
If Debian should be used as the base for a commercial distribution
like
- <url id="http://www.linspire.com/" name="Linspire"> (formerly Lindows),
- <url id="http://www.libranet.com/" name="Libranet"> or
- <url id="http://www.xandros.com/" name="Xandros">, there is no other
+ <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.
-</p>
- </sect1>
+</para>
+ </sect2>
- <sect1 id="noncommercialfork">
- <heading>Non-commercial forks</heading>
+ <sect2 id="noncommercialfork">
+ <title>Non-commercial forks</title>
-<p>
+<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.
@@ -45,9 +45,11 @@ 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:
-<taglist>
- <tag><url id="http://www.skolelinux.org" name="SkoleLinux"></tag>
- <item>Mentioning SkoleLinux in the category of forks is more or less
+<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
@@ -55,39 +57,57 @@ Pure Blend are:
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.
- </item>
- <tag>DeMuDi</tag>
- <item>The <url name="Agnula"
- id="http://www.agnula.org/"> project, which is founded by the
+ 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:
- <taglist>
- <tag>Technical</tag>
- <item>They had some special requirements for the kernel and
- configuration. This is more or less solved in the
- upcoming Debian release.</item>
- <tag>License</tag>
- <item>When DeMuDi started, not enough free programs in this
- field existed. This situation is better now.</item>
- <tag>Organisational</tag>
- <item>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.</item>
- </taglist>
+ 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.
- </item>
- <tag>LinEx</tag>
- <item>LinEx is the very successful distribution for schools in the
+ 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
@@ -97,11 +117,15 @@ Pure Blend are:
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.
- </item>
-</taglist>
-</p>
-<p>
+ 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
@@ -109,14 +133,14 @@ 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 <strong>flavours</strong> of a Blend.
-</p>
- </sect1>
+would be called <emphasis>flavours</emphasis> of a Blend.
+</para>
+ </sect2>
- <sect1 id="disadvantages">
- <heading>Disadvantages of separate distribution</heading>
+ <sect2 id="disadvantages">
+ <title>Disadvantages of separate distribution</title>
-<p>
+<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
@@ -125,33 +149,35 @@ 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.
-</p>
-<p>
+</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.
-</p>
-<p>
+</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 <ref id="general_problem">.
-</p>
-<p>
+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.
-</p>
-<p>
-<strong>Forking would be a bad idea.</strong>
-</p>
- </sect1>
+</para>
+<para>
+<emphasis>Forking would be a bad idea.</emphasis>
+</para>
+ </sect2>
- <sect1 id="advantages">
- <heading>Advantages of integration into Debian</heading>
+ <sect2 id="advantages">
+ <title>Advantages of integration into Debian</title>
-<p>
+<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
@@ -161,25 +187,29 @@ 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.
-</p>
-<p>
+</para>
+
+<para>
You get a secure and stable system without extra effort for free.
-</p>
-<p>
+</para>
+
+<para>
Debian offers a sophisticated Bug Tracking System for free, which is a
really important resource for development.
-</p>
-<p>
+</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.
-</p>
-</sect1>
+</para>
+
+</sect2>
- <sect1>
- <heading>Enhancing Debian</heading>
+ <sect2>
+ <title>Enhancing Debian</title>
-<p>
+<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
@@ -187,48 +217,53 @@ 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
-<ref id="howto_itp">. This section explains how you can ask for
+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.
-</p>
+</para>
+
+</sect2>
</sect1>
-</sect>
- <sect>
- <heading>Adaptation to any purpose</heading>
+ <sect1>
+ <title>Adaptation to any purpose</title>
-<p>
+<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.
-</p>
-<p>
+</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
-<url id="http://www.debian.org/doc/debian-policy/" name ="Debian's policy">,
+<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.
-</p>
-<p>
+</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.
-</p>
-<p>
+</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.
-</p>
-<p>
+</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
@@ -236,33 +271,16 @@ 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.
-</p>
-<p>
+</para>
+
+<para>
Thus, single developers have influence on development - they just have
-to <strong>do</strong> it, which is a very different position compared
+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
-"<em><strong>Do</strong>ocracy</em>" - the one who does, rules.
-</p>
- </sect>
-
-</chapt>
-
-<!-- Keep this comment at the end of the file
-Local variables:
-mode: sgml
-sgml-omittag:nil
-sgml-shorttag:t
-sgml-namecase-general:t
-sgml-general-insert-case:lower
-sgml-minimize-attributes:nil
-sgml-always-quote-attributes:t
-sgml-indent-step:2
-sgml-indent-data:t
-sgml-parent-document:("../debian-blends.en.sgml" "book" "chapt")
-sgml-exposed-tags:nil
-sgml-local-catalogs:nil
-sgml-local-ecat-files:nil
-End:
--->
+"<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.sgml b/doc/en/06_technology.xml
similarity index 52%
rename from doc/en/06_technology.sgml
rename to doc/en/06_technology.xml
index 87c37fc..41f7b65 100644
--- a/doc/en/06_technology.sgml
+++ b/doc/en/06_technology.xml
@@ -1,98 +1,127 @@
-<chapt id="technology">
- <heading>Technology</heading>
+<chapter id="technology">
+ <title>Technology</title>
- <sect id="metapackages">
- <heading>Metapackages</heading>
+ <sect1 id="metapackages">
+ <title>Metapackages</title>
- <sect1 id="defmetapackages">
- <heading>Metapackage definition</heading>
+ <sect2 id="defmetapackages">
+ <title>Metapackage definition</title>
-<p>
+<para>
A metapackage, as used by Blends, is a Debian package that contains:
-<list>
- <item>Dependencies on other Debian packages (essential)
- <taglist>
- <tag>Depends</tag>
- <item><p>Use "Depends" for packages that are definitely needed
- for all basic stuff of the Blend in question.</p>
- </item>
- <tag>Recommends</tag>
- <item>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.
- </item>
- <tag>Suggests</tag>
- <item>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.
- </item>
- </taglist>
- </item>
- <item>Menu entries (recommended)
- <list>
- <item>Place these in <file>/etc/blends/<var><blend></var>/menu/<var><pkg-name></var></file>
- <item>Maintain these via role based tools</item>
- </list>
- </item>
- <item>Configuration stuff (optional)
- <list>
- <item><prgn>debconf</prgn> questions or pre-seeding</item>
- <item><prgn>cfengine</prgn> scripts (or similar see <ref id="EnhancingTechnology">)</item>
- </list>
- </item>
- <item>Special metapackages:
- <list>
- <item><package><var><blend></var>-tasks</package>:
- Contains information for <prgn>tasksel</prgn></item>
- <item><package><var><blend></var>-config</package>:
- Special configurations, basic stuff for user menus</item>
- </list>
- </item>
-</list>
-</p>
-<p>
+
+<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
-<var><blend></var>-<var><task></var>
-where <var><blend></var> stands for the short name of a Debian
+<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 <var><task></var> means the certain task inside the Blend,
+and <varname><task></varname> means the certain task inside the Blend,
e.g. puzzle or bio.
-</p>
-<p>
+</para>
+
+<para>
+
Examples:
-<taglist>
- <tag><package>junior-puzzle</package></tag>
- <item>Debian Jr. Puzzles</item>
- <tag><package>education-tasks</package></tag>
- <item>Tasksel files for SkoleLinux systems</item>
- <tag><package>med-bio</package></tag>
- <item>Debian Med micro-biology packages</item>
-</taglist>
-</p>
+<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>
- <sect1 id="collection">
- <heading>Collection of specific software</heading>
+</sect2>
+ <sect2 id="collection">
+ <title>Collection of specific software</title>
-<p>
+<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.
-</p>
-<p>
+</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.
-</p>
+</para>
<!-- This is not true any more since we turn Depends into Recommends
to explicitely *enable* users to remove certain packages.
@@ -102,46 +131,49 @@ explicit notice that also the metapackage has to be removed. This
helps non specialist administrators to keep the installation fit for
the specialized users.
-->
-<p>
+<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.
-</p>
-<p>
+</para>
+<para>
All in all, metapackages enable an easy installation from scratch, and
keep the effort required for administration low.
-</p>
-
- <sect1 id="categorisation">
- <heading>Packages showing up in more than one metapackage</heading>
-
-<p>
-This seems to be an FAQ: If a package <tt>A</tt> is in the list of
-dependencies of metapackage <tt>m</tt> is it allowed or reasonable to
-add it to the list of dependencies of metapackage <tt>n</tt>?
-</p>
-<p>
+</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?
-</p>
-<p>
+</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 <tt>x</tt> depends from package
-<tt>libc</tt> no other package is allowed to add <tt>libc</tt> to its
+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?
-</p>
-<p>
+</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
-<strong>not</strong> build a categorisation tree but build pools of useful
+<emphasis>not</emphasis> build a categorisation tree but build pools of useful
software for certain tasks which can definitely have overlaps.
-</p>
-<p>
+</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
@@ -151,22 +183,22 @@ 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.
-</p>
+</para>
- </sect1>
+ </sect2>
- <sect1 id="configuration">
- <heading>Adapted configuration inside metapackages</heading>
+ <sect2 id="configuration">
+ <title>Adapted configuration inside metapackages</title>
-<p>
+<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 <prgn>debconf</prgn> questions, or by
-modifying configuration files in a <prgn>postinst</prgn> script. It
+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
-<prgn>postinst</prgn> script takes over the role of a local
+<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
@@ -174,14 +206,14 @@ administrator.
scripts from debconf. Look at debconf-set-selections and
debconf-get-selections.
-->
-</p>
+</para>
- </sect1>
+ </sect2>
- <sect1 id="documentation">
- <heading>Documentation packages</heading>
+ <sect2 id="documentation">
+ <title>Documentation packages</title>
-<p>
+<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
@@ -190,24 +222,24 @@ 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.
-</p>
-<p>
+</para>
+<para>
Thus, translation is a very important thing to make programs more
useful for the target user group. Debian has established
-a <url id="http://ddtp.debian.net/" name="Debian Description
-Translation Project">, which has the goal to translate package
+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.
-</p>
+</para>
+ </sect2>
</sect1>
- </sect>
- <sect id="mp_handling">
- <heading>Handling of metapackages</heading>
+ <sect1 id="mp_handling">
+ <title>Handling of metapackages</title>
-<p>
+<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.
@@ -220,20 +252,23 @@ Debian Pure Blends.
-->
In short, there are no special tools available to handle metapackages
nicely. But there are some tricks that might help, for the moment.
-</p>
+</para>
- <sect1 id="cmdline">
- <heading>Command line tools</heading>
+ <sect2 id="cmdline">
+ <title>Command line tools</title>
-<p>
-<taglist>
- <tag><prgn>apt-cache</prgn></tag>
- <item>
- The program <prgn>apt-cache</prgn> is useful to search for
+<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
- "<tt>med</tt>") and combine it reasonably with <prgn>grep</prgn>:
- <example>
+ "<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
@@ -243,16 +278,24 @@ 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
- </example>
- This is <strong>not really straightforward</strong>, and
+</programlisting>
+ </informalexample>
+ <para>
+ This is <emphasis>not really straightforward</emphasis>, and
absolutely unacceptable for end users.
- </item>
- <tag><prgn>grep-dctrl</prgn></tag>
- <item>
- The program <prgn>grep-dctrl</prgn> is a grep for Debian package
+ </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:
- <example>
+ matching certain patterns:</para>
+ <informalexample>
+ <programlisting>
~> grep-dctrl ': med-' /var/lib/dpkg/available | \
grep -v '^[SIMAVF]' | \
grep -v '^Pri'
@@ -287,20 +330,27 @@ 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 ...
- </example>
- This is, like the <prgn>apt-cache</prgn> example, <strong>also
- a bit cryptic</strong>, and again is not acceptable for end users.
- </item>
- <tag><prgn>auto-apt</prgn></tag>
- <item>
- The program <prgn>auto-apt</prgn> is really cool if you are
+</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
- <prgn>auto-apt</prgn> in the following manner to guarantee that you
- have all of the files or programs you need:
- <example>
+ <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
@@ -339,151 +389,190 @@ 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
- </example>
- Just do your normal business - in the above example, <tt>less
- /usr/share/doc/med-bio/copyright</tt> - and if the necessary
- package is not yet installed, <prgn>auto-apt</prgn> will care for
- the installation and proceed with your command. While this is
- really cool, this is <strong>not really intended for a production
- machine</strong>.
- </item>
-</taglist>
-
-The short conclusion here is: <strong>There are no sophisticated tools
+</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.</strong>
-</p>
+Debian.</emphasis>
+</para>
- </sect1>
+ </sect2>
+
+ <sect2 id="text_ui">
+ <title>Text user interfaces</title>
+<para>
- <sect1 id="text_ui">
- <heading>Text user interfaces</heading>
-<p>
-<taglist>
- <tag><prgn>tasksel</prgn></tag>
- <item>
- <p>
- The Debian task installer <prgn>Tasksel</prgn> is the first
+<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 <tt>End-user</tt> section should
+ 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 <prgn>tasksel</prgn> list,
+ 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 <url id="http://bugs.debian.org/186085"
- name="#186085">.) In principle, <prgn>tasksel</prgn> is a good
+ 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.
- </p>
- <p>
- As a workaround for this problem the <prgn>blends-dev</prgn>
- framework creates a package <tt>BLEND-tasks</tt> which contains
- a <prgn>tasksel</prgn> control file. If you install this package
+ </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 <prgn>tasksel</prgn>. So a solution for Blend specific
+ 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.
- </p>
- </item>
- <tag><prgn>aptitude</prgn></tag>
- <item>
- This is a better replacement for <prgn>dselect</prgn>, and has
+ </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.
- </item>
-</taglist>
-Short conclusion: <strong>There is a good chance metapackages could be
+ 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.</strong>
-</p>
+but this is not yet implemented.</emphasis>
+</para>
- </sect1>
+ </sect2>
- <sect1 id="gui">
- <heading>Graphical user interfaces</heading>
-<p>
-Debian <em>Woody</em> does not contain a really nice graphical
+ <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.
-<taglist>
- <tag><prgn>gnome-apt</prgn></tag>
- <item>This is the native GNOME flavour of graphical user interfaces
- to apt. It has a nice <tt>Search</tt> feature that can be
- found in the <tt>Package</tt> menu section. If for instance
+
+<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 "<tt>junior-*</tt>" will show
+ 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.
- </item>
- <tag><prgn>synaptic</prgn></tag>
- <item>Even more sophisticated and perhaps the best choice for users
- of Debian Pure Blends. <prgn>Synaptic</prgn> has a nice
+ 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 <prgn>synaptic</prgn> is currently the only user
+ Moreover <package>synaptic</package> is currently the only user
interface that supports Debian Package Tags
- (see <ref id="debtags">).
- </item>
- <tag><prgn>kpackage</prgn></tag>
- <item>This is the user interface of choice for KDE lovers.
+ (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.
- </item>
-</taglist>
-Short conclusion: <strong>As well as the text based user interfaces
+ 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.</strong>
-</p>
- </sect1>
+powerful tools for Debian Pure Blends.</emphasis>
+</para>
+ </sect2>
- <sect1 id="web_if">
- <heading>Web interfaces</heading>
+ <sect2 id="web_if">
+ <title>Web interfaces</title>
+
+<para>
+
+<variablelist>
-<p>
-<taglist>
- <tag>Tasks pages</tag>
- <item><p>The tasks pages probably provide the best overview about
+<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 <ref id="debian_control">) and verifying the existence
+ (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 <prgn>gettext</prgn> which
+ 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
- <url id="http://ddtp.debian.net/" name="Debian Description
- Translation Project" >.
- </p>
- <p>These tasks pages are available via
- <example>
+ <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
- </example>
- where <tt>BLEND</tt> has to be replaced by the name of the
+ </programlisting>
+ </informalexample>
+ where <package>BLEND</package> has to be replaced by the name of the
Blend. Currently these pages are available for the Blends:
- <example>
+ <informalexample>
+ <programlisting>
accessibility, edu, gis, junior, lex, science, debichem
- </example>
+ </programlisting>
+ </informalexample>
The tasks pages are available for Debian Med as well but for
historical reasons the URL for these pages is
- <example>
+ <informalexample>
+ <programlisting>
http://debian-med.alioth.debian.org/tasks
- </example>
+ </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.
- </p>
- </item>
- <tag>Bugs pages</tag>
- <item><p>The more developer oriented bugs pages try to match the
+ </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
@@ -492,42 +581,55 @@ powerful tools for Debian Pure Blends.</strong>
Blend: Fixing bugs is always welcome and listing all relevant
bugs at a single place is a nice way to detect problems
quickly.
- </p>
- <p>These bugs pages are available via
- <example>
+ </para>
+ <para>These bugs pages are available via
+ <informalexample>
+ <programlisting>
http://blends.alioth.debian.org/BLEND/bugs
- </example>
- where <tt>BLEND</tt> has to be replaced by the name of the
+ </programlisting>
+ </informalexample>
+ where <package>BLEND</package> has to be replaced by the name of the
Blend. Currently these pages are available for the Blends:
- <example>
+ <informalexample>
+ <programlisting>
accessibility, edu, gis, junior, lex, science, debichem
- </example>
+ </programlisting>
+ </informalexample>
The bugs pages are available for Debian Med as well but for
historical reasons the URL for these pages is
- <example>
+ <informalexample>
+ <programlisting>
http://debian-med.alioth.debian.org/bugs
- </example>
+ </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.
- </p>
- </item>
- <tag><url id="http://packages.debian.org/" name="Web search"></tag>
- <item><p>Debian has a web interface that can be used to search for certain substrings
+ </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</p>
- <p>
-<comment>FIXME: & is sometimes broken!!!
-<url id="http://packages.debian.org/cgi-bin/search_packages.pl?keywords=med-&subword=1">
+ to</para>
+ <para>
+<remark>FIXME: & is sometimes broken!!!
+<ulink url="http://packages.debian.org/cgi-bin/search_packages.pl?keywords=med-&subword=1"/>
^^^^^
-</comment>
-<url id="http://packages.debian.org/cgi-bin/search_packages.pl?keywords=med-&subword=1">
- </p><p>
- As a result you will get a list of all Debian Med packages.
- </item>
- <tag><url id="http://qa.debian.org/developer.php" name="Package Tracking System"></tag>
- <item><p>
+</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
@@ -535,110 +637,144 @@ powerful tools for Debian Pure Blends.</strong>
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:
- <taglist>
- <tag>Debian Jr:</tag>
- <item>
- <url id="http://qa.debian.org/developer.php?login=debian-jr@lists.debian.org">
- </item>
- <tag>Debian Med:</tag>
- <item>
- <url id="http://qa.debian.org/developer.php?login=debian-med-packaging@lists.alioth.debian.org">
- </item>
- <tag>Debian Edu:</tag>
- <item>
- <url id="http://qa.debian.org/developer.php?login=debian-edu@lists.debian.org">
- </item>
- <tag>Debian Science:</tag>
- <item>
- <url id="http://qa.debian.org/developer.php?login=debian-science-maintainers@lists.alioth.debian.org">
- </item>
- </taglist>
- Hint: If you append the option <prgn>&ordering=3</prgn> you
+ </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.
- </p>
- <p>
+ </para>
+ <para>
The other way to use the Package Tracking System is to search
for packages starting with a certain letter:
- <taglist>
- <tag>Debian Jr:</tag>
- <item>
- <url id="http://packages.qa.debian.org/j">
- </item>
- <tag>Debian Med:</tag>
- <item>
- <url id="http://packages.qa.debian.org/m">
- </item>
- </taglist>
+ <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.
- </p><p>
- </p>
- <tag><prgn>list-junior.sh</prgn></tag>
- <item>The package <package>junior-doc</package> contains a script
- <file>/usr/share/doc/junior-doc/examples/scripts/list-junior.sh</file>
+ </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.)
- </item>
-</taglist>
-Short conclusion: <strong>The Debian Pure Blends provide some nice web
+ 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..</strong>
-</p>
- </sect1>
+ basically dealing with single packages..</emphasis>
+</para>
+ </sect2>
- <sect1 id="future_handling">
- <heading>Future handling of metapackages</heading>
+ <sect2 id="future_handling">
+ <title>Future handling of metapackages</title>
-<p>
+<para>
Obviously there are no nifty tools as you might know them from Debian
-available yet. The user interfaces for <prgn>apt-get</prgn> have to be
+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:
-<list>
- <item>Searching for existing metapackages</item>
- <item>Overview about dependencies of these metapackages</item>
- <item>Enhancing tools like <prgn>aptitude</prgn>,
- <prgn>synaptic</prgn>, etc.</item>
- <item>Special <prgn>tasksel</prgn> section</item>
- <item>Web tools that keep metapackage information up to
- date</item>
-</list>
-</p>
-<p>
+<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.
-</p>
-<p>
+</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.
-</p>
+</para>
+ </sect2>
</sect1>
- </sect>
- <sect id="userroles">
- <heading>User roles</heading>
+ <sect1 id="userroles">
+ <title>User roles</title>
-<p>
+<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.
-</p>
-<p>
+</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
@@ -647,10 +783,11 @@ 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 <file>/etc/group</file> file in the appropriate group and gets a
+the <filename>/etc/group</filename> file in the appropriate group and gets a
special user menu that is provided for exactly this group.
-</p>
-<p>
+</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
@@ -659,79 +796,86 @@ 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
-<em>practical</em> limit to the number of groups to which a user may
+<emphasis>practical</emphasis> limit to the number of groups to which a user may
belong for the existing Debian Pure Blends at this time.
-</p>
-<p>
+</para>
+<para>
In the long run, this role system might even be enhanced to certain
-"<em>levels</em>" a user can have and here the UNIX groups approach
+"<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.
-</p>
-<p>
+</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.
-</p>
-<p>
+</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.
-</p>
+</para>
- <sect1 id="menu_tools">
- <heading>User menu tools</heading>
+ <sect2 id="menu_tools">
+ <title>User menu tools</title>
- <sect2 id="user-menus">
- <heading>Using the Debian menu system</heading>
-<p>
+ <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 <em>role</em> based menu
+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 <manref name="blend-update-menus" section="8"> (see
-<ref id="blend-update-menus">) script from
+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
-<prgn>blend-update-menus</prgn> is not enough to change the menu of a
+<orgname>blend-update-menus</orgname> is not enough to change the menu of a
user. To accomplish this a call of the general
-<prgn>update-menu</prgn> script for every single user of a Blend is
+<orgname>update-menu</orgname> script for every single user of a Blend is
necessary if this is not done by the
-<file>postinst</file> script of a metapackage. This can easily been
+<filename>postinst</filename> script of a metapackage. This can easily been
done if the configuration file of a Debian Pure Blend
-<file>/etc/blends/<var><blend></var>/<var><blend></var>.conf</file> contains the
+<filename>/etc/blends/</filename><varname><blend></varname>/<varname><blend></varname><filename>.conf</filename> contains the
line
-<example>
+<informalexample>
+<programlisting>
UPDATEUSERMENU=yes
-</example>
+ </programlisting>
+</informalexample>
-</p>
-<p>
+</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
-<file>menu</file> directory with the menu entries. Note, that the users
-<file>${HOME}/.menu</file> directory remains untouched.
-</p>
- </sect2>
+<filename>menu</filename> directory with the menu entries. Note, that the users
+<filename>${HOME}/.menu</filename> directory remains untouched.
+</para>
+ </sect3>
- <sect2 id="user-debconf">
- <heading>Managing Debian Pure Blend users with <prgn>debconf</prgn></heading>
+ <sect3 id="user-debconf">
+ <title>Managing Debian Pure Blend users with <orgname>debconf</orgname></title>
-<p>
+<para>
Using <package>blends-dev</package> it is very easy to build a
-<var>blend</var><package>-config</package> package that contains
-<prgn>debconf</prgn> scripts to configure system users who should
-belong to the group of users of the Debian Pure Blend <var>blend</var>.
+<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.
- <example>
+ <informalexample>
+ <programlisting>
~> dpkg-reconfigure med-common
Configuring med-common
@@ -749,102 +893,94 @@ should get a Debian Med user menu.
(Enter the items you want to select, separated by spaces.)
:-! Please specify the Debian Med users! 2 8
- </example>
+</programlisting>
+ </informalexample>
This example shows the situation when you
-<prgn>dpkg-reconfigure</prgn> <package>med-common</package> if
-<var>med user B</var> and <var>med user H</var> were defined as users
-of Debian Med previously and <var>med user F</var> should be added to
+<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 <url id="http://bugs.debian.org/140684" name="does not yet
- support screen shots">.)
-</p>
- </sect2>
- </sect1>
- </sect>
+SGML DTD <ulink url="http://bugs.debian.org/140684">does not yet
+ support screen shots</ulink>.)
+</para>
+ </sect3>
+ </sect2>
+ </sect1>
- <sect id="devtools">
- <heading>Development tools</heading>
+ <sect1 id="devtools">
+ <title>Development tools</title>
-<p>
+<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
-<taglist>
- <tag><package>blends-dev</package></tag>
- <item><p>Helpful tools to build metapackages from a set of template
+<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.</p>
- <p>This package is described in detail in appendix <ref
- id="blends-dev">.</p>
- </item>
- <tag><package>blends-common</package></tag>
- <item><p>This package provides some files that are common to meta
+ 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 <ref id="userroles">.</p>
- <p>This package is described in detail in appendix <ref
- id="blends-common">.</p>
- </item>
-</taglist>
+ 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.
-</p>
+</para>
- <sect id="othertools">
- <heading>Other interesting tools</heading>
+</sect1>
+ <sect1 id="othertools">
+ <title>Other interesting tools</title>
- <sect1 id="simple-cdd">
- <heading>Simple-CDD</heading>
+ <sect2 id="simple-cdd">
+ <title>Simple-CDD</title>
-<p>
-The tool <prgn>simple-cdd</prgn> is a limited though relatively easy
+<para>
+The tool <package>simple-cdd</package> is a limited though relatively easy
tool to create a customized debian-installer CD.
-</p><p>
+</para><para>
It includes simple mechanisms to create "profiles" that define common
system configurations, which can be selected during system
-installation. <prgn>Simple-cdd</prgn> also makes it easy to build CDs
+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.
-</p><p>
+</para><para>
This can be used to create a crude "Debian Pure Blend" using
packages from Debian, with pre-configuration of packages that use
-<prgn>debconf</prgn>. Custom configuration scripts can be specified
-to handle packages that don't support <prgn>debconf</prgn>
+<orgname>debconf</orgname>. Custom configuration scripts can be specified
+to handle packages that don't support <orgname>debconf</orgname>
pre-configuration.
-</p><p>
-Testing CD images with <prgn>qemu</prgn> is also made simple with a
+</para><para>
+Testing CD images with <package>qemu</package> is also made simple with a
provided script.
-</p><p>
-It has only been tested with <prgn>debian-cd</prgn> from Etch (other
-than <prgn>debpartial-mirror</prgn>), so if using a new
-<prgn>debian-cd</prgn> or <prgn>debian-installer</prgn>, it may
+</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.
-</p>
+</para>
+ </sect2>
</sect1>
- </sect>
-</chapt>
-
-
-<!-- Keep this comment at the end of the file
-Local variables:
-mode: sgml
-sgml-omittag:nil
-sgml-shorttag:t
-sgml-namecase-general:t
-sgml-general-insert-case:lower
-sgml-minimize-attributes:nil
-sgml-always-quote-attributes:t
-sgml-indent-step:2
-sgml-indent-data:t
-sgml-parent-document:("../debian-blends.en.sgml" "book" "chapt")
-sgml-exposed-tags:nil
-sgml-local-catalogs:nil
-sgml-local-ecat-files:nil
-End:
--->
+
+</chapter>
diff --git a/doc/en/07_starting.sgml b/doc/en/07_starting.xml
similarity index 78%
rename from doc/en/07_starting.sgml
rename to doc/en/07_starting.xml
index a83205b..32c8cac 100644
--- a/doc/en/07_starting.sgml
+++ b/doc/en/07_starting.xml
@@ -1,71 +1,71 @@
-<chapt id="starting">
- <heading>How to start a Debian Pure Blend</heading>
+<chapter id="starting">
+ <title>How to start a Debian Pure Blend</title>
-<p>
+<para>
This chapter is based on the Debian Subproject HOWTO, which was
written by Ben Armstrong <email>synrg at debian.org</email>.
-</p>
+</para>
- <sect id="planning">
- <heading>Planning to form a Debian Pure Blend</heading>
+ <sect1 id="planning">
+ <title>Planning to form a Debian Pure Blend</title>
- <p>
+ <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.
- </p>
+ </para>
- <sect1 id="leadership">
- <heading>Leadership</heading>
- <p>
+ <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:
- <em>"Am I the right person for the job?"</em> Surely this is a
+ <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 <em>job</em> of leader, considering the
+ 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.
- </p>
- </sect1>
+ </para>
+ </sect2>
- <sect1 id="defining_scope">
- <heading>Defining the scope of the Blend</heading>
- <p>
+ <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.
- </p>
- <p>
+ </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.
- </p>
- <p>
+ </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.
- </p>
- <p>
+ </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.
- </p>
- </sect1>
+ </para>
+ </sect2>
- <sect1 id="initial_discussion">
- <heading>Initial discussion</heading>
- <p>
+ <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
@@ -73,28 +73,28 @@ written by Ben Armstrong <email>synrg at debian.org</email>.
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.
- </p>
+ </para>
- <sect2 id="calling_all_developers">
- <heading>Calling all developers</heading>
- <p>
+ <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 <tt>Reply-to:
- </tt><email>debian-devel at lists.debian.org</email> and listen to what
+ 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.
- </p>
- </sect2>
+ </para>
+ </sect3>
- <sect2 id="steering_the_discussion">
- <heading>Steering the discussion</heading>
- <p>
+ <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
@@ -102,35 +102,34 @@ written by Ben Armstrong <email>synrg at debian.org</email>.
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.
- </p>
- <p>
+ </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.
- </p>
- </sect2>
+ </para>
+ </sect3>
- </sect1>
+ </sect2>
-</sect>
+</sect1>
-<sect id="setting_up">
- <heading>Setting up</heading>
+<sect1 id="setting_up">
+ <title>Setting up</title>
-<sect1>
- <heading>Mailing list</heading>
- <p>
+<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.
- </p>
- <p>
+ </para>
+ <para>
Creating a new mailing list starts with a wishlist bug against
- <package><var>lists.debian.org</var></package>. The format of this
+ <package>lists.debian.org</package>. The format of this
bug has to follow
- <url id="http://www.debian.org/MailingLists/HOWTO_start_list"
- name="certain rules">.
- </p>
- <p>
+ <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
@@ -139,49 +138,49 @@ written by Ben Armstrong <email>synrg at debian.org</email>.
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
- <url id="http://bugs.debian.org/237017" name="#237017">.
- </p>
- <p>
+ <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.
- </p>
-</sect1>
+ </para>
+</sect2>
-<sect1>
- <heading>Web space</heading>
- <p>
+<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 <url name="Wiki" id="http://wiki.debian.org">.
+ put a page on the <ulink url="http://wiki.debian.org">Wiki</ulink>.
There is a
- special <url id="http://wiki.debian.org/index.cgi?DebianPureBlends"
- name="Wiki page for Debian Pure Blends">.
- </p>
- <p>
+ 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: <url id="http://blends.alioth.debian.org">. There is a
+ 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 <ref id="web_if">. Following this
+ 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.
- </p>
- <p>
+ </para>
+ <para>
Sooner or later a Debian Pure Blend will establish an own project at
- <url id="http://alioth.debian.org" name="alioth.debian.org">, since
+ <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.
- </p>
- <p>
+ </para>
+ <para>
Finally, the best way is to have a page
- under <url id="http://www.debian.org/devel">. While not as
+ 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
@@ -192,31 +191,30 @@ written by Ben Armstrong <email>synrg at debian.org</email>.
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 <url id="http://www.debian.org/devel/website" name="learn
- more about building Debian web pages">.
- </p>
- <p>
+ 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 <url id="http://www.debian.org/intro/organization"
- name="organisation page">.
- </p>
-</sect1>
+ project to the <ulink url="http://www.debian.org/intro/organization">organisation page</ulink>.
+ </para>
+</sect2>
-<sect1>
- <heading>Repository</heading>
- <p>
- On <url id="http://alioth.debian.org/" name="alioth.debian.org"> a
- <url id="http://gforge.org/" name="Gforge">-site is running to host
+<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.
- </p>
-</sect1>
+ </para>
+</sect2>
-<sect1>
- <heading>Formal announcement</heading>
- <p>
+<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
@@ -228,8 +226,8 @@ written by Ben Armstrong <email>synrg at debian.org</email>.
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.
- </p>
- <p>
+ </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
@@ -238,26 +236,26 @@ written by Ben Armstrong <email>synrg at debian.org</email>.
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.
- </p>
-</sect1>
+ </para>
+</sect2>
-<sect1>
- <heading>Explaining the project</heading>
- <p>
+<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.
- </p>
+ </para>
+</sect2>
</sect1>
-</sect>
-<sect id="structure">
- <heading>Project structure</heading>
+<sect1 id="structure">
+ <title>Project structure</title>
-<sect1 id="subsetting_debian">
- <heading>Sub-setting Debian</heading>
- <p>
+<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
@@ -265,8 +263,8 @@ written by Ben Armstrong <email>synrg at debian.org</email>.
project aims to identify, expand, integrate, enhance, and maintain a
collection of packages suitable for a particular purpose by a
particular kind of user.
- </p>
- <p>
+ </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
@@ -274,22 +272,22 @@ written by Ben Armstrong <email>synrg at debian.org</email>.
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.
- </p>
- <p>
+ </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.
- <comment>BA: I had a bit of trouble deciding how to punctuate the following
+ <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.</comment>
+ 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?"
- </p>
- <p>
+ </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
@@ -297,8 +295,8 @@ written by Ben Armstrong <email>synrg at debian.org</email>.
making the project ineffective. Choose too narrow a focus and the
project ends up being marginal, lacking the critical mass necessary
to sustain itself.
- </p>
- <p>
+ </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
@@ -307,8 +305,8 @@ written by Ben Armstrong <email>synrg at debian.org</email>.
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.
- </p>
- <p>
+ </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
@@ -317,33 +315,33 @@ written by Ben Armstrong <email>synrg at debian.org</email>.
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.
- </p>
-</sect1>
+ </para>
+</sect2>
-<sect1 id="tasksel">
- <heading>Using tasksel and metapackages</heading>
-<p>
- According to the plan of the project, the first metapackages (<ref
- id="metapackages">) should be developed. It is not always easy to
+<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.
-</p>
-<p>
- Section <ref id="text_ui"> mentions <prgn>tasksel</prgn> as a tool
+</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.
-</p>
- </sect1>
+</para>
+ </sect2>
-</sect>
+</sect1>
-<sect id="first_release">
- <heading>First release</heading>
+<sect1 id="first_release">
+ <title>First release</title>
-<sect1 id="release_announcement">
- <heading>Release announcement</heading>
- <p>
+<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
@@ -352,21 +350,21 @@ written by Ben Armstrong <email>synrg at debian.org</email>.
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.
- </p>
-</sect1>
+ </para>
+</sect2>
-<sect1 id="users">
- <heading>Users of a Debian Pure Blend</heading>
- <p>
+<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.
- </p>
+ </para>
-<sect2 id="user_support">
- <heading>Devoting resources to the users</heading>
- <p>
+<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
@@ -377,12 +375,12 @@ written by Ben Armstrong <email>synrg at debian.org</email>.
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.
- </p>
-</sect2>
+ </para>
+</sect3>
-<sect2 id="devel_vs_user_list">
- <heading>Developer vs. user mailing list</heading>
- <p>
+<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
@@ -394,40 +392,22 @@ written by Ben Armstrong <email>synrg at debian.org</email>.
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.
- </p>
-</sect2>
+ </para>
+</sect3>
-<sect2 id="user_support_beyond_debian">
- <heading>User support beyond Debian</heading>
- <p>
+<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.
- </p>
+ </para>
+</sect3>
+
</sect2>
</sect1>
-</sect>
-
-</chapt>
-
-<!-- Keep this comment at the end of the file
-Local variables:
-mode: sgml
-sgml-omittag:nil
-sgml-shorttag:t
-sgml-namecase-general:t
-sgml-general-insert-case:lower
-sgml-minimize-attributes:nil
-sgml-always-quote-attributes:t
-sgml-indent-step:2
-sgml-indent-data:t
-sgml-parent-document:("../debian-blends.en.sgml" "book" "chapt")
-sgml-exposed-tags:nil
-sgml-local-catalogs:nil
-sgml-local-ecat-files:nil
-End:
--->
+</chapter>
diff --git a/doc/en/08_websentinel.sgml b/doc/en/08_websentinel.xml
similarity index 50%
rename from doc/en/08_websentinel.sgml
rename to doc/en/08_websentinel.xml
index 8b015be..0648a3a 100644
--- a/doc/en/08_websentinel.sgml
+++ b/doc/en/08_websentinel.xml
@@ -1,19 +1,19 @@
-<chapt id="sentinel">
- <heading>The web sentinel</heading>
+<chapter id="sentinel">
+ <title>The web sentinel</title>
- <sect id="packageslist">
- <heading>Existing and prospective packages</heading>
+ <sect1 id="packageslist">
+ <title>Existing and prospective packages</title>
-<p>
+<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
-<url id="http://blends.alioth.debian.org/" name="list of all Blends">
+<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.
-</p>
-<p>
+</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
@@ -22,59 +22,73 @@ 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:
- <list>
- <item>Read dependency information of the <file>tasks</file> files.</item>
- <item>Verify whether there is really a package with this name and
- print the description of this package.</item>
- <item>If there is no such package in Debian try to parse
- the <file>tasks</file> file whether there is some information
+ <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.</item>
- </list>
-</p>
-<p>
+ 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.
-</p>
-
- <sect id="edittasksfiles">
- <heading>Tasks files controling web sentinel content</heading>
+</para>
+</sect1>
+ <sect1 id="edittasksfiles">
+ <title>Tasks files controling web sentinel content</title>
-<p>
+<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 SVN of the sources of the Blends
+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 SVN at
-<example>
- svn://svn.debian.org/svn/blends/projects/BLEND/trunk/SRCPKG/tasks
-</example>
+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.
-</p>
-<p>
+</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:
-<taglist>
- <tag>Depends / Recommends / Suggests</tag>
- <item>Even if there is no Debian package available for the moment
+<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.
- </item>
- <tag>Ignore</tag>
- <item>The Ignore key should be the favourite way to use for
+ 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
@@ -82,188 +96,266 @@ Debian control files do and is kept quite simple:
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.
- </item>
- <tag>Homepage</tag>
- <item>This is the URL to the software that should be packaged.
- </item>
- <tag>WNPP</tag>
- <item>In case there might be a WNPP bug filed for this software 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.
- </item>
- <tag>Responsible</tag>
- <item>In case some developer claimed to care for the software
+ 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.
- </item>
- <tag>License</tag>
- <item>Debian cares always about the license. This information
- about prospective packages should be easily available.
- </item>
- <tag>Vcs-Svn</tag>
- <item><p>If there is some Debian packaging stuff available this
+ 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.
- </p><p>
+ </para><para>
The usage for this field is the same as it is described in
- <url id="http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-vcs"
- name="paragraph 6.2.5 of Debian developers reference">
- </p>
- </item>
- <tag>Vcs-Git</tag>
- <item><p>If there is some Debian packaging stuff available this
+ <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.
- </p><p>
+ </para><para>
The usage for this field is the same as it is described in
- <url id="http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-vcs"
- name="paragraph 6.2.5 of Debian developers reference">
- </p>
- </item>
- <tag>Vcs-Browser</tag>
- <item><p>If there is some Debian packaging stuff available this
+ <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 <file>Vcs-Svn</file> or <file>Vcs-Git</file>
- there is no need to set <file>Vcs-Browser</file> explicitely
+ 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.
- </p><p>
+ </para><para>
The usage for this field is the same as it is described in
- <url id="http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-vcs"
- name="paragraph 6.2.5 of Debian developers reference">
- </p>
- </item>
- <tag>Pkg-URL</tag>
- <item>In some cases there are unofficial packages for some software
+ <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 <url id="http://mentors.debian.net/"
- name="mentors.debian.net"> and prepared by people who do not
+ 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.
- </item>
- <tag>Pkg-Description</tag>
- <item>This tag should give reasonable information about the
- software as it normally is done in <file>debian/control</file>
+ 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.
- </item>
- <tag>Remark</tag>
- <item>In some cases it makes perfectly sense to add a remark on
+ 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.
- </item>
- <tag>Registration</tag>
- <item>Sometimes, specifically in the case of scientific software,
+ 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.
- </item>
- <tag>Published-* (deprecated)</tag>
- <item>
- <p>These tags were previouosely used to specify scientific
+ 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 <file>debian/upstream</file> as documented in
- <url id="http://wiki.debian.org/UpstreamMetadata" name="Debian
- Wiki">. The <file>debian/upstream</file> files will be gathered
+ 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.
- </p>
- </item>
-</taglist>
-</p>
+ </para>
+ </listitem>
+</varlistentry>
-<sect1 id="webconf">
-<heading>Configuring Web Sentinel pages per Blend</heading>
+</variablelist>
+</para>
-<p>
+<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
-<url id="http://svn.debian.org/wsvn/blends/blends/trunk/webtools/webconf/"
- name="maintained in SVN">. The following values can be set:
-<taglist>
- <tag>Blend</tag>
- <item>Id of the Blend (for instance debian-edu, debian-med, etc.)
- </item>
- <tag>ProjectName</tag>
- <item>Name the Blend in correct spelling. Please note that English
+<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)
- </item>
- <tag>ProjectUrl</tag>
- <item>URL to technical information about the Blend
- </item>
- <tag>Homepage</tag>
- <item>URL to the user oriented homepage of the Blend
- </item>
- <tag>AliothUrl</tag>
- <item>URL of the Alioth project of the Blend (might be identical to
- ProjectUrl)
- </item>
- <tag>LogoUrl</tag>
- <item>URL to a logo image of the Blend
- </item>
- <tag>ProjectList</tag>
- <item>E-Mail address of a mailing list where developers and users
- of the Blend are communicating
- </item>
- <tag>PkgList</tag>
- <item>E-Mail address of a mailing list where developers of the
- Blend are discussing technical details of packaging
- </item>
- <tag>OutputDir</tag>
- <item>Directory where to put the rendered HTML pages. The Blends
+ 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 <file>/var/lib/gforge/chroot/home/groups/blends/htdocs/<ProjectName></file>
- </item>
- <tag>DataDir</tag>
- <item>Directory where the rendering code stores temporary data like
+ 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
- <file>/var/lib/gforge/chroot/home/groups/blends/data/<ProjectName></file>
- </item>
- <tag>VcsDir</tag>
- <item>Path to tasks files in Blends SVN
- <file>/svn/blends/projects/science/trunk/<ProjectName></file>
- </item>
- <tag>CSS</tag>
- <item>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.
- </item>
-</taglist>
-</p>
+ <filename>/var/lib/gforge/chroot/home/groups/blends/data/<ProjectName></filename>
+ </para>
+ </listitem>
+</varlistentry>
-</sect1>
+<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>
- <sect1 id="ddtp">
- <heading>Debian Description Translation Project</heading>
+</sect2>
-<p>
-The <url id="http://ddtp.debian.net/" name="Debian Description
-Translation Project"> (see <ref id="documentation">) provides users of
+ <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
@@ -273,21 +365,21 @@ 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.
-</p>
-<p>
+</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.
-</p>
+</para>
- </sect1>
+ </sect2>
- <sect1>
- <heading>Features of the web sentinel tasks pages</heading>
-<p>
+ <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
@@ -297,104 +389,103 @@ translations for all these packages are existing.
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.
-</p>
-<p>
-<taglist>
- <tag>Short and long Description</tag>
- <item>If there is a DDTP translation the descriptions are translated.
- </item>
- <tag>Homepage</tag>
- <item>The Homepage field is taken from
- the <file>debian/control</file> file. If this information is
+</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.
- </item>
- <tag>Maintainer / last Uploader</tag>
- <item>Both are provides as mailto-links. If the latest Uploader is
+ 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.
- </item>
- <tag>Popularity contest</tag>
- <item>The popularity contest database contains different values.
+ 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
- </item>
- <tag>Versions and architectures</tag>
- <item>A button can be used to uncover the versions of this package
+ 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.
- </item>
-</taglist>
-</p>
+ packaging team to easily detect work items to do.</para>
+ </listitem>
+</varlistentry>
+
+</variablelist>
+</para>
+ </sect2>
</sect1>
- </sect>
- <sect id="bugs">
- <heading>Bugs overview</heading>
-<p>
+ <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 <file>tasks</file> files are parsed for the listed
+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.
-</p>
-<p>
+</para>
+<para>
If you want to see examples for those bugs pages just have a look at the
-<url id="http://blends.alioth.debian.org/" name="list of all Blends">
+<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.
-</p>
+</para>
- </sect>
+ </sect1>
- <sect id="svnoverview">
- <heading>SVN overview</heading>
-<p>
+ <sect1 id="svnoverview">
+ <title>SVN overview</title>
+<para>
This page gives a recent overview about the current development
activities of the Blend developers.
-</p>
- </sect>
+</para>
+ </sect1>
- <sect id="qareport">
- <heading>Quality assurance report</heading>
+ <sect1 id="qareport">
+ <title>Quality assurance report</title>
-<p>
+<para>
The Debian Quality Assurance group does a decent job in watching the
status o f Debian packages. If a package features a
-valid <file>debian/watch</file> the tool <prgn>uscan</prgn> is able to
+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.
-</p>
- </sect>
-
-</chapt>
-
-<!-- Keep this comment at the end of the file
-Local variables:
-mode: sgml
-sgml-omittag:nil
-sgml-shorttag:t
-sgml-namecase-general:t
-sgml-general-insert-case:lower
-sgml-minimize-attributes:nil
-sgml-always-quote-attributes:t
-sgml-indent-step:2
-sgml-indent-data:t
-sgml-parent-document:("../debian-blends.en.sgml" "book" "chapt")
-sgml-exposed-tags:nil
-sgml-local-catalogs:nil
-sgml-local-ecat-files:nil
-End:
--->
+</para>
+ </sect1>
+
+</chapter>
diff --git a/doc/en/09_todo.sgml b/doc/en/09_todo.xml
similarity index 64%
rename from doc/en/09_todo.sgml
rename to doc/en/09_todo.xml
index d0053d3..eccdbc2 100644
--- a/doc/en/09_todo.sgml
+++ b/doc/en/09_todo.xml
@@ -1,38 +1,47 @@
-<chapt id="todo">
- <heading>To do</heading>
+<chapter id="todo">
+ <title>To do</title>
- <sect id="communication">
- <heading>Establishing and using communication platforms</heading>
+ <sect1 id="communication">
+ <title>Establishing and using communication platforms</title>
-<p>
+<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 <url id="http://lists.debian.org/debian-blends/" name="subscribe
-to this list or read the list archive">.
-</p>
-<p>
-Moreover the project <url id="http://alioth.debian.org/projects/blends/"
-name="Blends"> on Alioth exists to organise the cooperation of developers.
-The <url id="http://svn.debian.org/wsvn/blends/" name="subversion repository">
+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
-<example>
+<informalexample>
+ <programlisting>
svn checkout svn://svn.debian.org/svn/blends blends
-</example>
+</programlisting>
+</informalexample>
+<programlisting>
for anonymous users. Developers should check out via
-<example>
- svn checkout svn+ssh://<var>username</var>@svn.debian.org/svn/blends blends
-</example>
+</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:
-<example>
+</programlisting>
+<informalexample>
+ <programlisting>
blends -+- blends
| |
| +- tags -----+- blends -+- 0.3 [older versions of blends tools]
| | | +- 0.3.1
| | | ...
- | | | +- <var><latest></var>
+ | | | +- <varname><latest></varname>
| | |
| | +- doc -+- 0.1 [older versions of this doc]
| | +- 0.2
@@ -54,122 +63,135 @@ The current layout for the repository is as follows:
+- ...
|
...
-</example>
+ </programlisting>
+</informalexample>
There is
-a <url id="http://lists.alioth.debian.org/mailman/listinfo/blends-commits"
-name="mailing list"> with subversion changes and
-a <url id="http://cia.navi.cx/stats/project/debian-custom" name="CIA
-system"> for tracking changes in the Debian Pure Blends projects in
+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.
-</p>
- </sect>
+</para>
+ </sect1>
- <sect id="visibility">
- <heading>Enhancing visibility</heading>
+ <sect1 id="visibility">
+ <title>Enhancing visibility</title>
-<p>
+<para>
If a user installs Debian via official install CDs the first chance to
-do a package selection to customise the box is <prgn>tasksel</prgn>.
+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.
-</p>
-<p>
-In bug <url id="http://bugs.debian.org/186085" name="#186085"> a
+</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 <prgn>tasksel</prgn>-approach is that all included
+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.
-</p>
-<p>
+</para>
+<para>
How to enhance visibility of Debian Pure Blends for the user who
installs Debian from scratch?
-<taglist>
- <tag>Change <prgn>tasksel</prgn> policy.</tag>
- <item>If the <em>packages must be on the first CD</em> feature of
- <prgn>tasksel</prgn> would be dropped all Blends could be
- listed under this topic in the task selection list.
- </item>
- <tag>Debian Pure Blends information screen.</tag>
- <item>Alternatively a new feature could be added to
- <prgn>tasksel</prgn> or in addition to <prgn>tasksel</prgn>
+<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.
- </item>
- <tag>Provide separate install CDs</tag>
- <item>By completely ignoring the installation of the official
+ 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.
- </item>
- <tag>Change overall distribution philosophy of Debian.</tag>
- <item>This way is concerned to some ideas from Debian developers
+ 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 <ref id="new_ways_of_distribution">. This would save the
+ 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.
- </item>
-</taglist>
-</p>
-<p>
+ 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 <em>show</em> our users the tools we
+interest to support users and <emphasis>show</emphasis> our users the tools we
invented to support them.
-</p>
- <sect1 id="webpages">
- <heading>Debian Pure Blends web pages</heading>
-<p>
+</para>
+ <sect2 id="webpages">
+ <title>Debian Pure Blends web pages</title>
+<para>
Some Blends maintain their own web space under
-<tt>http://www.debian.org/devel/BLEND-name</tt> to provide general
+<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 <ref id="web_if"> to make sure that the content of the page remains
+in <xref linkend="web_if"/> to make sure that the content of the page remains
up to date at any time.
-</p>
- </sect1>
- </sect>
+</para>
+ </sect2>
+ </sect1>
- <sect id="debtags">
- <heading>Debian Package Tags</heading>
+ <sect1 id="debtags">
+ <title>Debian Package Tags</title>
-<p>
-<url id="http://debtags.alioth.debian.org/" name="Debian
-Package Tags"> is a work to add more metadata to Debian packages.
+<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.
-</p>
-<p>
+</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.
-</p>
-<p>
+</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.
-</p>
-<p>
+</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.
-</p>
-<p>
+</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
@@ -177,89 +199,91 @@ classification would be managed by the Debian Edu people, while
Debian Edu users looking for "use::configuring" could have a look at
what packages in that category are suggested by the Debian Edu
community.
-</p>
-<p>
+</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.
-</p>
-<p>
+</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.
-</p>
- </sect>
+</para>
+ </sect1>
- <sect id="EnhancingTechnology">
- <heading>Enhancing basic technologies regarding Debian Pure Blends</heading>
+ <sect1 id="EnhancingTechnology">
+ <title>Enhancing basic technologies regarding Debian Pure Blends</title>
-<p>
-In section <ref id="future_handling"> several issues where raised how
+<para>
+In section <xref linkend="future_handling"/> several issues where raised how
handling of metapackages should be enhanced.
-</p>
-<p>
+</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
-<prgn>debconf</prgn> configuration for this case. Then the
+<orgname>debconf</orgname> configuration for this case. Then the
metapackage could provide the needed options by pre-seeding the
-<prgn>debconf</prgn> database while using very low priority questions
+<orgname>debconf</orgname> database while using very low priority questions
which do not came to users notice.
-</p>
-<p>
+</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 <prgn>cfengine</prgn>
+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 <prgn>cfengine</prgn>
+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-<prgn>cfengine</prgn>-driven-administrator-robot".
-</p>
-<p>
-If there is some agreement to use <prgn>cfengine</prgn> scripts to
-change configuration - either according to <prgn>debconf</prgn>
+"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
-<example>
+<informalexample>
+ <programlisting>
/usr/share/blends/#BLEND#/#METAPACKAGE#/cf.#SOMETHING#
-</example>
-</p>
-<p>
+ </programlisting>
+</informalexample>
+</para>
+<para>
There was another suggestion at the Valencia workshop: Make use of
-<prgn>ucf</prgn> for the purpose mentioned above. This is a topic
+<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 <prgn>cfengine</prgn> but perhaps it is worth comparing
+experiences with <package>cfengine</package> but perhaps it is worth comparing
both.
-</p>
-<p>
+</para>
+<para>
A further option might be
-<url id="http://freedesktop.org/Software/CFG" name="Config4GNU"> from
+<ulink url="http://freedesktop.org/Software/CFG">Config4GNU</ulink> from
freedesktop.org but it is not even yet packaged for Debian.
-</p>
- </sect>
+</para>
+ </sect1>
- <sect id="liveCD">
- <heading>Building Live CDs of each Debian Pure Blend</heading>
+ <sect1 id="liveCD">
+ <title>Building Live CDs of each Debian Pure Blend</title>
-<p>
+<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.
-<url id="http://www.knoppix.org/" name="Knoppix"> - <em>the "mother" of
-all Debian-based live CDs</em> - is a really great success and it is a
+<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.
-</p>
-<p>
+</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
@@ -268,11 +292,11 @@ 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 <url id="http://dirk.eddelbuettel.com/quantian.html"
-name="Quantian"> which is quite regularly updated and is intended for
+perhaps <ulink url="http://dirk.eddelbuettel.com/quantian.html">
+Quantian</ulink> which is quite regularly updated and is intended for
scientists.
-</p>
-<p>
+</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
@@ -280,37 +304,38 @@ 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.
-</p>
+</para>
- </sect>
+ </sect1>
- <sect id="new_ways_of_distribution">
- <heading>New way to distribute Debian</heading>
+ <sect1 id="new_ways_of_distribution">
+ <title>New way to distribute Debian</title>
-<p>
-<em>This section is kind of "Request For Comments" in the sense that
+<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.</em>
-</p>
-<p>
+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.
-</p>
-<p>
+</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 <tt>unstable</tt>. The normal
-process which propagates packages to <tt>testing</tt> and releasing a
-complete <tt>stable</tt> distribution also remains untouched. The new
+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 <tt>tested inside the subset</tt> distribution
-which leads to a <tt>stable</tt> subset release. The following graph
+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:
-<example>
+<informalexample>
+ <programlisting>
DD -> unstable --> testing --> stable
|
+---> BLEND_A testing --> stable BLEND_A
@@ -318,49 +343,64 @@ DD -> unstable --> testing --> stable
+---> BLEND_B testing --> stable BLEND_B
|
+---> ...
-</example>
+ </programlisting>
+</informalexample>
-where <tt>BLEND_A</tt> / <tt>BLEND_B</tt> might be something like
-<tt>debian-edu</tt> / <tt>debian-med</tt>. To implement this
+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:
-<taglist>
- <tag>Promotion rules</tag>
- <item>There was a general agreement that technical implementation
+<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 <tt>debian-desktop</tt> project. Unfortunately this
- goal was not realised finally.
- </item>
- <tag>Reasonable subsets</tag>
- <item>Once the promotion tools are able to work with sub-setting,
+ 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.
- </item>
- <tag>BTS support</tag>
- <item>The Bug Tracking System has to deal with different package
+ 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.
- </item>
- <tag>Security</tag>
- <item>As a consequence of having more than only a single
- <tt>stable</tt> each Blend team has to form a security team
+ 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" <tt>stable</tt>.
- </item>
-</taglist>
-</p>
-<p>
-A not so drastically change would be to find a <em>common</em> set of
+ 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:
-<example>
+<informalexample>
+ <programlisting>
DD -> unstable --> testing --> releasable --> stable
|
+---> stable BLEND_A
@@ -368,12 +408,14 @@ DD -> unstable --> testing --> releasable --> stable
+---> stable BLEND_B
|
+---> ...
-</example>
-
+ </programlisting>
+</informalexample>
+<programlisting>
A third suggestion was given at Congreso Software Libre Comunidad
Valenciana:
-
-<example>
+</programlisting>
+<informalexample>
+<programlisting>
testing_proposed_updated
|
|
@@ -385,7 +427,8 @@ DD -> unstable --> testing --> stable
+---> stable BLEND_B
|
+---> ...
-</example>
+</programlisting>
+</informalexample>
The rationale behind these testing backports is that sometimes a
Debian Pure Blend is able to reduce the set of releasable
@@ -393,8 +436,8 @@ 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.
-</p>
-<p>
+</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
@@ -408,7 +451,8 @@ 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:
-<example>
+<informalexample>
+<programlisting>
debian/dists/stable/binary-i386
/binary-sparc
/binary-...
@@ -424,44 +468,32 @@ structures of the Debian mirrors:
pool/main
/contrib
/non-free
-</example>
+</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.
-</p>
-<p>
+</para>
+<para>
Regarding to security issues there are two ways: Either one Debian
Pure Blend goes with the current stable Debian and thus the
-<file>Packages.gz</file> is just pointing to the very same versions
+<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.
-</p>
-<p>
+</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.
-</p>
- </sect>
-</chapt>
+</para>
+ </sect1>
+</chapter>
-<!-- Keep this comment at the end of the file
-Local variables:
-mode: sgml
-sgml-omittag:nil
-sgml-shorttag:t
-sgml-namecase-general:t
-sgml-general-insert-case:lower
-sgml-minimize-attributes:nil
-sgml-always-quote-attributes:t
-sgml-indent-step:2
-sgml-indent-data:t
-sgml-parent-document:("../debian-blends.en.sgml" "book" "chapt")
-sgml-exposed-tags:nil
-sgml-local-catalogs:nil
-sgml-local-ecat-files:nil
-End:
+<!--
+ 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
new file mode 100644
index 0000000..8da6172
--- /dev/null
+++ b/doc/en/A_devel.xml
@@ -0,0 +1,837 @@
+ <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.sgml b/doc/en/B_quickintro.xml
similarity index 57%
rename from doc/en/B_quickintro.sgml
rename to doc/en/B_quickintro.xml
index cb9cb34..7367b3a 100644
--- a/doc/en/B_quickintro.sgml
+++ b/doc/en/B_quickintro.xml
@@ -1,178 +1,193 @@
<appendix id="QuickIntro">
- <heading>Quick intro into building metapackages</heading>
+ <title>Quick intro into building metapackages</title>
-<p>
+<para>
There are several descriptions available how to build Debian packages
in general. The main resource might be the repository of
-<url
-id="http://www.debian.org/doc/packaging-manuals/"
-name="Debian packaging manuals"> (especially
-<url
-id="http://www.debian.org/doc/packaging-manuals/developers-reference/best-pkging-practices.html"
-name="developers reference chapter 6, best packaging practices">).
+<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
-<url
-id="http://www-106.ibm.com/developerworks/linux/library/l-debpkg.html"
-name="Joe 'Zonker' Brockmeier">.
-</p>
+<ulink url="http://www-106.ibm.com/developerworks/linux/library/l-debpkg.html">
+ Joe 'Zonker' Brockmeier</ulink>.
+</para>
- <sect id="Dependencies">
- <heading>Defining dependencies for metapackages</heading>
+ <sect1 id="Dependencies">
+ <title>Defining dependencies for metapackages</title>
-<p>
+<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.
- <example>
+ <informalexample>
+ <programlisting>
~> cp -a /usr/share/doc/blends-dev/examples/tasks .
~> cat tasks/README
~> edit tasks/task1
-Description: <var>short description
- long description as in any debian/control file</var>
+Description: <varname>short description
+ long description as in any debian/control file</varname>
-Depends: <var>dependency1, dependency2, ...</var>
- </example>
+Depends: <varname>dependency1, dependency2, ...</varname>
+</programlisting>
+ </informalexample>
-For each metapackage this skeleton of a <file>debian/control</file>
+For each metapackage this skeleton of a <filename>debian/control</filename>
entry is needed. All necessary information is available in the
-directory <file>/usr/share/doc/blends-dev/examples/tasks</file>.
-</p>
- </sect>
+directory <filename>/usr/share/doc/blends-dev/examples/tasks</filename>.
+</para>
+ </sect1>
- <sect id="Packaging">
- <heading>The packaging directory</heading>
+ <sect1 id="Packaging">
+ <title>The packaging directory</title>
-<p>
+<para>
To build any Debian package you always need a directory named
-<file>debian</file>, which contains a certain set of files. The
+<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.
-<example>
+<informalexample>
+ <programlisting>
~> cp -a /usr/share/doc/blends-dev/examples/debian .
~> cat debian/README
~> edit debian/control.stub
-</example>
-Now the variables in the file <file>control.stub</file> change the
-variables named <var>_BLEND_</var>, <var>_MAINTAINER_</var> etc. to
+</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 <file>debian/control</file> is and has to be a symbolic
-link to <file>control.stub</file> to let the
+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.
-<example>
+<informalexample>
+ <programlisting>
~> edit debian/rules
-</example>
+</programlisting>
+</informalexample>
-Also in the <file>debian/rules</file> the name of the Blend has to be
+Also in the <filename>debian/rules</filename> the name of the Blend has to be
inserted where the template contains
-<var>_BLEND_</var>. Depending from the way the
-<file>sources.list</file> should be scanned the options for the
-<prgn>gen-control</prgn> call can be adjusted.
-</p>
-<p>
+<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
-<example>
+<informalexample>
+ <programlisting>
~> make -f debian/rules get-orig-source
-</example>
+</programlisting>
+</informalexample>
For your comfort you might like to create a file
-<file>Makefile</file> containing
-<example>
+<filename>Makefile</filename> containing
+<informalexample>
+ <programlisting>
#!/usr/bin/make -f
include /usr/share/blends-dev/Makefile
-</example>
+</programlisting>
+</informalexample>
which enables you to simply use
-<example>
+<informalexample>
+ <programlisting>
~> make dist
-</example>
+</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
-<example>
+<informalexample>
+ <programlisting>
~> debuild
-</example>
-</p>
-<p>
+</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.
-</p>
+</para>
- </sect>
+ </sect1>
- <sect id="common-metapackage">
- <heading>The common metapackage</heading>
+ <sect1 id="common-metapackage">
+ <title>The common metapackage</title>
-<p>
+<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
-<file>blend-install-helper</file>, which is called in
-<file>debian/rules</file>, if the <file>common</file> directory exists.
+<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:
-<example>
+<informalexample>
+ <programlisting>
~> cp -a /usr/share/doc/blends-dev/examples/common .
~> cat common/README
~> edit common/conf common/control common/common.1
-</example>
-The variables (<var>_BLEND_</var>) in these three files have to be
+</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 <file><var>blend</var>-config</file> cares for the initialisation
+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>.
-</p>
-<p>
-If the metapackage <package><var>blend</var>-config</package> will be
+</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
-<prgn>auto-apt</prgn>, a helper
-<file>/usr/bin/<var><metapackage-name></var></file> will be
+<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.
-</p>
- </sect>
- <sect id="metapackage-menus">
- <heading>The metapackage menus</heading>
+</para>
+ </sect1>
+ <sect1 id="metapackage-menus">
+ <title>The metapackage menus</title>
-<p>
-As explained in <ref id="menu_tools"> the metapackages can contain
+<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:
-<example>
+<informalexample>
+ <programlisting>
~> cp -a /usr/share/doc/blends-dev/examples/menu .
~> cat menu/README
~> edit menu/task1
- <var>Edit the example to legal menu entries of the
- dependencies of this metapackage</var>
-~> cp menu/task1 menu/<var><metapackage name></var>
-</example>
+ <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
-<tt>package</tt> field, which has to be changed from
+<package>package</package> field, which has to be changed from
<package><dependent package></package> to
-<package><var>blend</var>-<var>task</var></package>. All other entries
+<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.
-</p>
-<p>
+</para>
+<para>
In principle these menu items could be created automatically either at
-metapackage build time or even better in the <file>postinst</file>
+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
@@ -185,13 +200,13 @@ 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.
-</p>
+</para>
- </sect>
- <sect id="any-dependency--menus">
- <heading>Menu for any dependency</heading>
+ </sect1>
+ <sect1 id="any-dependency--menus">
+ <title>Menu for any dependency</title>
-<p>
+<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
@@ -199,39 +214,24 @@ with relevant documentation should be provided in a viewer by the
creator of the metapackage. Such documentation can be created using
the following templates:
-<example>
+<informalexample>
+ <programlisting>
~> cp -a /usr/share/doc/blends-dev/examples/docs .
~> cat docs/README
~> edit docs/task1/dep1
- <var>Provide information about a package <dep1> that is
+ <varname>Provide information about a package <dep1> that is
a dependency of the metapackage <task1>, but does not
- contain a useful menu entry.</var>
-~> cp docs/task1/dep1 docs/task1/<var><dependent pkg></var>
-~> cp -a docs/task1 docs/<var><metapackage name></var>
-</example>
+ 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.
-</p>
+</para>
+</sect1>
</appendix>
-
-<!-- Keep this comment at the end of the file
-Local variables:
-mode: sgml
-sgml-omittag:nil
-sgml-shorttag:t
-sgml-namecase-general:t
-sgml-general-insert-case:lower
-sgml-minimize-attributes:nil
-sgml-always-quote-attributes:t
-sgml-indent-step:2
-sgml-indent-data:t
-sgml-parent-document:("../debian-blends.en.sgml" "book" "chapt")
-sgml-exposed-tags:nil
-sgml-local-catalogs:nil
-sgml-local-ecat-files:nil
-End:
--->
diff --git a/doc/en/C_bts.sgml b/doc/en/C_bts.sgml
deleted file mode 100644
index 394b4af..0000000
--- a/doc/en/C_bts.sgml
+++ /dev/null
@@ -1,72 +0,0 @@
- <appendix id="bts">
- <heading>Using the Bug Tracking System</heading>
-
- <sect id="howto_itp">
- <heading>How to ask for packages which are not yet included</heading>
-
-<p>
-A very frequently asked question in mailing list is, whether
-<prgn>program_xy</prgn> 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.
-</p>
-<p>
-There is a <url id="http://www.debian.org/devel/wnpp/#l1"
- name="detailed description"> how anybody can ask for including a
-certain piece of software into Debian. It explains how to use the
-program <prgn>reportbug</prgn> for this purpose.
-</p>
-<p>
-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 <ref id="packageslist">
-for more details).
-</p>
- </sect>
-
- <sect id="howto_file_bugs">
- <heading>How to report problems</heading>
-
-<p>
-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.
-</p>
-<p>
-A <url id="http://www.debian.org/Bugs/Reporting" name="detailed
-explanation how to report errors"> is helpful in these cases. While
-the program <prgn>reportbug</prgn> fetches other reports from BTS
-before creating the bug report it is always a good idea to search
-<url id="http://bugs.debian.org"
-name="http://bugs.debian.org/_package_"> for known problems and
-probably suggested solutions before calling <prgn>reportbug</prgn>.
-</p>
-
-</sect>
-
-</appendix>
-
-<!-- Keep this comment at the end of the file
-Local variables:
-mode: sgml
-sgml-omittag:nil
-sgml-shorttag:t
-sgml-namecase-general:t
-sgml-general-insert-case:lower
-sgml-minimize-attributes:nil
-sgml-always-quote-attributes:t
-sgml-indent-step:2
-sgml-indent-data:t
-sgml-parent-document:("../debian-blends.en.sgml" "book" "chapt")
-sgml-exposed-tags:nil
-sgml-local-catalogs:nil
-sgml-local-ecat-files:nil
-End:
--->
diff --git a/doc/en/C_bts.xml b/doc/en/C_bts.xml
new file mode 100644
index 0000000..c1e4c83
--- /dev/null
+++ b/doc/en/C_bts.xml
@@ -0,0 +1,54 @@
+ <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 code
More information about the Blends-commit
mailing list