[Blends-commit] r2414 - in /blends/trunk/blends/doc/docbook-xml: ./ en/ fr/
georgesk at users.alioth.debian.org
georgesk at users.alioth.debian.org
Tue Oct 26 16:58:22 UTC 2010
Author: georgesk
Date: Tue Oct 26 16:58:17 2010
New Revision: 2414
URL: http://svn.debian.org/wsvn/blends/?sc=1&rev=2414
Log:
first port to docbook-xml format, and localisation to French initiated
Added:
blends/trunk/blends/doc/docbook-xml/
blends/trunk/blends/doc/docbook-xml/Makefile
blends/trunk/blends/doc/docbook-xml/debian-blends.en.xml
blends/trunk/blends/doc/docbook-xml/debian-blends.fr.xml
blends/trunk/blends/doc/docbook-xml/en/
blends/trunk/blends/doc/docbook-xml/en/00_titletoc.xml
blends/trunk/blends/doc/docbook-xml/en/01_introduction.xml
blends/trunk/blends/doc/docbook-xml/en/02_about.xml
blends/trunk/blends/doc/docbook-xml/en/03_general_ideas.xml
blends/trunk/blends/doc/docbook-xml/en/04_existing_blends.xml
blends/trunk/blends/doc/docbook-xml/en/05_inside.xml
blends/trunk/blends/doc/docbook-xml/en/06_technology.xml
blends/trunk/blends/doc/docbook-xml/en/07_starting.xml
blends/trunk/blends/doc/docbook-xml/en/08_websentinel.xml
blends/trunk/blends/doc/docbook-xml/en/09_todo.xml
blends/trunk/blends/doc/docbook-xml/en/A_devel.xml
blends/trunk/blends/doc/docbook-xml/en/B_quickintro.xml
blends/trunk/blends/doc/docbook-xml/en/C_bts.xml
blends/trunk/blends/doc/docbook-xml/en/sgml2xml (with props)
blends/trunk/blends/doc/docbook-xml/fr/
blends/trunk/blends/doc/docbook-xml/fr/00_titletoc.xml
blends/trunk/blends/doc/docbook-xml/fr/01_introduction.xml
blends/trunk/blends/doc/docbook-xml/fr/02_about.xml
blends/trunk/blends/doc/docbook-xml/fr/03_general_ideas.xml
blends/trunk/blends/doc/docbook-xml/fr/04_existing_blends.xml
blends/trunk/blends/doc/docbook-xml/fr/05_inside.xml
blends/trunk/blends/doc/docbook-xml/fr/06_technology.xml
blends/trunk/blends/doc/docbook-xml/fr/07_starting.xml
blends/trunk/blends/doc/docbook-xml/fr/08_websentinel.xml
blends/trunk/blends/doc/docbook-xml/fr/09_todo.xml
blends/trunk/blends/doc/docbook-xml/fr/A_devel.xml
blends/trunk/blends/doc/docbook-xml/fr/B_quickintro.xml
blends/trunk/blends/doc/docbook-xml/fr/C_bts.xml
blends/trunk/blends/doc/docbook-xml/fr/sgml2xml (with props)
Added: blends/trunk/blends/doc/docbook-xml/Makefile
URL: http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/docbook-xml/Makefile?rev=2414&op=file
==============================================================================
--- blends/trunk/blends/doc/docbook-xml/Makefile (added)
+++ blends/trunk/blends/doc/docbook-xml/Makefile Tue Oct 26 16:58:17 2010
@@ -1,0 +1,95 @@
+## ----------------------------------------------------------------------
+## Makefile : makefile for docbook-xml
+## ----------------------------------------------------------------------
+
+## ----------------------------------------------------------------------
+## Document definitions
+doc_lang := fr en
+doc_name := debian-blends
+doc_xml := $(shell for l in $(doc_lang); do echo $(doc_name).$$l.xml; done)
+sources := $(shell find . -name "*.xml")
+doc_pdf := $(shell for l in $(doc_lang); do echo $$l/pdf/$(doc_name).$$l.pdf; done)
+doc_ps := $(shell for l in $(doc_lang); do echo $$l/ps/$(doc_name).$$l.ps; done)
+doc_dvi := $(shell for l in $(doc_lang); do echo $$l/dvi/$(doc_name).$$l.dvi; done)
+doc_txt := $(shell for l in $(doc_lang); do echo $$l/txt/$(doc_name).$$l.txt; done)
+doc_html := $(shell for l in $(doc_lang); do echo $$l/html/index.html; done)
+pkg := blends-doc
+
+## ----------------------------------------------------------------------
+## General definitions
+LN := /bin/ln -sf
+RMR := /bin/rm -fr
+LOCALE := unset LC_ALL; unset LANG; unset LANGUAGE;
+
+## ----------------------------------------------------------------------
+# this can and will be overriden by a higher level makefile
+PUBLISHDIR := alioth.debian.org:/srv/alioth.debian.org/chroot/home/groups/blends/htdocs/blends
+
+# There is no difference between letter and a4, but a2 for instance works
+PAPERSIZE := a4
+
+## ----------------------------------------------------------------------
+## Targets
+all: html
+
+validate: $(doc_xml)
+ for f in $(doc_xml); do \
+ xmllint --valid --noout $$f; \
+ done
+
+html: $(doc_html)
+
+$(doc_html): $(doc_xml) $(sources)
+ for l in $(doc_lang); do \
+ f=$(doc_name).$$l.xml; d=$$l/html; \
+ mkdir -p $$d; \
+ $(LOCALE) xmlto -o $$d 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 -o $$d txt $$f; \
+ done
+
+ps $(doc_ps): $(doc_xml)
+ for l in $(doc_lang); do \
+ f=$(doc_name).$$l.xml; d=$$l/ps; \
+ mkdir -p $$d; \
+ $(LOCALE) xmlto -o $$d ps $$f; \
+ done
+
+
+pdf $(doc_pdf): $(doc_xml)
+ for l in $(doc_lang); do \
+ f=$(doc_name).$$l.xml; d=$$l/pdf; \
+ mkdir -p $$d; \
+ $(LOCALE) xmlto -o $$d pdf $$f; \
+ done
+
+
+dvi $(doc_dvi): $(doc_xml)
+ for l in $(doc_lang); do \
+ f=$(doc_name).$$l.xml; d=$$l/dvi; \
+ mkdir -p $$d; \
+ $(LOCALE) xmlto -o $$d dvi $$f; \
+ done
+
+
+#publish: html pdf
+# rsync -azult --delete $(doc_html)/* $(PUBLISHDIR)
+# [ -s debian-blends.en.pdf ] && rsync -azult $(doc_pdf) $(PUBLISHDIR)
+
+clean:
+ for l in $(doc_lang); do \
+ for d in html pdf txt ps dvi info; do \
+ $(RMR) $$l/$$d; \
+ done; \
+ done
+ find . -name "*~" -exec $(RMR) {} \;
+
+distclean:
+ make clean
+
+.PHONY: all publish clean distclean validate
Added: blends/trunk/blends/doc/docbook-xml/debian-blends.en.xml
URL: http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/docbook-xml/debian-blends.en.xml?rev=2414&op=file
==============================================================================
--- blends/trunk/blends/doc/docbook-xml/debian-blends.en.xml (added)
+++ blends/trunk/blends/doc/docbook-xml/debian-blends.en.xml Tue Oct 26 16:58:17 2010
@@ -1,0 +1,41 @@
+<?xml version="1.0"?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
+ "/usr/share/sgml/docbook/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" lang="en" >
+
+ &titletoc;
+ <toc />
+
+ &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>
Added: blends/trunk/blends/doc/docbook-xml/debian-blends.fr.xml
URL: http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/docbook-xml/debian-blends.fr.xml?rev=2414&op=file
==============================================================================
--- blends/trunk/blends/doc/docbook-xml/debian-blends.fr.xml (added)
+++ blends/trunk/blends/doc/docbook-xml/debian-blends.fr.xml Tue Oct 26 16:58:17 2010
@@ -1,0 +1,41 @@
+<?xml version="1.0"?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
+ "/usr/share/sgml/docbook/dtd/4.5/docbookx.dtd"
+[
+ <!-- textual data entities -->
+ <!ENTITY titletoc SYSTEM "fr/00_titletoc.xml">
+ <!ENTITY ch-introduction SYSTEM "fr/01_introduction.xml">
+ <!ENTITY ch-about SYSTEM "fr/02_about.xml">
+ <!ENTITY ch-general-ideas SYSTEM "fr/03_general_ideas.xml">
+ <!ENTITY ch-existing-blends SYSTEM "fr/04_existing_blends.xml">
+ <!ENTITY ch-inside SYSTEM "fr/05_inside.xml">
+ <!ENTITY ch-technology SYSTEM "fr/06_technology.xml">
+ <!ENTITY ch-starting SYSTEM "fr/07_starting.xml">
+ <!ENTITY ch-websentinel SYSTEM "fr/08_websentinel.xml">
+ <!ENTITY ch-todo SYSTEM "fr/09_todo.xml">
+ <!ENTITY ap-devel SYSTEM "fr/A_devel.xml">
+ <!ENTITY ap-quickintro SYSTEM "fr/B_quickintro.xml">
+ <!ENTITY ap-bts SYSTEM "fr/C_bts.xml">
+]
+>
+
+<book id="debiandoc-xml" lang="fr" >
+
+ &titletoc;
+ <toc />
+
+ &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>
Added: blends/trunk/blends/doc/docbook-xml/en/00_titletoc.xml
URL: http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/docbook-xml/en/00_titletoc.xml?rev=2414&op=file
==============================================================================
--- blends/trunk/blends/doc/docbook-xml/en/00_titletoc.xml (added)
+++ blends/trunk/blends/doc/docbook-xml/en/00_titletoc.xml Tue Oct 26 16:58:17 2010
@@ -1,0 +1,82 @@
+<bookinfo>
+
+ <title>Debian Pure Blends</title>
+ <!-- subtitle> Preparing Debian for special user groups </subtitle -->
+
+<author>
+ <firstname>Andreas</firstname> <surname>Tille</surname>
+ <email>tille at debian.org</email>
+</author>
+
+<pubdate/>
+
+<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>
+<copyright>
+ <year>2004</year>
+ <year>2005</year>
+ <year>2006</year>
+ <year>2007</year>
+ <year>2008</year>
+ <year>2009</year>
+ <holder> Andreas Tille</holder>
+</copyright>
+
+<legalnotice>
+ <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">
+ <citebiblioid>http://www.gnu.org/copyleft/gpl.html"</citebiblioid>
+ </ulink>.
+ 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://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/">
+ in the Subversion repository at
+ <citebiblioid>svn.debian.org</citebiblioid>
+ </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>
+
+</bookinfo>
+
Added: blends/trunk/blends/doc/docbook-xml/en/01_introduction.xml
URL: http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/docbook-xml/en/01_introduction.xml?rev=2414&op=file
==============================================================================
--- blends/trunk/blends/doc/docbook-xml/en/01_introduction.xml (added)
+++ blends/trunk/blends/doc/docbook-xml/en/01_introduction.xml Tue Oct 26 16:58:17 2010
@@ -1,0 +1,47 @@
+<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 (formerly known as Custom Debian Distributions)
+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>
+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>
Added: blends/trunk/blends/doc/docbook-xml/en/02_about.xml
URL: http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/docbook-xml/en/02_about.xml?rev=2414&op=file
==============================================================================
--- blends/trunk/blends/doc/docbook-xml/en/02_about.xml (added)
+++ blends/trunk/blends/doc/docbook-xml/en/02_about.xml Tue Oct 26 16:58:17 2010
@@ -1,0 +1,225 @@
+
+<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>
+<!--AT: The context is somehow missing here. -->
+ 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 role="strong">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:
+ <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>
+ 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 role="strong">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>
+</sect1>
+
+</chapter>
Added: blends/trunk/blends/doc/docbook-xml/en/03_general_ideas.xml
URL: http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/docbook-xml/en/03_general_ideas.xml?rev=2414&op=file
==============================================================================
--- blends/trunk/blends/doc/docbook-xml/en/03_general_ideas.xml (added)
+++ blends/trunk/blends/doc/docbook-xml/en/03_general_ideas.xml Tue Oct 26 16:58:17 2010
@@ -1,0 +1,342 @@
+<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><para>
+ <itemizedlist>
+ <listitem><para>Corporate Server - Mandriva</para></listitem>
+ <listitem><para>Advanced Server - RedHat</para></listitem>
+ <listitem><para>Enterprise Server - SuSE</para></listitem>
+ </itemizedlist>
+ </para></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><para>
+ <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></para>
+ </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 role="strong">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
+<!-- AT: We should find a way to avoid printing the URL in PDF output. -->
+<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 role="strong">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>
Added: blends/trunk/blends/doc/docbook-xml/en/04_existing_blends.xml
URL: http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/docbook-xml/en/04_existing_blends.xml?rev=2414&op=file
==============================================================================
--- blends/trunk/blends/doc/docbook-xml/en/04_existing_blends.xml (added)
+++ blends/trunk/blends/doc/docbook-xml/en/04_existing_blends.xml Tue Oct 26 16:58:17 2010
@@ -1,0 +1,598 @@
+<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">
+ 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>Release</term>
+ <listitem><para>Debian 3.0 (Woody)</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Goals</term>
+ <listitem><para>
+ <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>
+ </para></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>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>Release</term>
+ <listitem><para>Sarge</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Goals</term>
+ <listitem><para>
+ <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>
+ </para></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>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>Former Initiator</term>
+ <listitem><para>Raphaël Hertzog <email>hertzog at debian.org</email></para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Now 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><para>
+ <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>
+ </para></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>
+<!-- Just learned that they are using Ubuntu now
+ <term><ulink url="http://www.lliurex.net/" name="LliureX"></term>
+ <listitem><para>A Debian derivative distribution in development to be used in
+ schools in Valencia. The goal is to integrate as much as
+ ## {BA} This is a difficult passage to interpret. What does "integrate
+ as much as possible as a Blend" mean? Does it mean they mean to literally
+ produce a Blend (impossible if they remain a derivative)? Or does it mean
+ they are going to "give back" their work into Debian so it could be
+ incorporated into a Blend (debian-edu itself?) Or something else?
+ [AT] More or less something else. They have not really
+ settled down what to do and how to proceed which I wanted to
+ say by "in development". I hope they will follow the
+ Debian Edu way (which I regard as a very clever solution as
+ close as possible but they have to respect local government
+ issues and perhaps need some stuff which can not be
+ integrated. We have to wait a little bit until they have
+ found a decision.
+ ##
+ possible as a Debian Pure Blend.< / item>
+ -->
+<!-- FIXME: Aren't they using Ubuntu as well? -->
+ <varlistentry>
+ <term><ulink url="http://www.guadalinex.org/">Guadalinex</ulink></term>
+ <listitem><para>This distribution is not only related to education, but might
+ try also to integrate what they have produced back into Debian.</para></listitem>
+ </varlistentry>
+ </variablelist>
+</para>
+</sect1>
+
+ <sect1 id="demudi">
+ <title>DeMuDi: Debian Multimedia Distribution</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></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>URL</term>
+ <listitem><para><ulink url="http://www.agnula.org/">Demudi</ulink>
+ (now <ulink url="http://64studio.com/">64 Studio</ulink>)
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Initiator</term>
+ <listitem><para>Marco Trevisani <email>marco at centrotemporeale.it</email></para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Goals</term>
+ <listitem><para>
+ <itemizedlist>
+ <listitem><para>To bring back this fork into Debian.</para></listitem>
+ <!-- [BA] This is not a goal. However, I don't know how to fix it. The
+ DeMuDi site was no help, as I couldn't find goals for the project listed
+ there. Perhaps the point should just be stricken?
+ [AT] I just wanted to express the fact that I got the word
+ that the first metapackages are in preparation by Free Enkanayaka.
+ -->
+ <listitem><para>Oriented toward music and multimedia.</para></listitem>
+ <listitem><para>To make GNU/Linux a platform of choice for the musician
+ and the multimedia artist.</para></listitem>
+ </itemizedlist>
+ </para></listitem>
+ </varlistentry>
+</variablelist>
+
+The initiator is not yet a Debian developer, but it is possible to work on
+Debian without being an official developer.
+</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>Mailing list</term>
+ <listitem><para><ulink url="http://wiki.debian.org/DebianGis/MailingLists">user and developer list</ulink></para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Initiator</term>
+ <listitem><para>Francesco P. Lovergine <email>frankie at debian.org</email></para></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>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>Initiator</term>
+ <listitem><para>Michael Banck <email>mbanck at debian.org</email></para></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>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>Initiator</term>
+ <listitem><para>Helen Faulkner <email>helen 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="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>Initiator</term>
+ <listitem><para>Colin Walters <email>walters at debian.org</email></para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Goals</term>
+ <listitem><para>
+ <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>
+ </para></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 Integrated Solutions. 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>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>Initiator</term>
+ <listitem><para>Jeremy Malcolm <email>Jeremy at Malcolm.id.au</email></para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Goals</term>
+ <listitem><para>
+ <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>
+ </para></listitem>
+ </varlistentry>
+</variablelist>
+The word <emphasis>lex</emphasis> is the Latin word for law.
+</para>
+</sect2>
+
+ <sect2 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>Initiator</term>
+ <listitem><para>Mario Lang <email>mlang at debian.org</email></para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Goals</term>
+ <listitem><para>
+ <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>
+ </para></listitem>
+ </varlistentry>
+</variablelist>
+
+</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>Goals</term>
+ <listitem><para>
+ <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><para>To provide install-time options regarding the intended
+ purpose.</para></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>
+ </para></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>
Added: blends/trunk/blends/doc/docbook-xml/en/05_inside.xml
URL: http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/docbook-xml/en/05_inside.xml?rev=2414&op=file
==============================================================================
--- blends/trunk/blends/doc/docbook-xml/en/05_inside.xml (added)
+++ blends/trunk/blends/doc/docbook-xml/en/05_inside.xml Tue Oct 26 16:58:17 2010
@@ -1,0 +1,264 @@
+<chapter id="inside">
+ <title>Distributions inside Debian</title>
+
+ <sect1 id="fork">
+ <title>To fork or not to fork</title>
+
+<para>
+There are many distributions that decided to fork from a certain
+state of Debian. This is perfectly all right because Debian is
+completely free and everybody is allowed to do this. People who
+built those derived distributions had certain reasons to proceed
+this way.
+</para>
+
+ <sect2 id="commercialfork">
+ <title>Commercial forks</title>
+
+<para>
+If Debian should be used as the base for a commercial distribution
+like
+ <ulink url="http://www.linspire.com/" >Linspire</ulink> (formerly Lindows),
+ <ulink url="http://www.libranet.com/" >Libranet</ulink> or
+ <ulink url="http://www.xandros.com/" >Xandros</ulink>, there is no other
+choice than forking because these companies normally add some stuff
+that is non-free. While Debian Pure Blends might be interesting in
+technical terms for those commercial distributions by making it easier
+to build a separate distribution, these non-free additions are not
+allowed to be integrated into Debian, and thus integration into Debian
+is impossible.
+</para>
+ </sect2>
+
+ <sect2 id="noncommercialfork">
+ <title>Non-commercial forks</title>
+
+<para>
+As a completely free distribution Debian GNU/Linux is quite often a
+welcome starting point for derived distributions with a certain
+purpose that are as free as Debian but had certain reasons to fork.
+One main reason for a fork was that Debian was not flexible enough for
+certain purposes and some needed features had to be added. One reason
+for the Debian Pure Blends effort is to increase flexibility and to
+make the reason mentioned above void (if it is not yet void because of
+the general develoment of Debian). Some examples of forks from Debian
+that are probably now able to integrate back into Debian as a Debian
+Pure Blend are:
+
+<variablelist>
+ <varlistentry>
+ <term><ulink url="http://www.skolelinux.org" >SkoleLinux</ulink></term>
+ <listitem><para>Mentioning SkoleLinux in the category of forks is more or less
+ history. The merge back into Debian started with the
+ SkoleLinux people really doing a great job to enhance Debian
+ for their own purposes in the form of their work on
+ debian-installer, and culminated with the formal merging of
+ the Blend Debian Edu and SkoleLinux, so that they are now
+ virtually equivalent. This is the recommended way for derived
+ distributions, and the reasons for this recommendation are
+ given below.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>DeMuDi</term>
+ <listitem><para>The <ulink
+ url="http://www.agnula.org/">Agnula</ulink> project, which is founded by the
+ European Community, (and in fact is the first Free Software project
+ that was founded by the EU at all,) forked for the
+ following reasons:
+ <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>
+ This shows that there is no longer a real need for a fork, and
+ in fact, the organiser of the DeMuDi project was in contact to
+ start bringing DeMuDi back into Debian. That is why DeMuDi is
+ mentioned in the list of Debian Pure Blends above.
+ Unfortunately the effort to merge back has stalled but it
+ might be an interesting project to apply Blends techniques to
+ support multimedia experts who want to use Debian.
+ </para></listitem>
+</varlistentry>
+<varlistentry>
+ <term>LinEx</term>
+ <listitem><para>LinEx is the very successful distribution for schools in the
+ Region Extremadura in Spain. The work of the LinEx people
+ perhaps made Debian more popular than any other distribution.
+ The project was founded by the local government of
+ Extremadura, and each school in this region is running this
+ distribution. While this is a great success, the further
+ development of LinEx has to face the problems that will be
+ explained below. Because the creators of LinEx are aware of
+ this fact they started joining the educational part of LinEx
+ with Debian Edu which in turn leaded to an even stronger
+ position of this Blend.
+ </para></listitem>
+</varlistentry>
+</variablelist>
+</para>
+<para>
+If developers of a non-commercial fork consider integrating back into
+Debian in the form of a Debian Pure Blend, it might happen that their
+field is covered already by an existing Blend. For instance, this
+would be the case for LinEx, which has the same group of target users
+as Debian Edu as explained above. On the other hand, some special
+adaptations might be necessary to fit the requirements of the local
+educational system. The specific changes that might be necessary
+would be called <emphasis role="strong">flavours</emphasis> of a Blend.
+</para>
+ </sect2>
+
+ <sect2 id="disadvantages">
+ <title>Disadvantages of separate distribution</title>
+
+<para>
+In general, a separate distribution costs extra effort. Because it is
+hardly possible to hire enough developers who can double the great
+work of many volunteer Debian developers, this would be a bad idea for
+economical reasons. These people would have to deal with continuous
+changes to keep the base system, installer, etc. up to date with the
+current Debian development. It would be more sane to send patches that
+address their special requirements to Debian instead of
+maintaining a complete Debian tree containing these patches.
+</para>
+<para>
+Debian is well known for its strong focus on security. Security is
+mainly based on manpower and knowledge. So the best way to deal with
+security issues would be to base it on the Debian infrastructure,
+instead of inventing something new.
+</para>
+<para>
+New projects with special intentions often have trouble to become
+popular to the user group they want to address. This is a matter of
+attaining the critical mass that was explained in <xref linkend="general_problem" />.
+</para>
+<para>
+Larger Free Software projects need certain infrastructure like
+web servers, ftp servers, (both with mirrors,) a bug tracking system,
+etc. It takes a fair amount of extra effort to build an entire infrastructure
+that is already available for free in Debian.
+</para>
+<para>
+<emphasis role="strong">Forking would be a bad idea.</emphasis>
+</para>
+ </sect2>
+
+ <sect2 id="advantages">
+ <title>Advantages of integration into Debian</title>
+
+<para>
+Debian has a huge user base all over the world. Any project that is
+integrated within Debian has a good chance to become popular on the back
+of Debian if the target users of the project just notice that it
+enables them to solve their problems. So there is no
+need for extra research on the side of the users, and no need for
+advertising for a special distribution. This fact has been
+observed in the Debian Med project, which is well known for many
+people in medical care. It would not have gained this popularity if
+it had been separated from Debian.
+</para>
+<para>
+You get a secure and stable system without extra effort for free.
+</para>
+<para>
+Debian offers a sophisticated Bug Tracking System for free, which is a
+really important resource for development.
+</para>
+<para>
+There is a solid infrastructure of web servers, ftp servers with
+mirrors, mail servers, and an LDAP directory of developers with a strongly
+woven web of trust (through gpg key signing) for free.
+</para>
+</sect2>
+
+ <sect2>
+ <title>Enhancing Debian</title>
+
+<para>
+By making changes to some packages to make them fit the needs of a target
+user group, the overall quality of Debian can be enhanced. In this way,
+enhancing Debian by making it more user friendly is a good way for
+the community to give back something to Debian. It would be a shame
+if somebody would refuse all the advantages to keeping a project
+inside Debian, and instead would decide to try to cope with the disadvantages
+because he just does not know how to do it the right way, and that it is
+normally easy to propogate changes into Debian. For instance, see
+<xref linkend="howto_itp" />. This section explains how you can ask for
+a certain piece of software to be included in Debian.
+The next section describes the reason why Debian is flexible enough
+to be adapted to any purpose.
+</para>
+
+</sect2>
+</sect1>
+
+ <sect1>
+ <title>Adaptation to any purpose</title>
+
+<para>
+Debian is developed by about 1000 volunteers. Within this large group,
+the developers are encouraged to care for their own interests in packages
+they have chosen to look after. Thus, Debian is not bound to commercial
+interests.
+</para>
+<para>
+Those who might fear this amount of freedom given to every single developer
+should realize that there are very strict rules, as laid out in
+<ulink url="http://www.debian.org/doc/debian-policy/">Debian's policy</ulink>,
+which glue everything together. To keep their packages in each new
+release, every developer must ensure that their packages abide by that policy.
+</para>
+<para>
+One common interest each individual developer shares is to make the
+best operating system for himself. This way, people with similar
+interests and tasks profit from the work of single developers. If
+users, in turn, work together with the developers by sending patches or
+bug reports for further enhancement, Debian can be improved also for
+special tasks.
+</para>
+<para>
+For instance, developers may have children, or may work in some
+special fields of work, and so they try to make the best system for
+their own needs. For children, they contribute to Debian Jr. or
+Debian Edu. For their field of work, they contribute to the
+appropriate Blend: Debian Med, Debian Science, and so forth.
+</para>
+<para>
+In contrast to employees of companies, every single Debian developer
+has the freedom and ability to realize his vision. He is not bound to
+decisions of the management of his company. Commercial distributors
+have to aim their distributions at gaining a big market share. The
+commercial possibilities in targeting children's PCs at home are
+slight, so distributions comparable to Debian Junior are not attractive
+for commercial distributors to make.
+</para>
+<para>
+Thus, single developers have influence on development - they just have
+to <emphasis role="strong">do</emphasis> it, which is a very different position compared
+with employees of a commercial distributor. This is the reason for the
+flexibility of Debian that makes it adaptable for any purpose. In
+the Debian world, this kind of community is called
+"<emphasis><emphasis role="strong">Do</emphasis>ocracy</emphasis>" - the one who does, rules.
+</para>
+ </sect1>
+
+</chapter>
+
+
Added: blends/trunk/blends/doc/docbook-xml/en/06_technology.xml
URL: http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/docbook-xml/en/06_technology.xml?rev=2414&op=file
==============================================================================
--- blends/trunk/blends/doc/docbook-xml/en/06_technology.xml (added)
+++ blends/trunk/blends/doc/docbook-xml/en/06_technology.xml Tue Oct 26 16:58:17 2010
@@ -1,0 +1,901 @@
+<chapter id="technology">
+ <title>Technology</title>
+
+ <sect1 id="metapackages">
+ <title>Metapackages</title>
+
+ <sect2 id="defmetapackages">
+ <title>Metapackage definition</title>
+
+<para>
+A metapackage, as used by Blends, is a Debian package that contains:
+<itemizedlist>
+ <listitem><para>Dependencies on other Debian packages (essential)
+ <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>
+ </para></listitem>
+ <listitem><para>Menu entries (recommended)
+ <itemizedlist>
+ <listitem><para>Place these in <filename>/etc/blends/<varname><blend></varname>/menu/<varname><pkg-name></varname></filename></para></listitem>
+ <listitem><para>Maintain these via role based tools</para></listitem>
+ </itemizedlist>
+ </para></listitem>
+ <listitem><para>Configuration stuff (optional)
+ <itemizedlist>
+ <listitem><para><command>debconf</command> questions or pre-seeding</para></listitem>
+ <listitem><para><command>cfengine</command> scripts (or similar see <xref linkend="EnhancingTechnology" />)</para></listitem>
+ </itemizedlist>
+ </para></listitem>
+ <listitem><para>Special metapackages:
+ <itemizedlist>
+ <listitem><para><package><replaceable><blend></replaceable>-tasks</package>:
+ Contains information for <command>tasksel</command></para></listitem>
+ <listitem><para><package><replaceable><blend></replaceable>-config</package>:
+ Special configurations, basic stuff for user menus</para></listitem>
+ </itemizedlist>
+ </para></listitem>
+</itemizedlist>
+</para>
+<para>
+Metapackages are small packages with nearly no contents. The main
+feature of this type of package is its dependencies on other
+packages. The naming of metapackages follows the pattern
+<varname><blend></varname>-<varname><task></varname>
+where <varname><blend></varname> stands for the short name of a Debian
+Pure Blend, e.g. <package>junior</package> for Debian
+Jr. or <package>med</package> for Debian Med,
+and <varname><task></varname> means the certain task inside the Blend,
+e.g. puzzle or bio.
+</para>
+<para>
+Examples:
+<variablelist>
+ <varlistentry>
+ <term><package>junior-puzzle</package></term>
+ <listitem><para>Debian Jr. Puzzles</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><package>education-tasks</package></term>
+ <listitem><para>Tasksel files for SkoleLinux systems</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><package>med-bio</package></term>
+ <listitem><para>Debian Med micro-biology packages</para></listitem>
+ </varlistentry>
+</variablelist>
+</para>
+</sect2>
+
+ <sect2 id="collection">
+ <title>Collection of specific software</title>
+
+<para>
+When using metapackages, no research for available software inside Debian is
+necessary. It would not be acceptable for normal users to have to browse the
+descriptions of the whole list of the 20000 packages in Debian to find
+everything they need. So, metapackages are an easy method to help users to
+find the packages that are interesting for their work quickly.
+</para>
+<para>
+If the author of a metapackage includes several packages with similar
+functionality, an easy comparison between software covering the same task is
+possible.
+</para>
+<!-- This is not true any more since we turn Depends into Recommends
+ to explicitely *enable* users to remove certain packages.
+
+Moreover, the installation of a metapackage ensures that no package
+that is necessary for the intended task can be removed without
+explicit notice that also the metapackage has to be removed. This
+helps non specialist administrators to keep the installation fit for
+the specialized users.
+ -->
+<para>
+By defining conflicts with some other packages inside the metapackage,
+it is possible to ensure that a package that might conflict for some
+reasons for the intended task can not be installed at the same time as
+the metapackage is installed.
+</para>
+<para>
+All in all, metapackages enable an easy installation from scratch, and
+keep the effort required for administration low.
+</para>
+</sect2>
+ <sect2 id="categorisation">
+ <title>Packages showing up in more than one metapackage</title>
+
+<para>
+This seems to be an FAQ: If a package <package>A</package> is in the list of
+dependencies of metapackage <package>m</package> is it allowed or reasonable to
+add it to the list of dependencies of metapackage <package>n</package>?
+</para>
+<para>
+The answer is: Why not?
+</para>
+<para>
+The "overlap" is no problem because we do not want to build
+an exclusive categorisation which might be hard to understand for our
+users. Metapackages are like "normal" packages: Nobody
+would assume that because package <package>x</package> depends from package
+<package>libc</package> no other package is allowed to add <package>libc</package> to its
+depends. So why not adding a dependency to more than one metapackage if
+it is just useful for a certain task?
+</para>
+<para>
+The important thing is to support our users. A specific user wants to
+solve a certain task (and thus installs a certain metapackage). The
+question whether some Dependencies are also mentioned in a different
+metapackage is completely useless for this task. So in fact we do
+<emphasis role="strong">not</emphasis> build a categorisation tree but build pools of useful
+software for certain tasks which can definitely have overlaps.
+</para>
+<para>
+To give a certain example which was asked by a member of Debian
+Multimedia team: A user who is seeking for his optimal sound player is
+not served best if we "hide" an application from his view by
+including it into sound recorders exclusively. While chances might be
+good that a sound recorder is not as lightweight as a pure player the
+user will find out this quickly if he is looking for only a
+lightweight player - but perhaps he becomes happy later about the
+"added value" of his favourite player if it also is able to record
+sound.
+</para>
+
+ </sect2>
+
+ <sect2 id="configuration">
+ <title>Adapted configuration inside metapackages</title>
+
+<para>
+Besides the simplification of installing relevant packages by
+dependencies inside metapackages, these packages might contain special
+configuration for the intended task. This might either be
+accomplished by pre-seeding <command>debconf</command> questions, or by
+modifying configuration files in a <command>postinst</command> 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
+<command>postinst</command> script takes over the role of a local
+administrator.
+<!-- FIXME:
+ An improved version of the pre-seeding scripts are included in newer
+ debconf versions. I just replaced the debian-edu scripts with the
+ scripts from debconf. Look at debconf-set-selections and
+ debconf-get-selections.
+ -->
+</para>
+
+ </sect2>
+
+ <sect2 id="documentation">
+ <title>Documentation packages</title>
+
+<para>
+A "traditional" weakness of Free Software projects is missing
+documentation. To fix this, Debian Pure Blends try to provide
+relevant documentation to help users to solve their problems. This
+can be done by building <package>*-doc</package> packages of existing
+documentation, and by writing extra documentation, like manpages, etc.
+By supplying documentation, Debian Pure Blends fulfil their role in
+addressing the needs of specialised users, who have a great need for
+good documentation in their native language.
+</para>
+<para>
+Thus, translation is a very important thing to make programs more
+useful for the target user group. Debian has established
+a <ulink url="http://ddtp.debian.net/" >Debian Description
+Translation Project</ulink>, which has the goal to translate package
+descriptions. There is a good chance this system could also be used
+for other types of documentation, which might be a great help for
+Debian Pure Blends.
+</para>
+
+ </sect2>
+ </sect1>
+
+ <sect1 id="mp_handling">
+ <title>Handling of metapackages</title>
+
+<para>
+<!-- [BA] I think we need to qualify what 'handle' means, because there
+ certainly are other tools that 'handle' them (e.g. synaptic) if that term
+ is taken in its broadest sense.
+ [AT] ACK, here that we have to define 'handle'. The term
+ 'nicely' was intended to be the keyword because metapackages are
+ currently handled as any other package which is fine, but no help
+ for users who do not know anything about metapackages. We need
+ special tools to gain all profits we could have. Could you set
+ this into good English???
+ -->
+In short, there are no special tools available to handle metapackages
+nicely. But there are some tricks that might help, for the moment.
+</para>
+
+ <sect2 id="cmdline">
+ <title>Command line tools</title>
+
+<para>
+<variablelist>
+ <varlistentry>
+ <term><command>apt-cache</command></term>
+ <listitem><para>
+ The program <command>apt-cache</command> is useful to search for
+ relevant keywords in package descriptions. With it, you could search
+ for a certain keyword connected to your topic (for instance
+ "<package>med</package>") and combine it reasonably with <command>grep</command>:
+ <programlisting language="shell">
+<![CDATA[
+~> apt-cache search med | grep '^med-'
+med-bio - Debian Med micro-biology packages
+med-bio-dev - Debian Med micro-biology development packages
+med-doc - Debian Med documentation packages
+med-imaging - Debian Med imaging packages
+med-imaging-dev - Debian Med packages for medical image develop...
+med-tools - Debian Med several tools
+med-common - Debian Med Project common package
+med-cms - Debian Med content management systems
+]]>
+ </programlisting>
+ This is <emphasis role="strong">not really straightforward</emphasis>, and
+ absolutely unacceptable for end users.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><command>grep-dctrl</command></term>
+ <listitem><para>
+ The program <command>grep-dctrl</command> is a grep for Debian package
+ information, which is helpful for extracting specific package details
+ matching certain patterns:
+ <programlisting language="shell">
+<![CDATA[
+~> grep-dctrl ': med-' /var/lib/dpkg/available | \
+ grep -v '^[SIMAVF]' | \
+ grep -v '^Pri'
+Package: med-imaging
+Depends: paul, ctsim, ctn, minc-tools, medcon, xmedcon, med-common
+Description: Debian Med imaging packages
+
+Package: med-bio
+Depends: bioperl, blast2, bugsx, fastdnaml, fastlink, garlic...
+Description: Debian Med micro-biology packages
+
+Package: med-common
+Depends: adduser, debconf (>= 0.5), menu
+Description: Debian Med Project common package
+
+Package: med-tools
+Depends: mencal, med-common
+Description: Debian Med several tools
+
+Package: med-doc
+Depends: doc-linux-html | doc-linux-text, resmed-doc, med-co...
+Description: Debian Med documentation packages
+
+Package: med-cms
+Depends: zope-zms
+Description: Debian Med content management systems
+
+Package: med-imaging-dev
+Depends: libgtkimreg-dev, ctn-dev, libminc0-dev, libmdc2-dev...
+Description: Debian Med packages for medical image development
+
+Package: med-bio-contrib
+Depends: clustalw | clustalw-mpi, clustalx, molphy, phylip, ...
+Description: Debian Med micro-biology packages (contrib and ...
+]]>
+ </programlisting>
+ This is, like the <command>apt-cache</command> example, <emphasis role="strong">also
+ a bit cryptic</emphasis>, and again is not acceptable for end users.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><command>auto-apt</command></term>
+ <listitem><para>
+ The program <command>auto-apt</command> 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
+ <command>auto-apt</command> in the following manner to guarantee that you
+ have all of the files or programs you need:
+ <programlisting language="shell">
+<![CDATA[
+~> sudo auto-apt update
+put: 880730 files, 1074158 entries
+put: 903018 files, 1101981 entries
+~> auto-apt -x -y run
+Entering auto-apt mode: /bin/bash
+Exit the command to leave auto-apt mode.
+bash-2.05b$ less /usr/share/doc/med-bio/copyright
+Reading Package Lists... Done
+Building Dependency Tree... Done
+The following extra packages will be installed:
+ bugsx fastlink readseq
+The following NEW packages will be installed:
+ bugsx fastlink med-bio readseq
+0 packages upgraded, 4 newly installed, 0 to remove and 183 ...
+Need to get 0B/1263kB of archives. After unpacking 2008kB wi...
+Reading changelogs... Done
+Selecting previously deselected package bugsx.
+(Reading database ... 133094 files and directories currently...
+Unpacking bugsx (from .../b/bugsx/bugsx_1.08-6_i386.deb) ...
+Selecting previously deselected package fastlink.
+Unpacking fastlink (from .../fastlink_4.1P-fix81-2_i386.deb) ...
+Selecting previously deselected package med-bio.
+Unpacking med-bio (from .../med-bio_0.4-1_all.deb) ...
+Setting up bugsx (1.08-6) ...
+
+Setting up fastlink (4.1P-fix81-2) ...
+
+Setting up med-bio (0.4-1) ...
+
+localepurge: checking for new locale files ...
+localepurge: processing locale files ...
+localepurge: processing man pages ...
+This package is Copyright 2002 by Andreas Tille <tille at debian.org>
+
+This software is licensed under the GPL.
+
+On Debian systems, the GPL can be found at /usr/share/common-...
+/usr/share/doc/med-bio/copyright
+]]>
+ </programlisting>
+ Just do your normal business - in the above example, <command>less
+ /usr/share/doc/med-bio/copyright</command> - and if the necessary
+ package is not yet installed, <command>auto-apt</command> will care for
+ the installation and proceed with your command. While this is
+ really cool, this is <emphasis role="strong">not really intended for a production
+ machine</emphasis>.
+ </para></listitem>
+ </varlistentry>
+</variablelist>
+
+The short conclusion here is: <emphasis role="strong">There are no sophisticated tools
+that might be helpful to handle metapackages as they are used in
+Debian Pure Blends - just some hacks using the powerful tools inside
+Debian.</emphasis>
+</para>
+
+ </sect2>
+
+ <sect2 id="text_ui">
+ <title>Text user interfaces</title>
+<para>
+<variablelist>
+ <varlistentry>
+ <term><command>tasksel</command></term>
+ <listitem>
+ <para>
+ The Debian task installer <command>Tasksel</command> is the first
+ interface for package selection that is presented to the user when
+ installing a new computer. The <varname>End-user</varname> section should
+ contain an entry for each Debian Pure Blend.
+ Unfortunately, there are some issues that prevent Blends
+ from being included in the <command>tasksel</command> list,
+ because the dependencies of this task can affect what appears on
+ the first installation CD. This problem would be even greater if
+ all Blends were added, and so a different solution has
+ to be found here. (See <ulink url="http://bugs.debian.org/186085"
+ >#186085</ulink>.) In principle, <command>tasksel</command> is a good
+ tool for easy installation of Blends.
+ </para>
+ <para>
+ As a workaround for this problem the <command>blends-dev</command>
+ framework creates a package <package>BLEND-tasks</package> which contains
+ a <command>tasksel</command> control file. If you install this package
+ all tasks of the Blend will be added to the default list of tasks
+ inside <command>tasksel</command>. So a solution for Blend specific
+ installation media might be to just remove the default tasksel
+ list and provide the Blends own tasks exclusively.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><command>aptitude</command></term>
+ <listitem><para>
+ This is a better replacement for <command>dselect</command>, and has
+ some useful support for searching for and grouping of packages.
+ While this is not bad, it was not intended for the purpose of
+ handling Debian Pure Blends, and thus there could be some better
+ support to handle metapackages more cleverly.
+ </para></listitem>
+ </varlistentry>
+</variablelist>
+Short conclusion: <emphasis role="strong">There is a good chance metapackages could be
+handled nicely by the text based Debian package administration tools,
+but this is not yet implemented.</emphasis>
+</para>
+
+ </sect2>
+
+ <sect2 id="gui">
+ <title>Graphical user interfaces</title>
+<para>
+Debian <emphasis>Woody</emphasis> does not contain a really nice graphical
+user interface for the Debian package management system. But the
+efforts to support users with an easy to use tool have increased, and
+so there there will be some usable options in Sarge.
+<variablelist>
+ <varlistentry>
+ <term><command>gnome-apt</command></term>
+ <listitem><para>This is the native GNOME flavour of graphical user interfaces
+ to apt. It has a nice <command>Search</command> 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 "<varname>junior-*</varname>" will show
+ up all related packages including their descriptions. This
+ will give a reasonable overview about metapackages of the
+ project.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><command>synaptic</command></term>
+ <listitem><para>Even more sophisticated and perhaps the best choice for users
+ of Debian Pure Blends. <command>Synaptic</command> has a nice
+ filter feature, which makes it a great tool here.
+ Moreover <command>synaptic</command> is currently the only user
+ interface that supports Debian Package Tags
+ (see <xref linkend="debtags" />).
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><command>kpackage</command></term>
+ <listitem><para>This is the user interface of choice for KDE lovers.
+ Regarding its features (with exception of Debian Package Tags)
+ it is similar to both above.
+ </para></listitem>
+ </varlistentry>
+</variablelist>
+Short conclusion: <emphasis role="strong">As well as the text based user interfaces
+these tools are quite usable but need enhancements to be regarded as
+powerful tools for Debian Pure Blends.</emphasis>
+</para>
+ </sect2>
+
+ <sect2 id="web_if">
+ <title>Web interfaces</title>
+
+<para>
+<variablelist>
+ <varlistentry>
+ <term>Tasks pages</term>
+ <listitem><para>
+ The tasks pages probably provide the best overview about
+ the actual work which is done in a Debian Pure Blend. These
+ pages are automatically generated by reading the tasks files
+ (see <xref linkend="debian_control" />) and verifying the existence
+ of the packages that are mentioned as dependencies. On the
+ resulting web page the packages are listed with some meta
+ information and the description of the package. As user
+ oriented pages they are translated into more than 10
+ languages while translated means, the navigation text of the
+ page generating code is using <command>gettext</command> which
+ enables translation (the work is not yet completely done for
+ all languages) but even more importantly the descriptions of
+ the packages are translated as well by using the information
+ from
+ <ulink url="http://ddtp.debian.net/" >Debian Description
+ Translation Project</ulink>.
+ </para>
+ <para>These tasks pages are available via
+ <command>
+ http://blends.alioth.debian.org/BLEND/tasks
+ </command>
+ where <varname>BLEND</varname> has to be replaced by the name of the
+ Blend. Currently these pages are available for the Blends:
+ <command>
+ accessibility, edu, gis, junior, lex, science, debichem
+ </command>
+ The tasks pages are available for Debian Med as well but for
+ historical reasons the URL for these pages is
+ <command>
+ http://debian-med.alioth.debian.org/tasks
+ </command>
+ In short: If you want to know more about a specific Blend
+ go to its task page and have a look what is listed there.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Bugs pages</term>
+ <listitem><para>The more developer oriented bugs pages try to match the
+ scope of the tasks pages mentioned above but there is no
+ description of the packages given but rather the bugs that
+ are reported in the Debian Bug Tracking System (BTS) are
+ listed there. This is a quite valuable source of information
+ if somebody is interested in increasing the quality of a
+ Blend: Fixing bugs is always welcome and listing all relevant
+ bugs at a single place is a nice way to detect problems
+ quickly.
+ </para>
+ <para>These bugs pages are available via
+ <programlisting language="shell">
+ http://blends.alioth.debian.org/BLEND/bugs
+ </programlisting>
+ where <varname>BLEND</varname> has to be replaced by the name of the
+ Blend. Currently these pages are available for the Blends:
+ <programlisting language="shell">
+ accessibility, edu, gis, junior, lex, science, debichem
+ </programlisting>
+ The bugs pages are available for Debian Med as well but for
+ historical reasons the URL for these pages is
+ <programlisting language="shell">
+ http://debian-med.alioth.debian.org/bugs
+ </programlisting>
+ In short: If you want to help enhancing the quality of a
+ specific Blend go to its bug page and start working on the
+ bugs listed there.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><ulink url="http://packages.debian.org/" >Web search</ulink></term>
+ <listitem><para>Debian has a web interface that can be used to search for certain substrings
+ in package names. For instance if you are searching the meta
+ packages of Debian Med you could point your favourite Browser
+ to</para>
+ <para>
+<!-- FIXME: & is sometimes broken!!!
+<ulink url="http://packages.debian.org/cgi-bin/search_packages.pl?keywords=med-&subword=1">
+ ^^^^^
+-->
+<ulink url="http://packages.debian.org/cgi-bin/search_packages.pl?keywords=med-&subword=1">http://packages.debian.org/cgi-bin/search_packages.pl?keywords=med-&subword=1</ulink>
+ As a result you will get a list of all Debian Med packages.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><ulink url="http://qa.debian.org/developer.php" >Package Tracking System</ulink></term>
+ <listitem><para>
+ The Package Tracking System is a really great tool that
+ provides essential information about packages. Most Debian
+ Pure Blends are using a mailing list address as Maintainer of
+ their key packages which includes the metapackages. This so
+ called team maintenance of packages is on one hand very handy
+ from a developers point of view on the other hand it enables
+ using the Package Tracking System to get a quick overview:
+ <variablelist>
+ <varlistentry>
+ <term>Debian Jr:</term>
+ <listitem><para>
+ <ulink url="http://qa.debian.org/developer.php?login=debian-jr@lists.debian.org">http://qa.debian.org/developer.php?login=debian-jr@lists.debian.org</ulink>
+ </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">http://qa.debian.org/developer.php?login=debian-med-packaging@lists.alioth.debian.org</ulink>
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Debian Edu:</term>
+ <listitem><para>
+ <ulink url="http://qa.debian.org/developer.php?login=debian-edu@lists.debian.org">http://qa.debian.org/developer.php?login=debian-edu@lists.debian.org</ulink>
+ </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">http://qa.debian.org/developer.php?login=debian-science-maintainers@lists.alioth.debian.org</ulink>
+ </para></listitem>
+ </varlistentry>
+ </variablelist>
+ Hint: If you append the option <command>&ordering=3</command> you
+ might get some sectioning of this page according to the
+ metapackage categories. This result is approached by a tool
+ which subscribes all dependent packages to the group
+ maintenance address and adds a section according to a
+ metapackage name.
+ </para>
+ <para>
+ The other way to use the Package Tracking System is to search
+ for packages starting with a certain letter:
+ <variablelist>
+ <varlistentry>
+ <term>Debian Jr:</term>
+ <listitem><para>
+ <ulink url="http://packages.qa.debian.org/j">
+ http://packages.qa.debian.org/j
+ </ulink>
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Debian Med:</term>
+ <listitem><para>
+ <ulink url="http://packages.qa.debian.org/m">
+ http://packages.qa.debian.org/m
+ </ulink>
+ </para></listitem>
+ </varlistentry>
+ </variablelist>
+ But the list that is obtained by this method is much larger
+ than it would be useful for a good overview.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><command>list-junior.sh</command></term>
+ <listitem><para>The package <package>junior-doc</package> contains a script
+ <filename>/usr/share/doc/junior-doc/examples/scripts/list-junior.sh</filename>
+ that checks for the installed packages of a Blend and builds
+ a simple web page describing these packages. (The BTS
+ contains a patch to let this script work also for other
+ Blends.)
+ </para></listitem>
+ </varlistentry>
+</variablelist>
+Short conclusion: <emphasis role="strong">The Debian Pure Blends provide some nice web
+ tools for a whole set of packages for a certain working field that
+ provide a better overview than the usual Debian tools that are
+ basically dealing with single packages..</emphasis>
+</para>
+ </sect2>
+
+ <sect2 id="future_handling">
+ <title>Future handling of metapackages</title>
+
+<para>
+Obviously there are no nifty tools as you might know them from Debian
+available yet. The user interfaces for <command>apt-get</command> have to be
+enhanced drastically to make them easy enough to make them useful in
+the hands of an end user. This might implicitly mean that we need
+some additional control fields in <package>dpkg</package> to implement
+reasonable functionality. The following items are target of future
+development:
+<itemizedlist>
+ <listitem><para>Searching for existing metapackages</para></listitem>
+ <listitem><para>Overview about dependencies of these metapackages</para></listitem>
+ <listitem><para>Enhancing tools like <command>aptitude</command>,
+ <command>synaptic</command>, etc.</para></listitem>
+ <listitem><para>Special <command>tasksel</command> section</para></listitem>
+ <listitem><para>Web tools that keep metapackage information up to
+ date</para></listitem>
+</itemizedlist>
+</para>
+<para>
+Furthermore it is necessary to find a set of keywords for each Debian
+Pure Blend and write a tool to search these keywords comfortable. The
+best way to accomplish this might be to make use of Debian Package
+Tags, which is a quite promising technique.
+</para>
+<para>
+Tools that grep the apt cache directly for metapackages have to be
+written or rather the available tools for this should be patched for
+this actual functionality.
+</para>
+ </sect2>
+ </sect1>
+
+ <sect1 id="userroles">
+ <title>User roles</title>
+
+<para>
+As stated above specialists have only interest in a subset of the
+available software on the system they are using. In an ideal world, this
+would be the only software that is presented in the menu. This would
+allow the user to concentrate on his real world tasks instead of
+browsing large menu trees with entries he does not understand.
+</para>
+<para>
+To accomplish this, a technique has to be implemented that allows to
+define a set of users who get a task-specific menu while getting rid
+of the part of software they are not interested in. Moreover this has
+to be implemented for certain groups of users of one Blend, which are
+called "roles". There are several techniques available to manage user
+roles. Currently in the field of Debian Pure Blends a UNIX group
+based role system is implemented. This means, that a user who belongs
+to a certain group of a Blend is mentioned in
+the <filename>/etc/group</filename> file in the appropriate group and gets a
+special user menu that is provided for exactly this group.
+</para>
+<para>
+Strictly speaking it is not the best solution to conflate a
+configuration mechanism, which users see with menus, with access
+control, i.e. unix groups. It might be confusing, and wastes the limited
+number of groups to which a user can belong. On the other hand this
+is a solution that works for the moment, and has no real negative
+impact on the general use of the system. The benefit of using unix
+groups is that there is a defined set of tools provided to handle user
+groups. This makes life much easier; there is no
+<emphasis>practical</emphasis> limit to the number of groups to which a user may
+belong for the existing Debian Pure Blends at this time.
+</para>
+<para>
+In the long run, this role system might even be enhanced to certain
+"<emphasis>levels</emphasis>" a user can have and here the UNIX groups approach
+will definitely fail and has to be replaced by other mechanisms. This
+will include the possibility to enable the user adjust his own level
+("novice", "intermediate", "expert") while only the administrator is
+able to access the UNIX groups. On the other hand such kind of user
+level maintenance is not only a topic for Debian Pure Blends but might
+be interesting for Debian in general.
+</para>
+<para>
+Another point that speaks against using UNIX groups for role
+administration is the fact that local administrators are not in all
+cases competent enough to understand the UNIX role concept as a
+security feature and thus a real role concept including tools to
+maintain roles are needed in the future.
+</para>
+<para>
+The handling of the user menus according to the groups is implemented
+in a flexible plugin system and other ways of handling groups
+(i.e. LDAP) should be easy to implement.
+</para>
+
+ <sect2 id="menu_tools">
+ <title>User menu tools</title>
+
+ <sect3 id="user-menus">
+ <title>Using the Debian menu system</title>
+<para>
+The Debian menu system cares for menu updates after each package
+installation. To enable compliance with the <emphasis>role</emphasis> based menu
+approach it is necessary to rebuild the user menu after each package
+installation or after adding new users to the intended role. This can
+be done by using the
+<citerefentry><refentrytitle>blend-update-menus</refentrytitle>
+<manvolnum>8</manvolnum></citerefentry>
+(see <xref linkend="blend-update-menus" />) script from
+<package>blends-common</package>. It has to be said that using
+<command>blend-update-menus</command> is not enough to change the menu of a
+user. To accomplish this a call of the general
+<command>update-menu</command> script for every single user of a Blend is
+necessary if this is not done by the
+<filename>postinst</filename> script of a metapackage. This can easily been
+done if the configuration file of a Debian Pure Blend
+<filename>/etc/blends/<varname><blend></varname>/<varname><blend></varname>.conf</filename> contains the
+line
+<programlisting language="shell">
+<![CDATA[
+ UPDATEUSERMENU=yes
+]]>
+</programlisting>
+
+</para>
+<para>
+It is strongly suggested to use the
+package <package>blends-dev</package> to build metapackages of a
+Debian Pure Blend that will move all necessary files right into place
+if there exists a
+<filename>menu</filename> directory with the menu entries. Note, that the users
+<filename>${HOME}/.menu</filename> directory remains untouched.
+</para>
+ </sect3>
+
+ <sect3 id="user-debconf">
+ <title>Managing Debian Pure Blend users with <command>debconf</command></title>
+
+<para>
+Using <package>blends-dev</package> it is very easy to build a
+<varname>blend</varname><package>-config</package> package that contains
+<command>debconf</command> 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.
+
+ <programlisting language="shell">
+<![CDATA[
+~> dpkg-reconfigure med-common
+
+Configuring med-common
+----------------------
+
+Here is a list of all normal users of the system. Now you can select those users who
+should get a Debian Med user menu.
+
+ 1. auser (normal user A) 6. fmeduser (med user F)
+ 2. bmeduser (med user B) 7. glexuser (lex user G)
+ 3. cjruser (jr user C) 8. hmeduser (med user H)
+ 4. djruser (jr user D) 9. iadmin (administrator I)
+ 5. eadmin (administrator E) 10. juser (normal user J)
+
+(Enter the items you want to select, separated by spaces.)
+
+:-! Please specify the Debian Med users! 2 8
+]]>
+ </programlisting>
+This example shows the situation when you
+<command>dpkg-reconfigure</command> <package>med-common</package> if
+<varname>med user B</varname> and <varname>med user H</varname> were defined as users
+of Debian Med previously and <varname>med user F</varname> should be added to
+the group of medical staff. (For sure it is more convenient to use the
+more comfortable interfaces to <package>debconf</package> but the used
+SGML DTD <ulink url="http://bugs.debian.org/140684" >does not yet
+ support screen shots</ulink>.)
+</para>
+ </sect3>
+ </sect2>
+ </sect1>
+
+ <sect1 id="devtools">
+ <title>Development tools</title>
+
+<para>
+Building a metapackage is more or less equal for each meta
+package. This was the reason to build a common source package
+<package>blend</package> that builds into two binary packages
+<variablelist>
+ <varlistentry>
+ <term><package>blends-dev</package></term>
+ <listitem><para>Helpful tools to build metapackages from a set of template
+ files. These tools are interesting for people who want to
+ build metapackages in the style Debian Edu and Debian Med
+ are currently doing this. The purpose of this package is to
+ make maintenance of metapackages as easy as possible.</para>
+ <para>This package is described in detail in appendix <xref
+ linkend="blends-dev" />.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><package>blends-common</package></term>
+ <listitem><para>This package provides some files that are common to meta
+ packages of Debian Pure Blends especially those that were
+ built using the tools of the package
+ <package>blends-dev</package>. It introduces a method to handle
+ system users in a group named according to the name of the
+ Blend. The user menu approach is explained in detail
+ in <xref linkend="userroles" />.</para>
+ <para>This package is described in detail in appendix <xref
+ linkend="blends-common" />.
+ </para></listitem>
+ </varlistentry>
+</variablelist>
+The usage of the tools that are contained in these packages are
+described now in detail.
+</para>
+</sect1>
+ <sect1 id="othertools">
+ <title>Other interesting tools</title>
+
+ <sect2 id="simple-cdd">
+ <title>Simple-CDD</title>
+
+<para>
+The tool <command>simple-cdd</command> is a limited though relatively easy
+tool to create a customized debian-installer CD.
+</para><para>
+It includes simple mechanisms to create "profiles" that define common
+system configurations, which can be selected during system
+installation. <command>Simple-cdd</command> also makes it easy to build CDs
+with language and country settings pre-configured, or to use a 2.6
+kernel by default.
+</para><para>
+This can be used to create a crude "Debian Pure Blend" using
+packages from Debian, with pre-configuration of packages that use
+<command>debconf</command>. Custom configuration scripts can be specified
+to handle packages that don't support <command>debconf</command>
+pre-configuration.
+</para><para>
+Testing CD images with <command>qemu</command> is also made simple with a
+provided script.
+</para><para>
+It has only been tested with <command>debian-cd</command> from Etch (other
+than <command>debpartial-mirror</command>), so if using a new
+<command>debian-cd</command> or <command>debian-installer</command>, it may
+require some tweaks.
+</para>
+ </sect2>
+ </sect1>
+</chapter>
+
+
+
Added: blends/trunk/blends/doc/docbook-xml/en/07_starting.xml
URL: http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/docbook-xml/en/07_starting.xml?rev=2414&op=file
==============================================================================
--- blends/trunk/blends/doc/docbook-xml/en/07_starting.xml (added)
+++ blends/trunk/blends/doc/docbook-xml/en/07_starting.xml Tue Oct 26 16:58:17 2010
@@ -1,0 +1,417 @@
+<chapter id="starting">
+ <title>How to start a Debian Pure Blend</title>
+
+<para>
+This chapter is based on the Debian Subproject HOWTO, which was
+written by Ben Armstrong <email>synrg at debian.org</email>.
+</para>
+
+ <sect1 id="planning">
+ <title>Planning to form a Debian Pure Blend</title>
+
+ <para>
+ In this section, issues to think about before starting a Debian Pure
+ Blend will be discussed. It is important to have a clear idea where
+ to head and how to get there before launching into this adventure.
+ </para>
+
+ <sect2 id="leadership">
+ <title>Leadership</title>
+ <para>
+ The existing Debian Pure Blends have clearly shown that they depend
+ on a person who keeps things running. If anybody wants to start a
+ project at first, he has to answer the question:
+ <emphasis>"Am I the right person for the job?"</emphasis> Surely this is a
+ question that may be faced with some amount of uncertainty. The way
+ Debian Pure Blends started in the past was for the person with the
+ idea for the project to just start doing the work. After some time
+ using this approach, it became clear that if the project lacked a
+ person to take leadership, the project would become stale. So the
+ initiator has to answer the question clearly, whether or not he is
+ able to continue in the <emphasis>job</emphasis> of leader, considering the
+ amount of time he will have to spend, and the technical and social
+ skills which are needed.
+ </para>
+ </sect2>
+
+ <sect2 id="defining_scope">
+ <title>Defining the scope of the Blend</title>
+ <para>
+ It is as important to decide what your group is not going to do as
+ it is what it is going to do. A clear borderline is essential for
+ the development of the project. Without it, outsiders might
+ either expect more from the project than it can accomplish, or may ignore
+ the project, finding it not helpful because they are
+ not able to find out the purpose.
+ </para>
+ <para>
+ By maintaining a good relationship with other Free Software projects,
+ some common tasks can be done very effectively. When efforts can be
+ shared, the amount of work for each project can be reduced.
+ </para>
+ <para>
+ Checking for cooperation with other Debian Pure Blends is always a
+ good idea. In technical terms, this is obvious, but sometimes there
+ are possibilities to share efforts when the goals of two projects
+ have parts in common.
+ </para>
+ <para>
+ The one who decides to start a Debian Pure Blend takes on a
+ responsibility for this project. It has to be for the good of
+ Debian as a whole, and should bring an extra reputation to our
+ common goal to build the best operating system.
+ </para>
+ </sect2>
+
+ <sect2 id="initial_discussion">
+ <title>Initial discussion</title>
+ <para>
+ By the time you have begun to think about forming the subproject,
+ have made the commitment to lead it, and have sketched out a
+ bit of where you want to go and how you'll get there, you have
+ likely already done some informal discussion with your peers.
+ It is time, if you haven't already, to take these ideas to the
+ broader Debian developer community, opening discussion on the
+ creation of your group.
+ </para>
+
+ <sect3 id="calling_all_developers">
+ <title>Calling all developers</title>
+ <para>
+ At this stage, you will want to reach as broad an audience as possible.
+ You have carefully thought out what you're going to do, and are able
+ to articulate it to Debian as a whole. Let everyone know through
+ the <email>debian-devel-announce at lists.debian.org</email> mailing
+ list, setting the <command>Reply-to:
+ </command><email>debian-devel at lists.debian.org</email> and listen to what
+ everyone has to say about your idea. You may learn some valuable
+ things about pitfalls that may lie ahead for your group. Maybe even
+ show-stoppers at that. You may also find a number of like-minded
+ individuals who are willing to join your group and help get it
+ established.
+ </para>
+ </sect3>
+
+ <sect3 id="steering_the_discussion">
+ <title>Steering the discussion</title>
+ <para>
+ It's all too easy to get lost in ever-branching-out sub-threads at
+ this point. Many people will be firing off ideas left, right and
+ centre about what your group should do. Don't worry too much about
+ containing the discussion and keeping it on track with your main
+ idea. You would rather not squelch enthusiasm at this point. But
+ do try to steer the discussion a bit, focusing on the ideas that
+ are central to your subproject and not getting lost in the details.
+ </para>
+ <para>
+ At some point, you'll decide you've heard enough, and you're ready
+ to get down to the business of starting your group.
+ </para>
+ </sect3>
+
+ </sect2>
+
+</sect1>
+
+<sect1 id="setting_up">
+ <title>Setting up</title>
+
+<sect2>
+ <title>Mailing list</title>
+ <para>
+ It is fairly important to enable some means for communication for
+ the project. The most natural way to do this is with a mailing
+ list.
+ </para>
+ <para>
+ Creating a new mailing list starts with a wishlist bug against
+ <varname>lists.debian.org</varname>. The format of this
+ bug has to follow
+ <ulink url="http://www.debian.org/MailingLists/HOWTO_start_list"
+ >certain rules</ulink>.
+ </para>
+ <para>
+ Before your list can be created, the listmasters will want assurance
+ that creation of the list is, in fact, necessary. So for this
+ reason, don't wait for your list to be created. Start discussing
+ your new project on <email>debian-devel at lists.debian.org</email>
+ immediately. To help distinguish your project's posts from the
+ large amount of traffic on this list, tag them in the Subject field
+ with an agreed-upon tag. An example bug report to create the
+ relevant list is bug
+ <ulink url="http://bugs.debian.org/237017" >#237017</ulink>.
+ </para>
+ <para>
+ When sufficient discussion on the developer's list has
+ taken place and it is time to move it to a subproject list,
+ add to your wishlist bug report some URLs pointing to these
+ discussions in the archives as justification for creation of
+ your list.
+ </para>
+</sect2>
+
+<sect2>
+ <title>Web space</title>
+ <para>
+ A simple possibility, and one which is fairly attractive because it
+ facilitates collaborative web site creation and maintenance, is to
+ put a page on the <ulink url="http://wiki.debian.org">Wiki</ulink>.
+ There is a
+ special <ulink url="http://wiki.debian.org/index.cgi?DebianPureBlends"
+ >Wiki page for Debian Pure Blends</ulink>.
+ </para>
+ <para>
+ A good place to put static web pages or even PHP code is the common
+ place on Alioth for all
+ Blends: <ulink url="http://blends.alioth.debian.org">http://blends.alioth.debian.org</ulink>. There is a
+ subdirectory for each Blend and it is very easy to create a simple
+ index page there which points to the automatically generated web
+ pages which are mentioned in <xref linkend="web_if" />. Following this
+ strategy is quite cheap and has a big effect when using the tools
+ provided by the Debian Pure Blends effort.
+ </para>
+ <para>
+ Sooner or later a Debian Pure Blend will establish an own project at
+ <ulink url="http://alioth.debian.org" >alioth.debian.org</ulink>, since
+ this enables many features for group maintaining packages, create
+ mailing lists for different purposes, maintain a version control
+ system like SVN or Git etc. The Alioth project enables to provide
+ web sites as well and the Debian Med project is using this since a
+ long time.
+ </para>
+ <para>
+ Finally, the best way is to have a page
+ under <ulink url="http://www.debian.org/devel">http://www.debian.org/devel</ulink>. While not as
+ straightforward as any of the other options, this approach has its
+ advantages. First, the site is mirrored everywhere. Second, the
+ Debian web site translators translate pages into many different
+ languages, reaching new potential audiences for your Debian Pure
+ Blend, and improving communication with other members of your
+ project and interested parties for whom English is not their most
+ comfortable language. Third, a number of templates are available to
+ make your site more integrated with the main web site, and to assist
+ with incorporating some dynamic content into your site. Before you
+ join the Debian Web team you
+ should <ulink url="http://www.debian.org/devel/website" >http://www.debian.org/devel/website</ulink>learn
+ more about building Debian web pages.
+ </para>
+ <para>
+ Once this is done, the Debian web pages team should be contacted via
+ the mailing list <email>debian-www at lists.debian.org</email> to add the
+ project to the <ulink url="http://www.debian.org/intro/organization"
+ >organisation page</ulink>.
+ </para>
+</sect2>
+
+<sect2>
+ <title>Repository</title>
+ <para>
+ On <ulink url="http://alioth.debian.org/" >alioth.debian.org</ulink> a
+ <ulink url="http://gforge.org/" >Gforge</ulink>-site is running to host
+ all Debian related project work. Creating a project on Alioth is a
+ good idea to start teamwork on the code a Debian Pure Blend is
+ releasing.
+ </para>
+</sect2>
+
+<sect2>
+ <title>Formal announcement</title>
+ <para>
+ Once there is a list, or at least enough preliminary discussion on
+ debian-devel to get started, and there is some information about the
+ newly planned Debian Pure Blend available on the web, it is time to
+ send a formal announcement to
+ <email>debian-devel-announce at lists.debian.org</email>. The
+ announcement should include references to past discussions, any web
+ pages and code which might already exist, and summarise in a well thought
+ out manner what the project is setting out to achieve. Enlisting the
+ help of fellow developers on irc or in private email to look over
+ the draft and work out the final wording before it is sent out is
+ always a good idea.
+ </para>
+ <para>
+ Emails to <email>debian-devel-announce at lists.debian.org</email> have to
+ be signed by the GPG key of an official Debian developer. However, it
+ should not be a very hard task if somebody wants to support Debian
+ while not yet being a developer to find a developer who volunteers
+ to sign an announcement of a reasonable project. It might be
+ reasonable to send this announcement also to other relevant non-Debian
+ lists. If your announcement is well done, it will draw a number
+ of responses from many outsiders, and will attract people to Debian.
+ </para>
+</sect2>
+
+<sect2>
+ <title>Explaining the project</title>
+ <para>
+ Now the real work starts. People who are involved in the project
+ should be aware that they have to answer questions about the project
+ whenever they show up at conferences or at an exhibition booth. So
+ being prepared with some flyers or posters is always a good idea.
+ </para>
+</sect2>
+</sect1>
+
+<sect1 id="structure">
+ <title>Project structure</title>
+
+<sect2 id="subsetting_debian">
+ <title>Sub-setting Debian</title>
+ <para>
+ While there are a variety of different kinds of work to be done in
+ Debian, and not all of them follow this pattern, this document
+ describes one particular kind of project. Our discussion about
+ Debian Pure Blends concerns sub-setting Debian. A sub-setting
+ project aims to identify, expand, integrate, enhance, and maintain a
+ collection of packages suitable for a particular purpose by a
+ particular kind of user.
+ </para>
+ <para>
+ Now, strictly speaking, a subset of packages could be more general
+ than described above. A subset could be a broad category like
+ "audio applications" or "network applications". Or it could be more
+ specific, such as "web browsers" or "text editors". But what a
+ sub-setting project such as Debian Jr. aims to do is not focus on the
+ kind of package, but rather the kind of user. In the case of Debian
+ Jr. it is a young child.
+ </para>
+ <para>
+ The sort of user the project looks after, and which of the needs the
+ project hopes to address are defined by the project's goals.
+ <!-- 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. -->
+ Thus, Debian Jr. first had to decide which children the project
+ would reach: "What age?" "English speaking children only, or
+ other languages as well?" Then the project had to determine
+ how and where they would be using Debian: "At home?" "In school?"
+ "Playing games?" "On their own systems?" "On their parents' systems?"
+ </para>
+ <para>
+ The answers to all of these questions are not straightforward. It is
+ very much up to the project to choose some arbitrary limits for the
+ scope of their work. Choose too broad a focus, or one which duplicates
+ work already done elsewhere, and the energy of the project dissipates,
+ making the project ineffective. Choose too narrow a focus and the
+ project ends up being marginal, lacking the critical mass necessary
+ to sustain itself.
+ </para>
+ <para>
+ A good example was the request to split the microbiology
+ related packages out of Debian Med into a Debian Bio project. This
+ is reasonable in principle, and should really be done. In fact, the
+ initiator of Debian Med would support this idea. So he gave the
+ answer: "Just start the Debian Bio project to take over all related
+ material. Until this happens, Debian Med will cover medical material
+ that deals with sequence analysis and so forth." Unfortunately,
+ there was silence from the Debian Bio proponents after this answer.
+ </para>
+ <para>
+ Of course, it sometimes turns out that you start working on a project
+ thinking you know what it is about, only to find out later that you
+ really had no idea what it would become until the user base has grown
+ beyond the small community of developers that started it. So, none of
+ the decisions you make about your project's scope at the beginning
+ should be taken as set in stone. On the other hand, it is your project,
+ and if you see it veering off in directions that are contrary to your
+ vision for it, by all means steer it back on course.
+ </para>
+</sect2>
+
+<sect2 id="tasksel">
+ <title>Using tasksel and metapackages</title>
+<para>
+ According to the plan of the project, the first metapackages (<xref
+ linkend="metapackages" />) should be developed. It is not always easy to
+ decide what should be included, and which metapackages should be
+ built. The best way to decide on this point is to discuss on the
+ mailing list some well thought out proposals.
+</para>
+<para>
+ Section <xref linkend="text_ui" /> mentions <command>tasksel</command> as a tool
+ to select a Debian Pure Blend, and explains why it is currently not
+ possible to get a Blend included into the task selection list.
+</para>
+ </sect2>
+
+</sect1>
+
+<sect1 id="first_release">
+ <title>First release</title>
+
+<sect2 id="release_announcement">
+ <title>Release announcement</title>
+ <para>
+ Beyond the release announcement for Debian itself, it is necessary
+ to put some thought and work into a release announcement for the
+ first release of a Debian Pure Blend. This will not only
+ be directed at the Debian developer community, but also at the users.
+ This will include potential new Debian users abroad, who may not be
+ on a Debian mailing list. Here, the same principle applies as for
+ the first announcement of the project: it is important to consider
+ sending the information to other relevant forums.
+ </para>
+</sect2>
+
+<sect2 id="users">
+ <title>Users of a Debian Pure Blend</title>
+ <para>
+ By this time, people have newly installed Debian along with the
+ material in the Blend, or have installed the metapackages on their
+ existing Debian systems. Now comes the fun part, building
+ relationships with the user community.
+ </para>
+
+<sect3 id="user_support">
+ <title>Devoting resources to the users</title>
+ <para>
+ Users are a mixed blessing. In the first development phase there are
+ some developers who are users, and some intrepid "early adopters."
+ But once it is released, the first version is "out there," and the
+ project will certainly attract all kinds of users who are not
+ necessarily as technically savvy as your small development user
+ community. Be prepared to spend some time with them. Be patient
+ with them. And be listening carefully for the underlying questions
+ beneath the surface questions. As draining as it can be to deal
+ with users, they are a very key component to keeping your
+ development effort vital.
+ </para>
+</sect3>
+
+<sect3 id="devel_vs_user_list">
+ <title>Developer vs. user mailing list</title>
+ <para>
+ Should a user list be created? It's not as cut-and-dried as it
+ might at first appear. When user help requests start coming in,
+ you might at first see them as a distraction from the development
+ effort. However, you don't necessarily want to "ghettoize" the
+ user community into a separate list early. That's a
+ recipe for developers to get out of touch very quickly with the
+ users. Tolerate the new user questions on the developer list
+ for a while. Once a user list is finally set up, courteously
+ redirect user questions to the user list. Treat your users as
+ the valuable resource about how your project is working "in the
+ field" that they are.
+ </para>
+</sect3>
+
+<sect3 id="user_support_beyond_debian">
+ <title>User support beyond Debian</title>
+ <para>
+ Fortunately, we're not in the business of supporting users alone.
+ Look beyond Debian for your allies in user support: Linux user
+ groups (LUGs) and the users themselves. Develop an awareness of who
+ has stakes in seeing your project succeed, and enlist their help
+ in getting a strong network of support established for your work.
+ </para>
+</sect3>
+
+</sect2>
+
+</sect1>
+
+</chapter>
+
+
Added: blends/trunk/blends/doc/docbook-xml/en/08_websentinel.xml
URL: http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/docbook-xml/en/08_websentinel.xml?rev=2414&op=file
==============================================================================
--- blends/trunk/blends/doc/docbook-xml/en/08_websentinel.xml (added)
+++ blends/trunk/blends/doc/docbook-xml/en/08_websentinel.xml Tue Oct 26 16:58:17 2010
@@ -1,0 +1,309 @@
+<chapter id="sentinel">
+ <title>The web sentinel</title>
+
+ <sect1 id="packageslist">
+ <title>Existing and prospective packages</title>
+
+<para>
+The so called tasks pages probably give the most interesting overview
+about what a Blend is actually doing for newcomers as well as a nice
+quality assurance tool for developers. If you want to see examples
+for tasks pages just have a look at the
+<ulink url="http://blends.alioth.debian.org/" >list of all Blends</ulink>
+using this technique and follow the links to the tasks pages once you
+selected one specific Blend.
+</para>
+<para>
+If a Debian Pure Blend should be presented one of the first questions
+is, what packages are available. The next question might be which
+packages are on the todo list for inclusion in Debian to make Debian
+even more attractive for people the Blend is targeting at. Both
+questions can be answered if you point people to the dynamically
+created tasks page. The page is rebuild daily to stay up to date
+according to recent developments of the Blend. The build process works
+as follows:
+ <itemizedlist>
+ <listitem><para>Read dependency information of the <filename>tasks</filename> files.</para></listitem>
+ <listitem><para>Verify whether there is really a package with this name and
+ print the description of this package.</para></listitem>
+ <listitem><para>If there is no such package in Debian try to parse
+ the <filename>tasks</filename> file whether there is some information
+ given and mark the result as prospective package for further
+ inclusion.</para></listitem>
+ </itemizedlist>
+</para>
+<para>
+The rationale behind this is to provide as much as possible
+information about packages that might be interesting for the target
+user of the Blend. Moreover the page can provide useful information for
+developers about things that might be a useful help for the project to
+work down the todo list and build Debian packages for software that is
+not yet included in Debian. To get the todo list builded it is
+necessary to add some additional information to the task files which
+are the main database of information for the Blend. The information is
+following the RFC822 syntax as all Debian control files do and is
+kept quite simple:
+<variablelist>
+ <varlistentry>
+ <term>Depends / Recommends / Suggests</term>
+ <listitem><para>Even if there is no Debian package available for the moment
+ the names of prospective packages are given as if they would
+ exists. The rationale behind is that once such a package
+ might exist the source of the metapackage does not have to
+ be changed and will work out of the box after rebuilding.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Ignore</term>
+ <listitem><para>The Ignore key should be the favourite way to use for
+ specifying prospective packages in case the packages should be
+ evaluated once it appears in the Debian package pool. If
+ "Depends", "Recommends" or "Suggests" are used for not yet
+ existing packages they will be turned into the list of Suggests
+ of the metapackage and thus might be possible to become
+ installed on a users machine if the user decides to install all
+ suggested packages. If some evaluation should be done first the
+ "Ignore" tag is your friend.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Homepage</term>
+ <listitem><para>This is the URL to the software that should be packaged.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>WNPP</term>
+ <listitem><para>In case there might be a WNPP bug filed for this software the
+ bug number is given here. This helps to keep track of the
+ ongoing effort to package the software.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Responsible</term>
+ <listitem><para>In case some developer claimed to care for the software
+ (perhaps by issuing the WNPP bug report) the e-mail address of
+ this developer is given here to enable an easy way to contact
+ this person.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>License</term>
+ <listitem><para>Debian cares always about the license. This information
+ about prospective packages should be easily available.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Vcs-Svn</term>
+ <listitem><para>If there is some Debian packaging stuff available this
+ can be addressed in this field. Unofficial packages which
+ have this field set are rendered in a separate section with
+ links to the packaging SVN.
+ </para><para>
+ The usage for this field is the same as it is described in
+ <ulink url="http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-vcs"
+ >paragraph 6.2.5 of Debian developers reference</ulink>
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Vcs-Git</term>
+ <listitem><para>If there is some Debian packaging stuff available this
+ can be addressed in this field. Unofficial packages which
+ have this field set are rendered in a separate section with
+ links to the packaging Git.
+ </para><para>
+ The usage for this field is the same as it is described in
+ <ulink url="http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-vcs"
+ >paragraph 6.2.5 of Debian developers reference</ulink>
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Vcs-Browser</term>
+ <listitem><para>If there is some Debian packaging stuff available this
+ can be addressed in this field. Unofficial packages which
+ have this field set are rendered in a separate section above
+ unofficial packages outside the official Debian mirrors.
+ If you have set <filename>Vcs-Svn</filename> or <filename>Vcs-Git</filename>
+ there is no need to set <filename>Vcs-Browser</filename> explicitely
+ because it is obtained automatically from the other fields.
+ But you might override this automatically generated URL if
+ needed.
+ </para><para>
+ The usage for this field is the same as it is described in
+ <ulink url="http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-vcs"
+ >paragraph 6.2.5 of Debian developers reference</ulink>
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Pkg-URL</term>
+ <listitem><para>In some cases there are unofficial packages for some software
+ which are prepared by a third party. It helps our users if
+ they could install such a package and thus the URL to it might
+ be a helpful hint. This is also true for developers because
+ they might have a look at this packaging before they start from
+ scratch. Often packages are available
+ at <ulink url="http://mentors.debian.net/"
+ >mentors.debian.net</ulink> and prepared by people who do not
+ yet have an official Debian maintainer status and thus are not
+ able to upload packages to the Debian mirror. The packages at
+ mentors are waiting for sponsoring of an official Debian
+ maintainer and if such a package shows up in the Blend tasks list
+ it might speed up the inclusion into official Debian
+ distribution.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Pkg-Description</term>
+ <listitem><para>This tag should give reasonable information about the
+ software as it normally is done in <filename>debian/control</filename>
+ files. It can be either a copy of the description of the WNPP
+ bug or could be used to file a WNPP bug and thus helps to
+ simplify the packaging work.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Remark</term>
+ <listitem><para>In some cases it makes perfectly sense to add a remark on
+ behalf of the Blends team to a package which is visible on the
+ tasks page. This can be done using the Remark field. It can
+ be used in the same syntax as a Description field in Debian
+ control files.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Registration</term>
+ <listitem><para>Sometimes, specifically in the case of scientific software,
+ the project authors ask for registration of their software to
+ get numbers of users of their software. These numbers enable
+ them to ask for further funding of their project. To support
+ this intend of authors the tasks pages can feature a link to
+ this registration page if the link is given in the tasks file
+ in the Registration field.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Published-*</term>
+ <listitem>
+ <para>Several scientific software asks users of the code to quote the
+ publication which was used to describe the algorithm.
+ There was a really long discussion on the
+ <ulink url="http://lists.debian.org/debian-science" >Mailing
+ list of Debian Science Blend</ulink>
+ (<ulink url="http://lists.debian.org/debian-science/2008/10/msg00033.html"
+ >see the start of the thread here</ulink>) how this might be
+ approached. There was some consensus that we need to define a
+ general control file featuring the citation information but the
+ problem has no real solution in the near future. To find an
+ intermediate solution which solves the situation for the tasks
+ pages of Blends some <varname>Published-*</varname> tags can be inserted
+ into the tasks file which are rendered on the according tasks
+ pages. Here comes a list of these tags:
+ </para>
+ <para>
+ <variablelist>
+ <varlistentry>
+ <term>Published-Authors</term>
+ <listitem><para>Authors of the publication. For consistency reasons it is
+ suggested to use <varname>Firstname1 Lastname1, Firstname2 Lastname2</varname>.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Published-Title</term>
+ <listitem><para>Title of the publication.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Published-URL</term>
+ <listitem><para>URL with online infos of the publication. The title will
+ feature a link to this URL - so please make sure there is a
+ Published-Title field if you specify Published-URL.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Published-In</term>
+ <listitem><para>Publication journal
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Published-Year</term>
+ <listitem><para>Publication year
+ </para></listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+ <para>Any suggestion to enhance these fields is welcome.
+ </para></listitem>
+</varlistentry>
+</variablelist>
+</para>
+
+ </sect1>
+
+ <sect1 id="ddtp">
+ <title>Debian Description Translation Project</title>
+
+<para>
+The <ulink url="http://ddtp.debian.net/" >Debian Description
+Translation Project</ulink> (see <xref linkend="documentation" />) provides users of
+non English languages with information about Debian packages. The
+sense of supporting especially the translations of descriptions which
+are in the focus of a Blend is to make the Blend even more usable for our
+target users. Moreover people interested in the special field of the
+Blend are most probably able to provide good translations if it comes to
+texts that are specific to their field of knowledge. Thus there is a
+web page automatically created that parses the tasks packages for
+package names and verifies the translation status of the package
+descriptions.
+</para>
+<para>
+Finally the DDTP descriptions can be used to create internationalised
+pages of existing packages which might help users with insufficient
+skills in English to easily find their software of interest.
+</para>
+
+ </sect1>
+
+ <sect1 id="bugs">
+ <title>Bugs overview</title>
+<para>
+The goal of a Blend is to support their user as best as possible. So a
+feature to have a quick overview about all packages in our focus might
+be helpful. This is solved by the bugs overview page. To create this
+page the <filename>tasks</filename> files are parsed for the listed
+dependencies. Then the Debian Bug Tracking System is consulted about
+known bugs of these packages. All bugs are listed and marked with
+different colours according to their severity. So the developers can
+easily check this page in case they plan to fix some bugs that are
+relevant for the Blend.
+</para>
+<para>
+If you want to see examples for those bugs pages just have a look at the
+<ulink url="http://blends.alioth.debian.org/" >list of all Blends</ulink>
+using this technique and follow the links to the bugs pages once you
+selected one specific Blend.
+</para>
+
+ </sect1>
+
+ <sect1 id="svnoverview">
+ <title>SVN overview</title>
+<para>
+This page gives a recent overview about the current development
+activities of the Blend developers.
+</para>
+ </sect1>
+
+ <sect1 id="qareport">
+ <title>Quality assurance report</title>
+
+<para>
+The Debian Quality Assurance group does a decent job in watching the
+status o f Debian packages. If a package features a
+valid <filename>debian/watch</filename> the tool <command>uscan</command> is able to
+verify the upstream source location for newer versions. The QA report
+page reports issues about the packages that are relevant for a Blend.
+</para>
+ </sect1>
+
+</chapter>
+
+
Added: blends/trunk/blends/doc/docbook-xml/en/09_todo.xml
URL: http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/docbook-xml/en/09_todo.xml?rev=2414&op=file
==============================================================================
--- blends/trunk/blends/doc/docbook-xml/en/09_todo.xml (added)
+++ blends/trunk/blends/doc/docbook-xml/en/09_todo.xml Tue Oct 26 16:58:17 2010
@@ -1,0 +1,469 @@
+<chapter id="todo">
+ <title>To do</title>
+
+ <sect1 id="communication">
+ <title>Establishing and using communication platforms</title>
+
+<para>
+Each Debian Pure Blend has an own mailing list for discussion of
+specific development issues. Because there are several common issues
+between all Blends also a common mailing list was created. People who
+are interested in working on common issues like building metapackages,
+technical issues of menu systems or how to create CDs for Blends
+could <ulink url="http://lists.debian.org/debian-custom/" >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
+<programlisting>
+ svn checkout svn://svn.debian.org/svn/blends blends
+</programlisting>
+for anonymous users. Developers should check out via
+<programlisting>
+ svn checkout svn+ssh://<varname>username</varname>@svn.debian.org/svn/blends blends
+</programlisting>
+The current layout for the repository is as follows:
+<programlisting>
+ blends -+- blends
+ | |
+ | +- tags -----+- cdd -+- 0.3 [older versions of cdd tools]
+ | | | +- 0.3.1
+ | | | ...
+ | | | +- <varname><latest></varname>
+ | | |
+ | | +- doc -+- 0.1 [older versions of this doc]
+ | | +- 0.2
+ | | +- 0.3
+ | | [Since 0.4.1 the doc is in blends directory]
+ | |
+ | +- trunk ----blends [code in development for blends source package]
+ | |
+ | +-- doc [this document = blends-doc package]
+ |
+ +- projects -+--- med ---+- tags
+ | |
+ | +- trunk [development version of Debian Med]
+ |
+ +- science -+- tags
+ | |
+ | +- trunk [development version of Debian Science]
+ |
+ +- ...
+ |
+ ...
+</programlisting>
+There is
+a <ulink url="http://lists.alioth.debian.org/mailman/listinfo/blends-commits"
+>mailing list</ulink> with subversion changes and
+a <ulink url="http://cia.navi.cx/stats/project/debian-custom" >CIA
+system</ulink> for tracking changes in the Debian Pure Blends projects in
+real-time.
+</para>
+ </sect1>
+
+ <sect1 id="visibility">
+ <title>Enhancing visibility</title>
+
+<para>
+If a user installs Debian via official install CDs the first chance to
+do a package selection to customise the box is <command>tasksel</command>.
+The first Debian Pure Blend Debian Junior is mentioned in the
+task selection list and thus it is clearly visible to the user who
+installs Debian.
+</para>
+<para>
+In bug <ulink url="http://bugs.debian.org/186085" >#186085</ulink> a
+request was filed to include Debian Med in the same manner. The
+problem with the <command>tasksel</command>-approach is that all included
+packages should be on the first install CD. This would immediately
+have the consequence that the first install CD would run out of space
+if all Blends would be included in the task selection list.
+</para>
+<para>
+How to enhance visibility of Debian Pure Blends for the user who
+installs Debian from scratch?
+<variablelist>
+ <varlistentry>
+ <term>Change <command>tasksel</command> policy.</term>
+ <listitem><para>If the <emphasis>packages must be on the first CD</emphasis> feature of
+ <command>tasksel</command> 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
+ <command>tasksel</command> or in addition to <command>tasksel</command>
+ in the installation procedure which presents a screen which
+ gives some very short information about Debian Pure Blends
+ (perhaps pointing to this document for further reference) and
+ enables the user to select from a list of the available
+ Blends.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Provide separate install CDs</term>
+ <listitem><para>By completely ignoring the installation of the official
+ installation CD each Blend can offer a separate installation
+ CD. This will be done anyway for certain practical reasons
+ (see for instance the Debian Edu - SkoleLinux approach). But
+ this is really no solution we could prefer because this does
+ not work if the user wants to install more than one Blend on
+ one computer.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Change overall distribution philosophy of Debian.</term>
+ <listitem><para>This way is concerned to some ideas from Debian developers
+ who took part in Open Source World Conference in Malaga and
+ is explained in Detail
+ in <xref linkend="new_ways_of_distribution" />. This would save the
+ problem of making Debian Pure Blends visible to users in a
+ completely different way because in this case Debian would be
+ released as its various flavours of Blends.
+ </para></listitem>
+ </varlistentry>
+</variablelist>
+</para>
+<para>
+Whichever way Debian developers will decide to go it is our vital
+interest to support users and <emphasis>show</emphasis> our users the tools we
+invented to support them.
+</para>
+ <sect2 id="webpages">
+ <title>Debian Pure Blends web pages</title>
+<para>
+Some Blends maintain their own web space under
+<command>http://www.debian.org/devel/BLEND-name</command> to provide general
+information which will be translated by the Debian web team. This is a
+good way to inform users about the progress of a project. This page
+should link to the apropriate autogenerated pages as described
+in <xref linkend="web_if" /> to make sure that the content of the page remains
+up to date at any time.
+</para>
+ </sect2>
+ </sect1>
+
+ <sect1 id="debtags">
+ <title>Debian Package Tags</title>
+
+<para>
+<ulink url="http://debtags.alioth.debian.org/" >Debian
+Package Tags</ulink> is a work to add more metadata to Debian packages.
+At the beginning it could be seen as a way to allow to specify
+multiple sections (called "tags") per package where now only one can
+be used.
+</para>
+<para>
+However, the system has evolved so that tags are organised in
+"facets", which are separate ontologies used to categorise the
+packages under different points of view.
+</para>
+<para>
+This means that the new categorisation system supports tagging
+different facets of packages. There can be a set of tags for the
+"purpose" of a package (like "chatting", "searching", "editing"),
+a set of tags for the technologies used by a package (like "html",
+"http", "vorbis") and so on.
+</para>
+<para>
+Besides being able to perform package selection more efficiently by
+being able to use a better categorisation, one of the first outcomes
+of Debian Package Tags for Blends is that every Blend could maintain
+its own set of tags organised under a "facet", providing
+categorisation data which could be used by its users and which
+automatically interrelates with the rest of the tags.
+</para>
+<para>
+For example, Debian Edu could look for "edu::administration" packages
+and then select "use::configuring". The "edu::administration"
+classification would be managed by the Debian Edu people, while
+"use::configuring" would be managed by Debian. At the same time, non
+Debian Edu users looking for "use::configuring" could have a look at
+what packages in that category are suggested by the Debian Edu
+community.
+</para>
+<para>
+It is not excluded that this could evolve in being able to create a
+Blend just by selecting all packages tagged by "edu::*" tags, plus
+dependencies; however, this option is still being investigated.
+</para>
+<para>
+Please write to the
+list <email>deb-usability-list at lists.alioth.debian.org</email> for
+more information about Debian Package Tags or if you want to get
+involved in Debian Package Tags development.
+</para>
+ </sect1>
+
+ <sect1 id="EnhancingTechnology">
+ <title>Enhancing basic technologies regarding Debian Pure Blends</title>
+
+<para>
+In section <xref linkend="future_handling" /> several issues where raised how
+handling of metapackages should be enhanced.
+</para>
+<para>
+Currently there is no solution to address the special configuration
+issue has to be addressed. In general developers of metapackages
+should provide patches for dependent packages if they need a certain
+configuration option and the package in question does feature a
+<command>debconf</command> configuration for this case. Then the
+metapackage could provide the needed options by pre-seeding the
+<command>debconf</command> database while using very low priority questions
+which do not came to users notice.
+</para>
+<para>
+If the maintainer of a package which is listed in a metapackage
+dependency and needs some specific configuration does not accept such
+kind of patch it would be possible to go with a <command>cfengine</command>
+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 <command>cfengine</command>
+script takes over the role of the local administrator: It just handles
+as an
+"automated-<command>cfengine</command>-driven-administrator-robot".
+</para>
+<para>
+If there is some agreement to use <command>cfengine</command> scripts to
+change configuration - either according to <command>debconf</command>
+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
+<programlisting>
+ /usr/share/blends/#BLEND#/#METAPACKAGE#/cf.#SOMETHING#
+</programlisting>
+</para>
+<para>
+There was another suggestion at the Valencia workshop: Make use of
+<command>ucf</command> for the purpose mentioned above. This is a topic
+for discussion. At least currently Debian Edu seems to have good
+experiences with <command>cfengine</command> but perhaps it is worth comparing
+both.
+</para>
+<para>
+A further option might be
+<ulink url="http://freedesktop.org/Software/CFG" >Config4GNU</ulink> from
+freedesktop.org but it is not even yet packaged for Debian.
+</para>
+ </sect1>
+
+ <sect1 id="liveCD">
+ <title>Building Live CDs of each Debian Pure Blend</title>
+
+<para>
+The first step to convince a user to switch to Debian is to show him
+how it works while leaving his running system untouched.
+<ulink url="http://www.knoppix.org/" >Knoppix</ulink> - <emphasis>the "mother" of
+all Debian-based live CDs</emphasis> - is a really great success and it is a
+fact that can not be ignored that Debian gains a certain amount of
+popularity because people want to know what distribution is working
+behind the scenes of Knoppix.
+</para>
+<para>
+But Knoppix is a very common demonstration and its purpose is to work
+in everyday live. There is no room left for special applications and
+thus people started to adopt it for there special needs. In fact
+there exist so many Debian based Live CDs that it makes hardly sense
+to list them all here. The main problem is that most of them
+containing special applications and thus are interesting in the Blends
+scope are out of date because they way the usually were builded was a
+pain. One exception is
+perhaps <ulink url="http://dirk.eddelbuettel.com/quantian.html"
+>Quantian</ulink> which is quite regularly updated and is intended for
+scientists.
+</para>
+<para>
+The good news is that the problem of orphaned or outdated Live CDs can
+easily solved by debian-live and the <package>live-helper</package>.
+This package turns all work to get an up to date ISO image for a Live
+CD into calling a single script. For the Blends tools this would
+simply mean that the tasks files have to be turned into a live-helper
+input file and the basic work is done. This will be done in a future
+<package>blends-dev</package> version.
+</para>
+
+ </sect1>
+
+ <sect1 id="new_ways_of_distribution">
+ <title>New way to distribute Debian</title>
+
+<para>
+<emphasis>This section is kind of "Request For Comments" in the sense that
+solid input and arguing is needed to find out whether it is worth
+implementing it or drop this idea in favour of a better solution.</emphasis>
+</para>
+<para>
+At Open Source World Conference in Malaga 2004 there was a workshop of
+Debian Developers. Among other things the topic was raised how the
+distribution cycle or rather the method of distribution could be
+changed to increase release frequency and to better fit user interests.
+</para>
+<para>
+There was a suggestion by Bdale Garbee <email>bdale at gag.com</email> to
+think about kind of sub-setting Debian in the following way: Debian
+developers upload their packages to <varname>unstable</varname>. The normal
+process which propagates packages to <varname>testing</varname> and releasing a
+complete <varname>stable</varname> 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 <emphasis>tested inside the subset</emphasis> distribution
+which leads to a <varname>stable</varname> subset release. The following graph
+might clarify this:
+
+<programlisting>
+<![CDATA[
+DD -> unstable --> testing --> stable
+ |
+ +---> BLEND_A testing --> stable BLEND_A
+ |
+ +---> BLEND_B testing --> stable BLEND_B
+ |
+ +---> ...
+]]>
+</programlisting>
+
+where <varname>BLEND_A</varname> / <varname>BLEND_B</varname> might be something like
+<varname>debian-edu</varname> / <varname>debian-med</varname>. To implement this
+sub-setting the following things are needed:
+<variablelist>
+ <varlistentry>
+ <term>Promotion rules</term>
+ <listitem><para>There was a general agreement that technical implementation
+ of this idea in the package pool scripts / database is not too
+ hard. In fact at LinuxTag Chemnitz 2004 Martin Loschwitz
+ <email>madkiss at debian.org</email> announced exactly this as
+ "nearly implemented for testing purpose" which should solve
+ the problem of outdated software for desktop users as a goal
+ of the <varname>debian-desktop</varname> project. Unfortunately this
+ goal was not realised finally.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Reasonable subsets</term>
+ <listitem><para>Once the promotion tools are able to work with sub-setting,
+ reasonable subsets have to be defined and maintained. A
+ decision has to be made (if this will be implemented at all)
+ whether this sub-setting should be done according to the
+ Blend layout or if there are better ways to find subsets.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>BTS support</term>
+ <listitem><para>The Bug Tracking System has to deal with different package
+ versions or even version ranges to work nicely together with
+ the sub-setting approach.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Security</term>
+ <listitem><para>As a consequence of having more than only a single
+ <varname>stable</varname> each Blend team has to form a security team
+ to care for those package versions that are not identically
+ with the "old" <varname>stable</varname>.
+ </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:
+
+<programlisting>
+DD -> unstable --> testing --> releasable --> stable
+ |
+ +---> stable BLEND_A
+ |
+ +---> stable BLEND_B
+ |
+ +---> ...
+</programlisting>
+
+A third suggestion was given at Congreso Software Libre Comunidad
+Valenciana:
+
+<programlisting>
+ testing_proposed_updated
+ |
+ |
+ v
+DD -> unstable --> testing --> stable
+ |
+ +---> stable BLEND_A
+ |
+ +---> stable BLEND_B
+ |
+ +---> ...
+</programlisting>
+
+The rationale behind these testing backports is that sometimes a
+Debian Pure Blend is able to reduce the set of releasable
+architectures. Thus some essential packages could be moved much
+faster to testing and these might be "backported" to testing
+for this special Blend. For instance this might make sense for Debian
+Edu where usually neither mainframes nor embedded devices are used.
+</para>
+<para>
+All these different suggestions would lead to a modification of the
+package pool scripts which could end up in a new way to distribute
+Debian. This might result from the fact that some Debian Pure Blends
+need a defined release cycle. For instance the education related
+distributions might trigger their release by the start-end-cycle of
+the school year. Another reason to change the package pool system is
+the fact that some interested groups, who provide special service for
+a certain Blend, would take over support only for the subset of
+packages which is included in the metapackage dependencies or
+suggestions but they refuse to provide full support for the whole
+range of Debian packages. This would lead to a new layout of the file
+structures of the Debian mirrors:
+
+<programlisting>
+ debian/dists/stable/binary-i386
+ /binary-sparc
+ /binary-...
+ /testing/...
+ /unstable/...
+ debian-BLEND_A/dists/stable/binary-[supported_architecture1]
+ /binary-[supported_architecture2]
+ /...
+ /testing/...
+ debian-BLEND_B/dists/testing/...
+ /stable/...
+ ...
+ pool/main
+ /contrib
+ /non-free
+</programlisting>
+To avoid flooding the archive with unnecessarily many versions of
+packages for each single Debian Pure Blend a common base of all these
+Blends has to be defined. Here some LSB conformance statement comes
+into mind: The base system of all currently released (stable) Debian
+Pure Blends is compliant to LSB version x.y.
+</para>
+<para>
+Regarding to security issues there are two ways: Either one Debian
+Pure Blend goes with the current stable Debian and thus the
+<filename>Packages.gz</filename> is just pointing to the very same versions
+which are also in debian/stable. Then no extra effort regarding to
+security issues is need. But if there would be a special support team
+which takes over maintenance and security service for the packages in
+a certain Blend they should be made reliable for this certain subset.
+</para>
+<para>
+This reduced subset of Debian packages of a Debian Pure Blend would
+also make it easier to provide special install CDs at is it currently
+done by Debian Edu.
+</para>
+ </sect1>
+</chapter>
+
+
Added: blends/trunk/blends/doc/docbook-xml/en/A_devel.xml
URL: http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/docbook-xml/en/A_devel.xml?rev=2414&op=file
==============================================================================
--- blends/trunk/blends/doc/docbook-xml/en/A_devel.xml (added)
+++ blends/trunk/blends/doc/docbook-xml/en/A_devel.xml Tue Oct 26 16:58:17 2010
@@ -1,0 +1,625 @@
+ <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
+<package><blend>-config</package> package from which
+all other metapackages of the <varname>Blend</varname> in question will
+depend. This <package><blend>-config</package> package
+instantiates the <varname>Blend</varname> in the common registry for all Blends in
+<filename>/etc/blends</filename>.
+</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 containig one single line
+
+<programlisting>
+ include /usr/share/blends-dev/Makefile
+</programlisting>
+
+(see <filename>/usr/share/doc/blends-dev/examples/Makefile</filename>). 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<varname>-tasks.desk</varname></title>
+
+<para>
+This target is the description file that is used in
+<command>tasksel</command> to enable selecting the tasks belonging to the
+Blend. The file will be moved to the
+<varname>blend</varname><package>-tasks</package>. All information is obtained
+from the single task files in the <filename>tasks</filename> directory of the
+Blend source.
+</para>
+
+</sect2>
+<sect2 id="debian_control">
+ <title><varname>debian/control</varname></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 <command>blend-gen-control</command> verifies whether these
+dependencies exist in the specified package pool and create
+the <filename>debian/control</filename> file 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>
+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 <command>apt-get</command> 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. Packages that are specified with
+ "Suggests" will not be taken over to
+ the <command>tasksel</command> 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 <command>tasksel</command> 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>
+ <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 <varname>stable</varname>, <varname>testing</varname>, <varname>unstable</varname> 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 <varname>-s </varname><varname>dist</varname> option of <citerefentry><refentrytitle>blend-gen-control</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+</para>
+<para>
+<emphasis role="strong">TODO:</emphasis> <emphasis>Either parse the available
+<filename>/etc/apt/sources.list</filename> or use a sane <command>debconf</command>
+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><!-- document type does not allow element "MANREF" here--><command>blend-role(8)</command></title>
+<para>
+<variablelist>
+ <varlistentry>
+ <term>NAME</term>
+ <listitem><para>
+ <command>blend-role</command> - add/remove roles in registered Debian Pure Blend
+
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>SYNOPSIS</term>
+ <listitem><para>
+ <command>blend-role</command> <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><para>
+ <variablelist>
+ <varlistentry>
+ <term><varname>Blend</varname></term>
+ <listitem><para>A registered Blend in /etc/blends, for example
+ one of <varname>med</varname>, <varname>junior</varname>,
+ <varname>edu</varname> or <varname>science</varname>
+ </para></listitem>
+ </varlistentry>
+ </variablelist>
+ </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>
+
+<sect2 id="blend-update-menus">
+ <title><!-- document type does not allow element "MANREF"
+ here--><command>blend-update-menus(8)</command></title>
+<para>
+<variablelist>
+ <varlistentry>
+ <term>NAME</term>
+ <listitem><para>
+ <command>blend-update-menus</command> - add menu of metapackage to all Blend users
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>SYNOPSIS</term>
+ <listitem><para>
+ <command>blend-update-menus</command> [<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><para>
+ <variablelist>
+ <varlistentry>
+ <term><varname>Blend</varname></term>
+ <listitem><para>one of the installed Blends, listed in /etc/blends/, for example
+ (if installed: <varname>med</varname>, <varname>junior</varname>,
+ <varname>edu</varname> or <varname>science</varname>.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>user</varname></term>
+ <listitem><para>system user</para></listitem>
+ </varlistentry>
+ </variablelist>
+ </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>
+
+<sect2>
+ <title><!-- document type does not allow element "MANREF" here--><command>blend-user(8)</command></title>
+<para>
+<variablelist>
+ <varlistentry>
+ <term>NAME</term>
+ <listitem><para>
+ <command>blend-user</command> - add/remove user to Role of a registered Blend
+
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>SYNOPSIS</term>
+ <listitem><para>
+ <command>blend-user</command> <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><para>
+ <variablelist>
+ <varlistentry>
+ <term><varname>Blend</varname></term>
+ <listitem><para>A registered Blend in /etc/blends, for example
+ one of <varname>med</varname>, <varname>junior</varname>,
+ <varname>edu</varname> or <varname>science</varname>.
+ </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>
+ </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>
+
+<sect2>
+ <title><command>blends.conf(5)</command></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/<varname><Blend></varname>/<varname><Blend></varname>.conf</filename>
+ for each single Blend.</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>SYNTAX</term>
+ <listitem><para>The following variables can be set:
+ <variablelist>
+ <varlistentry>
+ <term><varname>DBBACKEND</varname></term>
+ <listitem><para>Set the backend for the user role management system.
+ Currently the only implemented role management system is
+ <varname>unixgroups</varname> but others might be implemented
+ later. Unsetting this variable leads to use no roles at all.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>UPDATEUSERMENU</varname></term>
+ <listitem><para>If this is set to <varname>yes</varname>, 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><varname>SHAREDIR</varname></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><varname>DRYRUN</varname></term>
+ <listitem><para>This variable can be set for debugging. Normally it
+ should be left unset (<emphasis>NOT</emphasis> set to <varname>false</varname>
+ or anything else!). If set to <varname>true</varname> a dry run of
+ the tools is performed or <command>echo DRYRUN:</command> would
+ print debugging information.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>DEBUG</varname></term>
+ <listitem><para>If set to <varname>1</varname> debugging mode is switched on.</para></listitem>
+ </varlistentry>
+ </variablelist>
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>SEE ALSO</term>
+ <listitem><para>
+ <filename>blend-role (8)</filename>, <filename>blend-update-menus (8)</filename>,
+ <filename>blend-user (8)</filename>
+ </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 <filename>svn</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
+<programlisting>
+ svn checkout svn+ssh://<varname>username</varname>@svn.debian.org/svn/blends/blends/trunk/blends blends
+</programlisting>
+ or for the Debian Pure Blend <varname>BLEND-name</varname>
+<programlisting>
+ svn checkout svn+ssh://<varname>username</varname>@svn.debian.org/svn/blends/projects/<varname>BLEND-name</varname>/trunk
+</programlisting>
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Build source package</term>
+ <listitem><para>
+ Change into the created directory and type
+<programlisting>
+ make -f debian/rules get-orig-source
+</programlisting>
+ 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
+<programlisting>
+ #!/usr/bin/make -f
+ include /usr/share/blends-dev/Makefile
+</programlisting>
+ Which enables you to simply say
+<programlisting>
+ make dist
+</programlisting>
+ 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 <command>alioth.debian.org</command></para></listitem>
+ <listitem><para><command>cd /var/lib/gforge/chroot/home/groups/blends/webtools/</command></para></listitem>
+ <listitem><para><command>./tasks.py <blend-name></command></para></listitem>
+</orderedlist>
+</para>
+<para>
+To know what a valid <varname><blend-name></varname> might be have a look
+into
+<command>/var/lib/gforge/chroot/home/groups/blends/webtools/webconf</command>.
+Each Blend has an according config file there. Leave out
+the <varname>.conf</varname> extension and you have a
+valid <varname><blend-name></varname>.
+</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 <command>blends.debian.net</command> 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 SVN at
+<command>svn://svn.debian.org/blends/blends/trunk/webtools</command>. 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
+<command>svn://svn.debian.org/blends/blends/trunk/webtools/templates</command>.
+You can also influence some parameters of the web pages in the
+configuration files
+<command>svn://svn.debian.org/blends/blends/trunk/webtools/webconf</command>.
+Last but not least you can provide translations for the web pages in
+<command>svn://svn.debian.org/blends/blends/trunk/webtools/po</command>.
+</para>
+<para>
+Once something on the web pages was changed you can activate the
+changes as follows:
+</para>
+<para>
+<orderedlist>
+ <listitem><para>Login to <command>alioth.debian.org</command> or <command>blends.debian.net</command></para></listitem>
+ <listitem><para><command>cd /var/lib/gforge/chroot/home/groups/blends/webtools/</command></para></listitem>
+ <listitem><para><command>./deploy-svn</command></para></listitem>
+</orderedlist>
+</para>
+<para>
+Please note that the <varname>css</varname> and <varname>js</varname> 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 SVN at
+<command>svn://svn.debian.org/blends/blends/trunk/websites</command>.
+Once you have changed the content of the pages you can activate
+the changes by doing:
+</para>
+<para>
+<orderedlist>
+ <listitem><para>Login to <command>alioth.debian.org</command> or <command>blends.debian.net</command></para></listitem>
+ <listitem><para><command>cd /var/lib/gforge/chroot/home/groups/blends/webtools/</command></para></listitem>
+ <listitem><para><command>./deploy-static-pages</command></para></listitem>
+</orderedlist>
+</para>
+</sect1>
+ </appendix>
+
+
Added: blends/trunk/blends/doc/docbook-xml/en/B_quickintro.xml
URL: http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/docbook-xml/en/B_quickintro.xml?rev=2414&op=file
==============================================================================
--- blends/trunk/blends/doc/docbook-xml/en/B_quickintro.xml (added)
+++ blends/trunk/blends/doc/docbook-xml/en/B_quickintro.xml Tue Oct 26 16:58:17 2010
@@ -1,0 +1,219 @@
+ <appendix id="QuickIntro">
+ <title>Quick intro into building metapackages</title>
+
+<para>
+There are several descriptions available how to build Debian packages
+in general. The main resource might be the repository of
+<ulink
+url="http://www.debian.org/doc/packaging-manuals/"
+>Debian packaging manuals</ulink> (especially
+<ulink
+url="http://www.debian.org/doc/packaging-manuals/developers-reference/best-pkging-practices.html"
+>developers reference chapter 6, best packaging practices</ulink>).
+There are several external packaging HOWTOs for example the one from
+<ulink
+url="http://www-106.ibm.com/developerworks/linux/library/l-debpkg.html"
+>Joe 'Zonker' Brockmeier</ulink>.
+</para>
+
+ <sect1 id="Dependencies">
+ <title>Defining dependencies for metapackages</title>
+
+<para>
+This howto describes the building of metapackages by using the
+<package>blends-dev</package> package. It is perfectly possible to
+build a metapackage as any other normal Debian package but this HOWTO
+has the only purpose to describe the profit you might gain by using
+these tools.
+
+ <programlisting>
+~> cp -a /usr/share/doc/blends-dev/examples/tasks .
+~> cat tasks/README
+~> edit tasks/task1
+Description: <varname>short description
+ long description as in any debian/control file</varname>
+
+Depends: <varname>dependency1, dependency2, ...</varname>
+ </programlisting>
+
+For each metapackage this skeleton of a <filename>debian/control</filename>
+entry is needed. All necessary information is available in the
+directory <filename>/usr/share/doc/blends-dev/examples/tasks</filename>.
+</para>
+ </sect1>
+
+ <sect1 id="Packaging">
+ <title>The packaging directory</title>
+
+<para>
+To build any Debian package you always need a directory named
+<filename>debian</filename>, which contains a certain set of files. The
+package <package>blends-dev</package> provides a complete set of example
+files that only have to be copied and after editing some place
+holders are ready to use.
+<programlisting>
+~> cp -a /usr/share/doc/blends-dev/examples/debian .
+~> cat debian/README
+~> edit debian/control.stub
+</programlisting>
+Now the variables in the file <filename>control.stub</filename> change the
+variables named <varname>_BLEND_</varname>, <varname>_MAINTAINER_</varname> etc. to
+match the names of the Debian Pure Blend to be built. Please note
+that the file <filename>debian/control</filename> is and has to be a symbolic
+link to <filename>control.stub</filename> to let the
+<package>blends-dev</package> tools work.
+
+<programlisting>
+~> edit debian/rules
+</programlisting>
+
+Also in the <filename>debian/rules</filename> the name of the Blend has to be
+inserted where the template contains
+<varname>_BLEND_</varname>. Depending from the way the
+<filename>sources.list</filename> should be scanned the options for the
+<command>gen-control</command> call can be adjusted.
+</para>
+<para>
+You have to build the tarball using the command
+<programlisting>
+~> make -f debian/rules get-orig-source
+</programlisting>
+For your comfort you might like to create a file
+<filename>Makefile</filename> containing
+<programlisting>
+#!/usr/bin/make -f
+include /usr/share/blends-dev/Makefile
+</programlisting>
+which enables you to simply use
+<programlisting>
+~> make dist
+</programlisting>
+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
+<programlisting>
+~> debuild
+</programlisting>
+</para>
+<para>
+That's all for the very simple case when the metapackages should not
+contain user menus. Even if user menus are suggested they are not
+necessary. The following paragraphs describe how to use the
+<package>blends-dev</package> tools to support these menus.
+</para>
+
+ </sect1>
+
+ <sect1 id="common-metapackage">
+ <title>The common metapackage</title>
+
+<para>
+The creation of a common package is optional, but suggested, because it
+adds some special features like menus, user groups, and probably more
+in the future. It is automatically built by
+<filename>blend-install-helper</filename>, which is called in
+<filename>debian/rules</filename>, if the <filename>common</filename> directory exists.
+The easiest way to create this is as follows:
+<programlisting>
+~> cp -a /usr/share/doc/blends-dev/examples/common .
+~> cat common/README
+~> edit common/conf common/control common/common.1
+</programlisting>
+The variables (<varname>_BLEND_</varname>) in these three files have to be
+adjusted to the name of the Debian Pure Blend in question.
+This <filename><varname>blend</varname>-config</filename> cares for the initialisation
+of the role based menu system and might contain adjustments of the
+general configuration inside the <package>blends-common</package>.
+</para>
+<para>
+If the metapackage <package>blend-config</package> will be
+created according to these rules all other metapackages will depend
+automatically from this common package. For the friends of
+<command>auto-apt</command>, a helper
+<filename>/usr/bin/<metapackage-name></filename> will be
+installed as well, which just prints some information about the meta
+package. All in all, the usage of the common package is strongly
+suggested to have a common registry for stuff like user roles and
+possibly other things that will be implementd in the future.
+</para>
+ </sect1>
+ <sect1 id="metapackage-menus">
+ <title>The metapackage menus</title>
+
+<para>
+As explained in <xref linkend="menu_tools" /> the metapackages can contain
+user menus. This optional feature can be implemented easily by using
+the template from the <package>blends-dev</package> in the following way:
+
+<programlisting>
+~> cp -a /usr/share/doc/blends-dev/examples/menu .
+~> cat menu/README
+~> edit menu/task1
+ <varname>Edit the example to legal menu entries of the
+ dependencies of this metapackage</varname>
+~> cp menu/task1 menu/<varname><metapackage name></varname>
+</programlisting>
+
+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
+<varname>package</varname> field, which has to be changed from
+<package><dependent package></package> to
+<package>blend-task</package>. All other entries
+might remain unchanged. This is a good point to check whether the
+menu entries of the packages you depend from are formated nicely and
+print the necessary information (for instance make use of "hints").
+Here the metapackage maintainer has a good chance for quality
+assurance work, which is also part of the Debian Pure Blends
+issue.
+</para>
+<para>
+In principle these menu items could be created automatically either at
+metapackage build time or even better in the <filename>postinst</filename>
+script of the metapackage because it is granted that the needed menu
+files are installed on the system, which is not really necessary on
+the metapackage build machine. This might be implemented in later
+versions of <package>blends-dev</package>. Currently the policy is that
+we like to have a little bit of control about the menu entries for the
+quality assurance issue mentioned above. Last, but not least, there are
+packages that do not provide a menu entry. If this is the case
+because the package maintainer just forgot it a bug report should be
+filed. On the other hand, there are packages with programs that
+provide a command line interface that does not allow a reasonable
+menu entry. A solution for this case is provided in the next
+paragraph.
+</para>
+
+ </sect1>
+ <sect1 id="any-dependency--menus">
+ <title>Menu for any dependency</title>
+
+<para>
+The idea of the metapackage menu is to provide the user with easily
+viewable traces of any installed package that helps solving everyday
+tasks. So if there are packages that do not contain a menu, a screen
+with relevant documentation should be provided in a viewer by the
+creator of the metapackage. Such documentation can be created using
+the following templates:
+
+<programlisting>
+~> cp -a /usr/share/doc/blends-dev/examples/docs .
+~> cat docs/README
+~> edit docs/task1/dep1
+ <varname>Provide information about a package <dep1> that is
+ a dependency of the metapackage <task1>, but does not
+ contain a useful menu entry.</varname>
+~> cp docs/task1/dep1 docs/task1/<varname><dependent pkg></varname>
+~> cp -a docs/task1 docs/<varname><metapackage name></varname>
+</programlisting>
+
+This ensures that our users become aware of all interesting packages
+on their system. The documentation files should contain hints to man
+pages to read, URLs that should be visited to learn more about the
+package or some short introduction how to get started.
+</para>
+</sect1>
+</appendix>
Added: blends/trunk/blends/doc/docbook-xml/en/C_bts.xml
URL: http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/docbook-xml/en/C_bts.xml?rev=2414&op=file
==============================================================================
--- blends/trunk/blends/doc/docbook-xml/en/C_bts.xml (added)
+++ blends/trunk/blends/doc/docbook-xml/en/C_bts.xml Tue Oct 26 16:58:17 2010
@@ -1,0 +1,94 @@
+ <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
+<command>program_xy</command> 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 <command>reportbug</command> for this purpose.
+</para>
+<para>
+If you use wnpp sanely you can even tag this bug for the intended
+purpose to include it in a certain Debian Pure Blend. This was
+described
+in <ulink url="http://lists.debian.org/debian-devel-announce/2005/09/msg00002.html"
+>a mail of Anthony Towns</ulink> and
+<ulink
+url="http://wiki.debian.org/DebianScience/Sponsoring"
+>the Debian wiki</ulink>. It was also described in
+<ulink url="http://lists.debian.org/debian-custom/2005/04/msg00017.html"
+>a mail of Ben Armstrong</ulink> and in short works like this:
+
+<itemizedlist>
+ <listitem><para>
+ Add an usertag to an existing bug by sending to
+ request at bugs.debian.org a mail containing
+ <programlisting>
+ user <email>
+ usertag <bug number> + wnpp <metapackage name>
+ </programlisting>,
+ where email is the electronic address of the person or mailing
+ list which coordinates the relevant Debian Pure Blend.
+ </para>
+ <para>
+ For instance if you want to tag an ITP with bug number
+ #123456 for Debian Med section biology you would send the
+ following mail to <email>request at bugs.debian.org </email>:
+ <programlisting>
+ user debian-med at lists.debian.org
+ usertag 123456 + wnpp med-bio
+ thanks
+ </programlisting>
+ </para>
+ <para>
+ <emphasis role="strong">Note:</emphasis> Because the search is case sensitive
+ please always use lower case tags!
+ </para>
+ </listitem>
+ <listitem><para>To search for WNPP bugs of a certain Debian Pure Blend just
+ visit the URL
+<programlisting>
+http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=wnpp;users=<varname>email</varname>
+</programlisting>
+ </para></listitem>
+</itemizedlist>
+
+
+</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 <command>reportbug</command> 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 <command>reportbug</command>.
+</para>
+
+</sect1>
+
+</appendix>
+
+
Added: blends/trunk/blends/doc/docbook-xml/en/sgml2xml
URL: http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/docbook-xml/en/sgml2xml?rev=2414&op=file
==============================================================================
--- blends/trunk/blends/doc/docbook-xml/en/sgml2xml (added)
+++ blends/trunk/blends/doc/docbook-xml/en/sgml2xml Tue Oct 26 16:58:17 2010
@@ -1,0 +1,131 @@
+#!/usr/bin/python
+# -*- coding: utf-8 -*-
+
+"""
+transformation de Docbook-sgml en Docbook-xml
+"""
+import re, sys
+
+def changeTag1(source, from_, to_):
+ """
+ Change les tags, sans récupérer les attributs du tag ouvrant
+ @param source un texte source
+ @param from_ le tag de départ
+ @param to_ le tag de remplacement
+ @return le texte modifié.
+ """
+ openPattern="<%s>" %from_
+ closePattern="</%s>" %from_
+ out1=re.sub(openPattern,"<%s>" %to_, source)
+ out2=re.sub(closePattern,"</%s>" %to_, out1)
+ return out2
+
+def changeTag2(source, from_, to_):
+ """
+ Change les tags, en récupérant les attributs du tag ouvrant
+ @param source un texte source
+ @param from_ le tag de départ
+ @param to_ le tag de remplacement
+ @return le texte modifié.
+ """
+ openPattern="<%s(([^1-9][^>]*)?)>" %from_
+ closePattern="</%s>" %from_
+ out1=re.sub(openPattern,"<%s\\1>" %to_, source)
+ out2=re.sub(closePattern,"</%s>" %to_, out1)
+ return out2
+
+def changeItems(source):
+ """
+ change les <item>...</item> en <listitem><para>...</para></listitem>
+ @param source un texte source
+ @return le texte modifié.
+ """
+ out1=re.sub("<item>", "<listitem><para>", source)
+ out2=re.sub("</item>", "</para></listitem>", out1)
+ return out2
+
+def retireLocalVar(source):
+ """
+ retire la partie consacrée aux variables locales
+ @param source un texte source
+ @return le texte modifié.
+ """
+ out1=re.sub("<!-- Keep this comment at the end of the file[^>]*-->",
+ "", source)
+ return out1
+
+def traiteStrong(source):
+ """
+ traite les balises <strong>...</strong>
+ @param source un texte source
+ @return le texte modifié.
+ """
+ out1=re.sub("<strong>", "<emphasis role=\"strong\">", source)
+ out2=re.sub("</strong>", "</emphasis>", out1)
+ return out2
+
+def traiteUlink(source):
+ """
+ traite les balises <ulink> qui sont insuffisamment travaillées avant ça
+ @param source un texte source
+ @return le texte modifié.
+ """
+ out1=re.sub("<ulink([^>]*)id=[\"']([^\"']+)[\"']([^>]*)>",
+ "<ulink\\1url=\"\\2\"\\3>", source)
+ out2=re.sub("<ulink([^>]*)name=[\"']([^\"']+)[\"']([^>]*)>",
+ "<ulink\\1\\3>\\2</ulink>", out1)
+ return out2
+
+def traiteXref(source):
+ """
+ traite les balises <xref> qui sont insuffisamment travaillées avant ça
+ @param source un texte source
+ @return le texte modifié.
+ """
+ out1=re.sub("<xref([^>]*)id=[\"']([^\"']+)[\"']([^>]*)>",
+ "<xref\\1linkend=\"\\2\"\\3 />", source)
+ return out1
+
+if __name__=="__main__":
+ changes1=["p", "para",
+ "tag","term",
+ "em","emphasis",
+ "file","filename",
+ "var","varname",
+ "prgn","command",
+ "example","programlisting"
+ ]
+ changes2=["chapt","chapter",
+ "heading","title",
+ "sect2","sect3",
+ "sect1","sect2",
+ "sect","sect1",
+ "list","itemizedlist",
+ "enumlist","orderedlist",
+ "taglist","variablelist",
+ "url", "ulink",
+ "ref","xref",
+ ]
+ infile=open(sys.argv[1],"r")
+ source=infile.read()
+ infile.close()
+ for i in range(0, len(changes1),2):
+ from_=changes1[i]
+ to_=changes1[i+1]
+ source=changeTag1(source, from_, to_)
+ for i in range(0, len(changes2),2):
+ from_=changes2[i]
+ to_=changes2[i+1]
+ source=changeTag2(source, from_, to_)
+ source=changeItems(source)
+ source=traiteStrong(source)
+ source=traiteUlink(source)
+ source=traiteXref(source)
+ source=retireLocalVar(source)
+ if len (sys.argv) > 2 and sys.argv[2]=="change" :
+ outfile=open(sys.argv[1]+".tmp","w")
+ outfile.write(source)
+ else:
+ print source,
+
+
Propchange: blends/trunk/blends/doc/docbook-xml/en/sgml2xml
------------------------------------------------------------------------------
svn:executable = *
Added: blends/trunk/blends/doc/docbook-xml/fr/00_titletoc.xml
URL: http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/docbook-xml/fr/00_titletoc.xml?rev=2414&op=file
==============================================================================
--- blends/trunk/blends/doc/docbook-xml/fr/00_titletoc.xml (added)
+++ blends/trunk/blends/doc/docbook-xml/fr/00_titletoc.xml Tue Oct 26 16:58:17 2010
@@ -1,0 +1,91 @@
+<bookinfo>
+
+ <title>Debian Pure Blends</title>
+ <!-- subtitle>Préparation de Debian pour des groupes d'utilisateurs spéciaux </subtitle -->
+ <author>
+ <firstname>Andreas</firstname> <surname>Tille</surname>
+ <email>tille at debian.org</email>
+ </author>
+ <othercredit>
+ <firstname>Georges</firstname> <surname>Khaznadar</surname>
+ <contrib>Traduction française</contrib>
+ <email>georgesk at ofset.org</email>
+ </othercredit>
+
+<pubdate/>
+
+<abstract>
+ <para>
+ Cet article s'adresse à ceux qui s'intéressent à la philosophie de
+ Debian Pure Blends (« Blends », en abrégé, si on l'utilise clairement
+ dans le contexte interne Debian), et la technique utilisée pour gérer
+ ces projets. Pour ceux qui sont familiers du concept Custom
+ Debian Distributions : nous avons juste trouvé un nouveau nom pour ce
+ concept parce que l'ancien n'exprimait pas ce qui était fait. On
+ explique en détail pourquoi les Blends ne sont pas des fourches de
+ Debian, mais résident complètement à l'intérieur de la distribution
+ GNU/Linux Debian, et dont on peut profiter des avantages en utilisant
+ cette approche. Le concept de métapaquet et de menus basés sur un rôle
+ d'utilisateur sont expliqués. En résumé: ce document décrit pourquoi
+ les Debian Pure Blends sont importants pour la vitalité et la qualité
+ de Debian.
+ </para>
+</abstract>
+<copyright>
+ <year>2004</year>
+ <year>2005</year>
+ <year>2006</year>
+ <year>2007</year>
+ <year>2008</year>
+ <year>2009</year>
+ <holder> Andreas Tille</holder>
+</copyright>
+<copyright>
+ <year>2010</year>
+ <holder>Georges Khaznadar</holder>
+</copyright>
+
+<legalnotice>
+ <para>
+ Ce manuel est un logiciel libre ; vous pouvez le redistribuer et/ou
+ le modifier sous les termes de la GNU General Public License, comme
+ publiée par la Free Software Foundation ; au choix, la version 2.0,
+ ou (selon votre préférence) toute version ultérieure.
+ </para>
+
+ <para>
+ Ceci est distribué dans l'espoir que ce sera utile, mais
+ <emphasis>sans aucune garantie</emphasis> ; sans même la garantie
+ d'une valeur marchande ou de l'adaptions à un usage quelconque. Voyez
+ la GNU General Public License pour plus de détails.
+ </para>
+
+ <para>
+ Une copie de la GNU General Public License est disponible
+ sur Internet Ã
+ <ulink url="http://www.gnu.org/copyleft/gpl.html">
+ <citebiblioid>http://www.gnu.org/copyleft/gpl.html"</citebiblioid>
+ </ulink>.
+ Vous pouvez aussi l'obtenir en écrivant à  :
+ Free Software Foundation, Inc., 51
+ Franklin Street, Fifth Floor, Boston, MA 02110, USA.
+ </para>
+
+ <para>
+ Vous pouvez trouver la source de cet articles
+ <ulink url="http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/">
+ dans le dépôt Subversion
+ <citebiblioid>svn.debian.org</citebiblioid>
+ </ulink>.
+ Elle est aussi disponible comme un paquet Debian
+ <package>blends-doc</package>.
+ </para>
+
+ <para>
+ Une <ulink url="debian-blends.fr.pdf">
+ version imprimable au format PDF</ulink> sera construite de temps en temps.
+ </para>
+</legalnotice>
+
+</bookinfo>
+
Added: blends/trunk/blends/doc/docbook-xml/fr/01_introduction.xml
URL: http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/docbook-xml/fr/01_introduction.xml?rev=2414&op=file
==============================================================================
--- blends/trunk/blends/doc/docbook-xml/fr/01_introduction.xml (added)
+++ blends/trunk/blends/doc/docbook-xml/fr/01_introduction.xml Tue Oct 26 16:58:17 2010
@@ -1,0 +1,47 @@
+<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 (formerly known as Custom Debian Distributions)
+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>
+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>
Added: blends/trunk/blends/doc/docbook-xml/fr/02_about.xml
URL: http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/docbook-xml/fr/02_about.xml?rev=2414&op=file
==============================================================================
--- blends/trunk/blends/doc/docbook-xml/fr/02_about.xml (added)
+++ blends/trunk/blends/doc/docbook-xml/fr/02_about.xml Tue Oct 26 16:58:17 2010
@@ -1,0 +1,225 @@
+
+<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>
+<!--AT: The context is somehow missing here. -->
+ 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 role="strong">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:
+ <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>
+ 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 role="strong">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>
+</sect1>
+
+</chapter>
Added: blends/trunk/blends/doc/docbook-xml/fr/03_general_ideas.xml
URL: http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/docbook-xml/fr/03_general_ideas.xml?rev=2414&op=file
==============================================================================
--- blends/trunk/blends/doc/docbook-xml/fr/03_general_ideas.xml (added)
+++ blends/trunk/blends/doc/docbook-xml/fr/03_general_ideas.xml Tue Oct 26 16:58:17 2010
@@ -1,0 +1,342 @@
+<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><para>
+ <itemizedlist>
+ <listitem><para>Corporate Server - Mandriva</para></listitem>
+ <listitem><para>Advanced Server - RedHat</para></listitem>
+ <listitem><para>Enterprise Server - SuSE</para></listitem>
+ </itemizedlist>
+ </para></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><para>
+ <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></para>
+ </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 role="strong">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
+<!-- AT: We should find a way to avoid printing the URL in PDF output. -->
+<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 role="strong">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>
Added: blends/trunk/blends/doc/docbook-xml/fr/04_existing_blends.xml
URL: http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/docbook-xml/fr/04_existing_blends.xml?rev=2414&op=file
==============================================================================
--- blends/trunk/blends/doc/docbook-xml/fr/04_existing_blends.xml (added)
+++ blends/trunk/blends/doc/docbook-xml/fr/04_existing_blends.xml Tue Oct 26 16:58:17 2010
@@ -1,0 +1,598 @@
+<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">
+ 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>Release</term>
+ <listitem><para>Debian 3.0 (Woody)</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Goals</term>
+ <listitem><para>
+ <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>
+ </para></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>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>Release</term>
+ <listitem><para>Sarge</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Goals</term>
+ <listitem><para>
+ <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>
+ </para></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>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>Former Initiator</term>
+ <listitem><para>Raphaël Hertzog <email>hertzog at debian.org</email></para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Now 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><para>
+ <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>
+ </para></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>
+<!-- Just learned that they are using Ubuntu now
+ <term><ulink url="http://www.lliurex.net/" name="LliureX"></term>
+ <listitem><para>A Debian derivative distribution in development to be used in
+ schools in Valencia. The goal is to integrate as much as
+ ## {BA} This is a difficult passage to interpret. What does "integrate
+ as much as possible as a Blend" mean? Does it mean they mean to literally
+ produce a Blend (impossible if they remain a derivative)? Or does it mean
+ they are going to "give back" their work into Debian so it could be
+ incorporated into a Blend (debian-edu itself?) Or something else?
+ [AT] More or less something else. They have not really
+ settled down what to do and how to proceed which I wanted to
+ say by "in development". I hope they will follow the
+ Debian Edu way (which I regard as a very clever solution as
+ close as possible but they have to respect local government
+ issues and perhaps need some stuff which can not be
+ integrated. We have to wait a little bit until they have
+ found a decision.
+ ##
+ possible as a Debian Pure Blend.< / item>
+ -->
+<!-- FIXME: Aren't they using Ubuntu as well? -->
+ <varlistentry>
+ <term><ulink url="http://www.guadalinex.org/">Guadalinex</ulink></term>
+ <listitem><para>This distribution is not only related to education, but might
+ try also to integrate what they have produced back into Debian.</para></listitem>
+ </varlistentry>
+ </variablelist>
+</para>
+</sect1>
+
+ <sect1 id="demudi">
+ <title>DeMuDi: Debian Multimedia Distribution</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></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>URL</term>
+ <listitem><para><ulink url="http://www.agnula.org/">Demudi</ulink>
+ (now <ulink url="http://64studio.com/">64 Studio</ulink>)
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Initiator</term>
+ <listitem><para>Marco Trevisani <email>marco at centrotemporeale.it</email></para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Goals</term>
+ <listitem><para>
+ <itemizedlist>
+ <listitem><para>To bring back this fork into Debian.</para></listitem>
+ <!-- [BA] This is not a goal. However, I don't know how to fix it. The
+ DeMuDi site was no help, as I couldn't find goals for the project listed
+ there. Perhaps the point should just be stricken?
+ [AT] I just wanted to express the fact that I got the word
+ that the first metapackages are in preparation by Free Enkanayaka.
+ -->
+ <listitem><para>Oriented toward music and multimedia.</para></listitem>
+ <listitem><para>To make GNU/Linux a platform of choice for the musician
+ and the multimedia artist.</para></listitem>
+ </itemizedlist>
+ </para></listitem>
+ </varlistentry>
+</variablelist>
+
+The initiator is not yet a Debian developer, but it is possible to work on
+Debian without being an official developer.
+</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>Mailing list</term>
+ <listitem><para><ulink url="http://wiki.debian.org/DebianGis/MailingLists">user and developer list</ulink></para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Initiator</term>
+ <listitem><para>Francesco P. Lovergine <email>frankie at debian.org</email></para></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>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>Initiator</term>
+ <listitem><para>Michael Banck <email>mbanck at debian.org</email></para></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>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>Initiator</term>
+ <listitem><para>Helen Faulkner <email>helen 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="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>Initiator</term>
+ <listitem><para>Colin Walters <email>walters at debian.org</email></para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Goals</term>
+ <listitem><para>
+ <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>
+ </para></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 Integrated Solutions. 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>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>Initiator</term>
+ <listitem><para>Jeremy Malcolm <email>Jeremy at Malcolm.id.au</email></para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Goals</term>
+ <listitem><para>
+ <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>
+ </para></listitem>
+ </varlistentry>
+</variablelist>
+The word <emphasis>lex</emphasis> is the Latin word for law.
+</para>
+</sect2>
+
+ <sect2 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>Initiator</term>
+ <listitem><para>Mario Lang <email>mlang at debian.org</email></para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Goals</term>
+ <listitem><para>
+ <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>
+ </para></listitem>
+ </varlistentry>
+</variablelist>
+
+</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>Goals</term>
+ <listitem><para>
+ <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><para>To provide install-time options regarding the intended
+ purpose.</para></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>
+ </para></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>
Added: blends/trunk/blends/doc/docbook-xml/fr/05_inside.xml
URL: http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/docbook-xml/fr/05_inside.xml?rev=2414&op=file
==============================================================================
--- blends/trunk/blends/doc/docbook-xml/fr/05_inside.xml (added)
+++ blends/trunk/blends/doc/docbook-xml/fr/05_inside.xml Tue Oct 26 16:58:17 2010
@@ -1,0 +1,264 @@
+<chapter id="inside">
+ <title>Distributions inside Debian</title>
+
+ <sect1 id="fork">
+ <title>To fork or not to fork</title>
+
+<para>
+There are many distributions that decided to fork from a certain
+state of Debian. This is perfectly all right because Debian is
+completely free and everybody is allowed to do this. People who
+built those derived distributions had certain reasons to proceed
+this way.
+</para>
+
+ <sect2 id="commercialfork">
+ <title>Commercial forks</title>
+
+<para>
+If Debian should be used as the base for a commercial distribution
+like
+ <ulink url="http://www.linspire.com/" >Linspire</ulink> (formerly Lindows),
+ <ulink url="http://www.libranet.com/" >Libranet</ulink> or
+ <ulink url="http://www.xandros.com/" >Xandros</ulink>, there is no other
+choice than forking because these companies normally add some stuff
+that is non-free. While Debian Pure Blends might be interesting in
+technical terms for those commercial distributions by making it easier
+to build a separate distribution, these non-free additions are not
+allowed to be integrated into Debian, and thus integration into Debian
+is impossible.
+</para>
+ </sect2>
+
+ <sect2 id="noncommercialfork">
+ <title>Non-commercial forks</title>
+
+<para>
+As a completely free distribution Debian GNU/Linux is quite often a
+welcome starting point for derived distributions with a certain
+purpose that are as free as Debian but had certain reasons to fork.
+One main reason for a fork was that Debian was not flexible enough for
+certain purposes and some needed features had to be added. One reason
+for the Debian Pure Blends effort is to increase flexibility and to
+make the reason mentioned above void (if it is not yet void because of
+the general develoment of Debian). Some examples of forks from Debian
+that are probably now able to integrate back into Debian as a Debian
+Pure Blend are:
+
+<variablelist>
+ <varlistentry>
+ <term><ulink url="http://www.skolelinux.org" >SkoleLinux</ulink></term>
+ <listitem><para>Mentioning SkoleLinux in the category of forks is more or less
+ history. The merge back into Debian started with the
+ SkoleLinux people really doing a great job to enhance Debian
+ for their own purposes in the form of their work on
+ debian-installer, and culminated with the formal merging of
+ the Blend Debian Edu and SkoleLinux, so that they are now
+ virtually equivalent. This is the recommended way for derived
+ distributions, and the reasons for this recommendation are
+ given below.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>DeMuDi</term>
+ <listitem><para>The <ulink
+ url="http://www.agnula.org/">Agnula</ulink> project, which is founded by the
+ European Community, (and in fact is the first Free Software project
+ that was founded by the EU at all,) forked for the
+ following reasons:
+ <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>
+ This shows that there is no longer a real need for a fork, and
+ in fact, the organiser of the DeMuDi project was in contact to
+ start bringing DeMuDi back into Debian. That is why DeMuDi is
+ mentioned in the list of Debian Pure Blends above.
+ Unfortunately the effort to merge back has stalled but it
+ might be an interesting project to apply Blends techniques to
+ support multimedia experts who want to use Debian.
+ </para></listitem>
+</varlistentry>
+<varlistentry>
+ <term>LinEx</term>
+ <listitem><para>LinEx is the very successful distribution for schools in the
+ Region Extremadura in Spain. The work of the LinEx people
+ perhaps made Debian more popular than any other distribution.
+ The project was founded by the local government of
+ Extremadura, and each school in this region is running this
+ distribution. While this is a great success, the further
+ development of LinEx has to face the problems that will be
+ explained below. Because the creators of LinEx are aware of
+ this fact they started joining the educational part of LinEx
+ with Debian Edu which in turn leaded to an even stronger
+ position of this Blend.
+ </para></listitem>
+</varlistentry>
+</variablelist>
+</para>
+<para>
+If developers of a non-commercial fork consider integrating back into
+Debian in the form of a Debian Pure Blend, it might happen that their
+field is covered already by an existing Blend. For instance, this
+would be the case for LinEx, which has the same group of target users
+as Debian Edu as explained above. On the other hand, some special
+adaptations might be necessary to fit the requirements of the local
+educational system. The specific changes that might be necessary
+would be called <emphasis role="strong">flavours</emphasis> of a Blend.
+</para>
+ </sect2>
+
+ <sect2 id="disadvantages">
+ <title>Disadvantages of separate distribution</title>
+
+<para>
+In general, a separate distribution costs extra effort. Because it is
+hardly possible to hire enough developers who can double the great
+work of many volunteer Debian developers, this would be a bad idea for
+economical reasons. These people would have to deal with continuous
+changes to keep the base system, installer, etc. up to date with the
+current Debian development. It would be more sane to send patches that
+address their special requirements to Debian instead of
+maintaining a complete Debian tree containing these patches.
+</para>
+<para>
+Debian is well known for its strong focus on security. Security is
+mainly based on manpower and knowledge. So the best way to deal with
+security issues would be to base it on the Debian infrastructure,
+instead of inventing something new.
+</para>
+<para>
+New projects with special intentions often have trouble to become
+popular to the user group they want to address. This is a matter of
+attaining the critical mass that was explained in <xref linkend="general_problem" />.
+</para>
+<para>
+Larger Free Software projects need certain infrastructure like
+web servers, ftp servers, (both with mirrors,) a bug tracking system,
+etc. It takes a fair amount of extra effort to build an entire infrastructure
+that is already available for free in Debian.
+</para>
+<para>
+<emphasis role="strong">Forking would be a bad idea.</emphasis>
+</para>
+ </sect2>
+
+ <sect2 id="advantages">
+ <title>Advantages of integration into Debian</title>
+
+<para>
+Debian has a huge user base all over the world. Any project that is
+integrated within Debian has a good chance to become popular on the back
+of Debian if the target users of the project just notice that it
+enables them to solve their problems. So there is no
+need for extra research on the side of the users, and no need for
+advertising for a special distribution. This fact has been
+observed in the Debian Med project, which is well known for many
+people in medical care. It would not have gained this popularity if
+it had been separated from Debian.
+</para>
+<para>
+You get a secure and stable system without extra effort for free.
+</para>
+<para>
+Debian offers a sophisticated Bug Tracking System for free, which is a
+really important resource for development.
+</para>
+<para>
+There is a solid infrastructure of web servers, ftp servers with
+mirrors, mail servers, and an LDAP directory of developers with a strongly
+woven web of trust (through gpg key signing) for free.
+</para>
+</sect2>
+
+ <sect2>
+ <title>Enhancing Debian</title>
+
+<para>
+By making changes to some packages to make them fit the needs of a target
+user group, the overall quality of Debian can be enhanced. In this way,
+enhancing Debian by making it more user friendly is a good way for
+the community to give back something to Debian. It would be a shame
+if somebody would refuse all the advantages to keeping a project
+inside Debian, and instead would decide to try to cope with the disadvantages
+because he just does not know how to do it the right way, and that it is
+normally easy to propogate changes into Debian. For instance, see
+<xref linkend="howto_itp" />. This section explains how you can ask for
+a certain piece of software to be included in Debian.
+The next section describes the reason why Debian is flexible enough
+to be adapted to any purpose.
+</para>
+
+</sect2>
+</sect1>
+
+ <sect1>
+ <title>Adaptation to any purpose</title>
+
+<para>
+Debian is developed by about 1000 volunteers. Within this large group,
+the developers are encouraged to care for their own interests in packages
+they have chosen to look after. Thus, Debian is not bound to commercial
+interests.
+</para>
+<para>
+Those who might fear this amount of freedom given to every single developer
+should realize that there are very strict rules, as laid out in
+<ulink url="http://www.debian.org/doc/debian-policy/">Debian's policy</ulink>,
+which glue everything together. To keep their packages in each new
+release, every developer must ensure that their packages abide by that policy.
+</para>
+<para>
+One common interest each individual developer shares is to make the
+best operating system for himself. This way, people with similar
+interests and tasks profit from the work of single developers. If
+users, in turn, work together with the developers by sending patches or
+bug reports for further enhancement, Debian can be improved also for
+special tasks.
+</para>
+<para>
+For instance, developers may have children, or may work in some
+special fields of work, and so they try to make the best system for
+their own needs. For children, they contribute to Debian Jr. or
+Debian Edu. For their field of work, they contribute to the
+appropriate Blend: Debian Med, Debian Science, and so forth.
+</para>
+<para>
+In contrast to employees of companies, every single Debian developer
+has the freedom and ability to realize his vision. He is not bound to
+decisions of the management of his company. Commercial distributors
+have to aim their distributions at gaining a big market share. The
+commercial possibilities in targeting children's PCs at home are
+slight, so distributions comparable to Debian Junior are not attractive
+for commercial distributors to make.
+</para>
+<para>
+Thus, single developers have influence on development - they just have
+to <emphasis role="strong">do</emphasis> it, which is a very different position compared
+with employees of a commercial distributor. This is the reason for the
+flexibility of Debian that makes it adaptable for any purpose. In
+the Debian world, this kind of community is called
+"<emphasis><emphasis role="strong">Do</emphasis>ocracy</emphasis>" - the one who does, rules.
+</para>
+ </sect1>
+
+</chapter>
+
+
Added: blends/trunk/blends/doc/docbook-xml/fr/06_technology.xml
URL: http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/docbook-xml/fr/06_technology.xml?rev=2414&op=file
==============================================================================
--- blends/trunk/blends/doc/docbook-xml/fr/06_technology.xml (added)
+++ blends/trunk/blends/doc/docbook-xml/fr/06_technology.xml Tue Oct 26 16:58:17 2010
@@ -1,0 +1,901 @@
+<chapter id="technology">
+ <title>Technology</title>
+
+ <sect1 id="metapackages">
+ <title>Metapackages</title>
+
+ <sect2 id="defmetapackages">
+ <title>Metapackage definition</title>
+
+<para>
+A metapackage, as used by Blends, is a Debian package that contains:
+<itemizedlist>
+ <listitem><para>Dependencies on other Debian packages (essential)
+ <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>
+ </para></listitem>
+ <listitem><para>Menu entries (recommended)
+ <itemizedlist>
+ <listitem><para>Place these in <filename>/etc/blends/<varname><blend></varname>/menu/<varname><pkg-name></varname></filename></para></listitem>
+ <listitem><para>Maintain these via role based tools</para></listitem>
+ </itemizedlist>
+ </para></listitem>
+ <listitem><para>Configuration stuff (optional)
+ <itemizedlist>
+ <listitem><para><command>debconf</command> questions or pre-seeding</para></listitem>
+ <listitem><para><command>cfengine</command> scripts (or similar see <xref linkend="EnhancingTechnology" />)</para></listitem>
+ </itemizedlist>
+ </para></listitem>
+ <listitem><para>Special metapackages:
+ <itemizedlist>
+ <listitem><para><package><replaceable><blend></replaceable>-tasks</package>:
+ Contains information for <command>tasksel</command></para></listitem>
+ <listitem><para><package><replaceable><blend></replaceable>-config</package>:
+ Special configurations, basic stuff for user menus</para></listitem>
+ </itemizedlist>
+ </para></listitem>
+</itemizedlist>
+</para>
+<para>
+Metapackages are small packages with nearly no contents. The main
+feature of this type of package is its dependencies on other
+packages. The naming of metapackages follows the pattern
+<varname><blend></varname>-<varname><task></varname>
+where <varname><blend></varname> stands for the short name of a Debian
+Pure Blend, e.g. <package>junior</package> for Debian
+Jr. or <package>med</package> for Debian Med,
+and <varname><task></varname> means the certain task inside the Blend,
+e.g. puzzle or bio.
+</para>
+<para>
+Examples:
+<variablelist>
+ <varlistentry>
+ <term><package>junior-puzzle</package></term>
+ <listitem><para>Debian Jr. Puzzles</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><package>education-tasks</package></term>
+ <listitem><para>Tasksel files for SkoleLinux systems</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><package>med-bio</package></term>
+ <listitem><para>Debian Med micro-biology packages</para></listitem>
+ </varlistentry>
+</variablelist>
+</para>
+</sect2>
+
+ <sect2 id="collection">
+ <title>Collection of specific software</title>
+
+<para>
+When using metapackages, no research for available software inside Debian is
+necessary. It would not be acceptable for normal users to have to browse the
+descriptions of the whole list of the 20000 packages in Debian to find
+everything they need. So, metapackages are an easy method to help users to
+find the packages that are interesting for their work quickly.
+</para>
+<para>
+If the author of a metapackage includes several packages with similar
+functionality, an easy comparison between software covering the same task is
+possible.
+</para>
+<!-- This is not true any more since we turn Depends into Recommends
+ to explicitely *enable* users to remove certain packages.
+
+Moreover, the installation of a metapackage ensures that no package
+that is necessary for the intended task can be removed without
+explicit notice that also the metapackage has to be removed. This
+helps non specialist administrators to keep the installation fit for
+the specialized users.
+ -->
+<para>
+By defining conflicts with some other packages inside the metapackage,
+it is possible to ensure that a package that might conflict for some
+reasons for the intended task can not be installed at the same time as
+the metapackage is installed.
+</para>
+<para>
+All in all, metapackages enable an easy installation from scratch, and
+keep the effort required for administration low.
+</para>
+</sect2>
+ <sect2 id="categorisation">
+ <title>Packages showing up in more than one metapackage</title>
+
+<para>
+This seems to be an FAQ: If a package <package>A</package> is in the list of
+dependencies of metapackage <package>m</package> is it allowed or reasonable to
+add it to the list of dependencies of metapackage <package>n</package>?
+</para>
+<para>
+The answer is: Why not?
+</para>
+<para>
+The "overlap" is no problem because we do not want to build
+an exclusive categorisation which might be hard to understand for our
+users. Metapackages are like "normal" packages: Nobody
+would assume that because package <package>x</package> depends from package
+<package>libc</package> no other package is allowed to add <package>libc</package> to its
+depends. So why not adding a dependency to more than one metapackage if
+it is just useful for a certain task?
+</para>
+<para>
+The important thing is to support our users. A specific user wants to
+solve a certain task (and thus installs a certain metapackage). The
+question whether some Dependencies are also mentioned in a different
+metapackage is completely useless for this task. So in fact we do
+<emphasis role="strong">not</emphasis> build a categorisation tree but build pools of useful
+software for certain tasks which can definitely have overlaps.
+</para>
+<para>
+To give a certain example which was asked by a member of Debian
+Multimedia team: A user who is seeking for his optimal sound player is
+not served best if we "hide" an application from his view by
+including it into sound recorders exclusively. While chances might be
+good that a sound recorder is not as lightweight as a pure player the
+user will find out this quickly if he is looking for only a
+lightweight player - but perhaps he becomes happy later about the
+"added value" of his favourite player if it also is able to record
+sound.
+</para>
+
+ </sect2>
+
+ <sect2 id="configuration">
+ <title>Adapted configuration inside metapackages</title>
+
+<para>
+Besides the simplification of installing relevant packages by
+dependencies inside metapackages, these packages might contain special
+configuration for the intended task. This might either be
+accomplished by pre-seeding <command>debconf</command> questions, or by
+modifying configuration files in a <command>postinst</command> 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
+<command>postinst</command> script takes over the role of a local
+administrator.
+<!-- FIXME:
+ An improved version of the pre-seeding scripts are included in newer
+ debconf versions. I just replaced the debian-edu scripts with the
+ scripts from debconf. Look at debconf-set-selections and
+ debconf-get-selections.
+ -->
+</para>
+
+ </sect2>
+
+ <sect2 id="documentation">
+ <title>Documentation packages</title>
+
+<para>
+A "traditional" weakness of Free Software projects is missing
+documentation. To fix this, Debian Pure Blends try to provide
+relevant documentation to help users to solve their problems. This
+can be done by building <package>*-doc</package> packages of existing
+documentation, and by writing extra documentation, like manpages, etc.
+By supplying documentation, Debian Pure Blends fulfil their role in
+addressing the needs of specialised users, who have a great need for
+good documentation in their native language.
+</para>
+<para>
+Thus, translation is a very important thing to make programs more
+useful for the target user group. Debian has established
+a <ulink url="http://ddtp.debian.net/" >Debian Description
+Translation Project</ulink>, which has the goal to translate package
+descriptions. There is a good chance this system could also be used
+for other types of documentation, which might be a great help for
+Debian Pure Blends.
+</para>
+
+ </sect2>
+ </sect1>
+
+ <sect1 id="mp_handling">
+ <title>Handling of metapackages</title>
+
+<para>
+<!-- [BA] I think we need to qualify what 'handle' means, because there
+ certainly are other tools that 'handle' them (e.g. synaptic) if that term
+ is taken in its broadest sense.
+ [AT] ACK, here that we have to define 'handle'. The term
+ 'nicely' was intended to be the keyword because metapackages are
+ currently handled as any other package which is fine, but no help
+ for users who do not know anything about metapackages. We need
+ special tools to gain all profits we could have. Could you set
+ this into good English???
+ -->
+In short, there are no special tools available to handle metapackages
+nicely. But there are some tricks that might help, for the moment.
+</para>
+
+ <sect2 id="cmdline">
+ <title>Command line tools</title>
+
+<para>
+<variablelist>
+ <varlistentry>
+ <term><command>apt-cache</command></term>
+ <listitem><para>
+ The program <command>apt-cache</command> is useful to search for
+ relevant keywords in package descriptions. With it, you could search
+ for a certain keyword connected to your topic (for instance
+ "<package>med</package>") and combine it reasonably with <command>grep</command>:
+ <programlisting language="shell">
+<![CDATA[
+~> apt-cache search med | grep '^med-'
+med-bio - Debian Med micro-biology packages
+med-bio-dev - Debian Med micro-biology development packages
+med-doc - Debian Med documentation packages
+med-imaging - Debian Med imaging packages
+med-imaging-dev - Debian Med packages for medical image develop...
+med-tools - Debian Med several tools
+med-common - Debian Med Project common package
+med-cms - Debian Med content management systems
+]]>
+ </programlisting>
+ This is <emphasis role="strong">not really straightforward</emphasis>, and
+ absolutely unacceptable for end users.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><command>grep-dctrl</command></term>
+ <listitem><para>
+ The program <command>grep-dctrl</command> is a grep for Debian package
+ information, which is helpful for extracting specific package details
+ matching certain patterns:
+ <programlisting language="shell">
+<![CDATA[
+~> grep-dctrl ': med-' /var/lib/dpkg/available | \
+ grep -v '^[SIMAVF]' | \
+ grep -v '^Pri'
+Package: med-imaging
+Depends: paul, ctsim, ctn, minc-tools, medcon, xmedcon, med-common
+Description: Debian Med imaging packages
+
+Package: med-bio
+Depends: bioperl, blast2, bugsx, fastdnaml, fastlink, garlic...
+Description: Debian Med micro-biology packages
+
+Package: med-common
+Depends: adduser, debconf (>= 0.5), menu
+Description: Debian Med Project common package
+
+Package: med-tools
+Depends: mencal, med-common
+Description: Debian Med several tools
+
+Package: med-doc
+Depends: doc-linux-html | doc-linux-text, resmed-doc, med-co...
+Description: Debian Med documentation packages
+
+Package: med-cms
+Depends: zope-zms
+Description: Debian Med content management systems
+
+Package: med-imaging-dev
+Depends: libgtkimreg-dev, ctn-dev, libminc0-dev, libmdc2-dev...
+Description: Debian Med packages for medical image development
+
+Package: med-bio-contrib
+Depends: clustalw | clustalw-mpi, clustalx, molphy, phylip, ...
+Description: Debian Med micro-biology packages (contrib and ...
+]]>
+ </programlisting>
+ This is, like the <command>apt-cache</command> example, <emphasis role="strong">also
+ a bit cryptic</emphasis>, and again is not acceptable for end users.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><command>auto-apt</command></term>
+ <listitem><para>
+ The program <command>auto-apt</command> 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
+ <command>auto-apt</command> in the following manner to guarantee that you
+ have all of the files or programs you need:
+ <programlisting language="shell">
+<![CDATA[
+~> sudo auto-apt update
+put: 880730 files, 1074158 entries
+put: 903018 files, 1101981 entries
+~> auto-apt -x -y run
+Entering auto-apt mode: /bin/bash
+Exit the command to leave auto-apt mode.
+bash-2.05b$ less /usr/share/doc/med-bio/copyright
+Reading Package Lists... Done
+Building Dependency Tree... Done
+The following extra packages will be installed:
+ bugsx fastlink readseq
+The following NEW packages will be installed:
+ bugsx fastlink med-bio readseq
+0 packages upgraded, 4 newly installed, 0 to remove and 183 ...
+Need to get 0B/1263kB of archives. After unpacking 2008kB wi...
+Reading changelogs... Done
+Selecting previously deselected package bugsx.
+(Reading database ... 133094 files and directories currently...
+Unpacking bugsx (from .../b/bugsx/bugsx_1.08-6_i386.deb) ...
+Selecting previously deselected package fastlink.
+Unpacking fastlink (from .../fastlink_4.1P-fix81-2_i386.deb) ...
+Selecting previously deselected package med-bio.
+Unpacking med-bio (from .../med-bio_0.4-1_all.deb) ...
+Setting up bugsx (1.08-6) ...
+
+Setting up fastlink (4.1P-fix81-2) ...
+
+Setting up med-bio (0.4-1) ...
+
+localepurge: checking for new locale files ...
+localepurge: processing locale files ...
+localepurge: processing man pages ...
+This package is Copyright 2002 by Andreas Tille <tille at debian.org>
+
+This software is licensed under the GPL.
+
+On Debian systems, the GPL can be found at /usr/share/common-...
+/usr/share/doc/med-bio/copyright
+]]>
+ </programlisting>
+ Just do your normal business - in the above example, <command>less
+ /usr/share/doc/med-bio/copyright</command> - and if the necessary
+ package is not yet installed, <command>auto-apt</command> will care for
+ the installation and proceed with your command. While this is
+ really cool, this is <emphasis role="strong">not really intended for a production
+ machine</emphasis>.
+ </para></listitem>
+ </varlistentry>
+</variablelist>
+
+The short conclusion here is: <emphasis role="strong">There are no sophisticated tools
+that might be helpful to handle metapackages as they are used in
+Debian Pure Blends - just some hacks using the powerful tools inside
+Debian.</emphasis>
+</para>
+
+ </sect2>
+
+ <sect2 id="text_ui">
+ <title>Text user interfaces</title>
+<para>
+<variablelist>
+ <varlistentry>
+ <term><command>tasksel</command></term>
+ <listitem>
+ <para>
+ The Debian task installer <command>Tasksel</command> is the first
+ interface for package selection that is presented to the user when
+ installing a new computer. The <varname>End-user</varname> section should
+ contain an entry for each Debian Pure Blend.
+ Unfortunately, there are some issues that prevent Blends
+ from being included in the <command>tasksel</command> list,
+ because the dependencies of this task can affect what appears on
+ the first installation CD. This problem would be even greater if
+ all Blends were added, and so a different solution has
+ to be found here. (See <ulink url="http://bugs.debian.org/186085"
+ >#186085</ulink>.) In principle, <command>tasksel</command> is a good
+ tool for easy installation of Blends.
+ </para>
+ <para>
+ As a workaround for this problem the <command>blends-dev</command>
+ framework creates a package <package>BLEND-tasks</package> which contains
+ a <command>tasksel</command> control file. If you install this package
+ all tasks of the Blend will be added to the default list of tasks
+ inside <command>tasksel</command>. So a solution for Blend specific
+ installation media might be to just remove the default tasksel
+ list and provide the Blends own tasks exclusively.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><command>aptitude</command></term>
+ <listitem><para>
+ This is a better replacement for <command>dselect</command>, and has
+ some useful support for searching for and grouping of packages.
+ While this is not bad, it was not intended for the purpose of
+ handling Debian Pure Blends, and thus there could be some better
+ support to handle metapackages more cleverly.
+ </para></listitem>
+ </varlistentry>
+</variablelist>
+Short conclusion: <emphasis role="strong">There is a good chance metapackages could be
+handled nicely by the text based Debian package administration tools,
+but this is not yet implemented.</emphasis>
+</para>
+
+ </sect2>
+
+ <sect2 id="gui">
+ <title>Graphical user interfaces</title>
+<para>
+Debian <emphasis>Woody</emphasis> does not contain a really nice graphical
+user interface for the Debian package management system. But the
+efforts to support users with an easy to use tool have increased, and
+so there there will be some usable options in Sarge.
+<variablelist>
+ <varlistentry>
+ <term><command>gnome-apt</command></term>
+ <listitem><para>This is the native GNOME flavour of graphical user interfaces
+ to apt. It has a nice <command>Search</command> 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 "<varname>junior-*</varname>" will show
+ up all related packages including their descriptions. This
+ will give a reasonable overview about metapackages of the
+ project.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><command>synaptic</command></term>
+ <listitem><para>Even more sophisticated and perhaps the best choice for users
+ of Debian Pure Blends. <command>Synaptic</command> has a nice
+ filter feature, which makes it a great tool here.
+ Moreover <command>synaptic</command> is currently the only user
+ interface that supports Debian Package Tags
+ (see <xref linkend="debtags" />).
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><command>kpackage</command></term>
+ <listitem><para>This is the user interface of choice for KDE lovers.
+ Regarding its features (with exception of Debian Package Tags)
+ it is similar to both above.
+ </para></listitem>
+ </varlistentry>
+</variablelist>
+Short conclusion: <emphasis role="strong">As well as the text based user interfaces
+these tools are quite usable but need enhancements to be regarded as
+powerful tools for Debian Pure Blends.</emphasis>
+</para>
+ </sect2>
+
+ <sect2 id="web_if">
+ <title>Web interfaces</title>
+
+<para>
+<variablelist>
+ <varlistentry>
+ <term>Tasks pages</term>
+ <listitem><para>
+ The tasks pages probably provide the best overview about
+ the actual work which is done in a Debian Pure Blend. These
+ pages are automatically generated by reading the tasks files
+ (see <xref linkend="debian_control" />) and verifying the existence
+ of the packages that are mentioned as dependencies. On the
+ resulting web page the packages are listed with some meta
+ information and the description of the package. As user
+ oriented pages they are translated into more than 10
+ languages while translated means, the navigation text of the
+ page generating code is using <command>gettext</command> which
+ enables translation (the work is not yet completely done for
+ all languages) but even more importantly the descriptions of
+ the packages are translated as well by using the information
+ from
+ <ulink url="http://ddtp.debian.net/" >Debian Description
+ Translation Project</ulink>.
+ </para>
+ <para>These tasks pages are available via
+ <command>
+ http://blends.alioth.debian.org/BLEND/tasks
+ </command>
+ where <varname>BLEND</varname> has to be replaced by the name of the
+ Blend. Currently these pages are available for the Blends:
+ <command>
+ accessibility, edu, gis, junior, lex, science, debichem
+ </command>
+ The tasks pages are available for Debian Med as well but for
+ historical reasons the URL for these pages is
+ <command>
+ http://debian-med.alioth.debian.org/tasks
+ </command>
+ In short: If you want to know more about a specific Blend
+ go to its task page and have a look what is listed there.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Bugs pages</term>
+ <listitem><para>The more developer oriented bugs pages try to match the
+ scope of the tasks pages mentioned above but there is no
+ description of the packages given but rather the bugs that
+ are reported in the Debian Bug Tracking System (BTS) are
+ listed there. This is a quite valuable source of information
+ if somebody is interested in increasing the quality of a
+ Blend: Fixing bugs is always welcome and listing all relevant
+ bugs at a single place is a nice way to detect problems
+ quickly.
+ </para>
+ <para>These bugs pages are available via
+ <programlisting language="shell">
+ http://blends.alioth.debian.org/BLEND/bugs
+ </programlisting>
+ where <varname>BLEND</varname> has to be replaced by the name of the
+ Blend. Currently these pages are available for the Blends:
+ <programlisting language="shell">
+ accessibility, edu, gis, junior, lex, science, debichem
+ </programlisting>
+ The bugs pages are available for Debian Med as well but for
+ historical reasons the URL for these pages is
+ <programlisting language="shell">
+ http://debian-med.alioth.debian.org/bugs
+ </programlisting>
+ In short: If you want to help enhancing the quality of a
+ specific Blend go to its bug page and start working on the
+ bugs listed there.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><ulink url="http://packages.debian.org/" >Web search</ulink></term>
+ <listitem><para>Debian has a web interface that can be used to search for certain substrings
+ in package names. For instance if you are searching the meta
+ packages of Debian Med you could point your favourite Browser
+ to</para>
+ <para>
+<!-- FIXME: & is sometimes broken!!!
+<ulink url="http://packages.debian.org/cgi-bin/search_packages.pl?keywords=med-&subword=1">
+ ^^^^^
+-->
+<ulink url="http://packages.debian.org/cgi-bin/search_packages.pl?keywords=med-&subword=1">http://packages.debian.org/cgi-bin/search_packages.pl?keywords=med-&subword=1</ulink>
+ As a result you will get a list of all Debian Med packages.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><ulink url="http://qa.debian.org/developer.php" >Package Tracking System</ulink></term>
+ <listitem><para>
+ The Package Tracking System is a really great tool that
+ provides essential information about packages. Most Debian
+ Pure Blends are using a mailing list address as Maintainer of
+ their key packages which includes the metapackages. This so
+ called team maintenance of packages is on one hand very handy
+ from a developers point of view on the other hand it enables
+ using the Package Tracking System to get a quick overview:
+ <variablelist>
+ <varlistentry>
+ <term>Debian Jr:</term>
+ <listitem><para>
+ <ulink url="http://qa.debian.org/developer.php?login=debian-jr@lists.debian.org">http://qa.debian.org/developer.php?login=debian-jr@lists.debian.org</ulink>
+ </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">http://qa.debian.org/developer.php?login=debian-med-packaging@lists.alioth.debian.org</ulink>
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Debian Edu:</term>
+ <listitem><para>
+ <ulink url="http://qa.debian.org/developer.php?login=debian-edu@lists.debian.org">http://qa.debian.org/developer.php?login=debian-edu@lists.debian.org</ulink>
+ </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">http://qa.debian.org/developer.php?login=debian-science-maintainers@lists.alioth.debian.org</ulink>
+ </para></listitem>
+ </varlistentry>
+ </variablelist>
+ Hint: If you append the option <command>&ordering=3</command> you
+ might get some sectioning of this page according to the
+ metapackage categories. This result is approached by a tool
+ which subscribes all dependent packages to the group
+ maintenance address and adds a section according to a
+ metapackage name.
+ </para>
+ <para>
+ The other way to use the Package Tracking System is to search
+ for packages starting with a certain letter:
+ <variablelist>
+ <varlistentry>
+ <term>Debian Jr:</term>
+ <listitem><para>
+ <ulink url="http://packages.qa.debian.org/j">
+ http://packages.qa.debian.org/j
+ </ulink>
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Debian Med:</term>
+ <listitem><para>
+ <ulink url="http://packages.qa.debian.org/m">
+ http://packages.qa.debian.org/m
+ </ulink>
+ </para></listitem>
+ </varlistentry>
+ </variablelist>
+ But the list that is obtained by this method is much larger
+ than it would be useful for a good overview.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><command>list-junior.sh</command></term>
+ <listitem><para>The package <package>junior-doc</package> contains a script
+ <filename>/usr/share/doc/junior-doc/examples/scripts/list-junior.sh</filename>
+ that checks for the installed packages of a Blend and builds
+ a simple web page describing these packages. (The BTS
+ contains a patch to let this script work also for other
+ Blends.)
+ </para></listitem>
+ </varlistentry>
+</variablelist>
+Short conclusion: <emphasis role="strong">The Debian Pure Blends provide some nice web
+ tools for a whole set of packages for a certain working field that
+ provide a better overview than the usual Debian tools that are
+ basically dealing with single packages..</emphasis>
+</para>
+ </sect2>
+
+ <sect2 id="future_handling">
+ <title>Future handling of metapackages</title>
+
+<para>
+Obviously there are no nifty tools as you might know them from Debian
+available yet. The user interfaces for <command>apt-get</command> have to be
+enhanced drastically to make them easy enough to make them useful in
+the hands of an end user. This might implicitly mean that we need
+some additional control fields in <package>dpkg</package> to implement
+reasonable functionality. The following items are target of future
+development:
+<itemizedlist>
+ <listitem><para>Searching for existing metapackages</para></listitem>
+ <listitem><para>Overview about dependencies of these metapackages</para></listitem>
+ <listitem><para>Enhancing tools like <command>aptitude</command>,
+ <command>synaptic</command>, etc.</para></listitem>
+ <listitem><para>Special <command>tasksel</command> section</para></listitem>
+ <listitem><para>Web tools that keep metapackage information up to
+ date</para></listitem>
+</itemizedlist>
+</para>
+<para>
+Furthermore it is necessary to find a set of keywords for each Debian
+Pure Blend and write a tool to search these keywords comfortable. The
+best way to accomplish this might be to make use of Debian Package
+Tags, which is a quite promising technique.
+</para>
+<para>
+Tools that grep the apt cache directly for metapackages have to be
+written or rather the available tools for this should be patched for
+this actual functionality.
+</para>
+ </sect2>
+ </sect1>
+
+ <sect1 id="userroles">
+ <title>User roles</title>
+
+<para>
+As stated above specialists have only interest in a subset of the
+available software on the system they are using. In an ideal world, this
+would be the only software that is presented in the menu. This would
+allow the user to concentrate on his real world tasks instead of
+browsing large menu trees with entries he does not understand.
+</para>
+<para>
+To accomplish this, a technique has to be implemented that allows to
+define a set of users who get a task-specific menu while getting rid
+of the part of software they are not interested in. Moreover this has
+to be implemented for certain groups of users of one Blend, which are
+called "roles". There are several techniques available to manage user
+roles. Currently in the field of Debian Pure Blends a UNIX group
+based role system is implemented. This means, that a user who belongs
+to a certain group of a Blend is mentioned in
+the <filename>/etc/group</filename> file in the appropriate group and gets a
+special user menu that is provided for exactly this group.
+</para>
+<para>
+Strictly speaking it is not the best solution to conflate a
+configuration mechanism, which users see with menus, with access
+control, i.e. unix groups. It might be confusing, and wastes the limited
+number of groups to which a user can belong. On the other hand this
+is a solution that works for the moment, and has no real negative
+impact on the general use of the system. The benefit of using unix
+groups is that there is a defined set of tools provided to handle user
+groups. This makes life much easier; there is no
+<emphasis>practical</emphasis> limit to the number of groups to which a user may
+belong for the existing Debian Pure Blends at this time.
+</para>
+<para>
+In the long run, this role system might even be enhanced to certain
+"<emphasis>levels</emphasis>" a user can have and here the UNIX groups approach
+will definitely fail and has to be replaced by other mechanisms. This
+will include the possibility to enable the user adjust his own level
+("novice", "intermediate", "expert") while only the administrator is
+able to access the UNIX groups. On the other hand such kind of user
+level maintenance is not only a topic for Debian Pure Blends but might
+be interesting for Debian in general.
+</para>
+<para>
+Another point that speaks against using UNIX groups for role
+administration is the fact that local administrators are not in all
+cases competent enough to understand the UNIX role concept as a
+security feature and thus a real role concept including tools to
+maintain roles are needed in the future.
+</para>
+<para>
+The handling of the user menus according to the groups is implemented
+in a flexible plugin system and other ways of handling groups
+(i.e. LDAP) should be easy to implement.
+</para>
+
+ <sect2 id="menu_tools">
+ <title>User menu tools</title>
+
+ <sect3 id="user-menus">
+ <title>Using the Debian menu system</title>
+<para>
+The Debian menu system cares for menu updates after each package
+installation. To enable compliance with the <emphasis>role</emphasis> based menu
+approach it is necessary to rebuild the user menu after each package
+installation or after adding new users to the intended role. This can
+be done by using the
+<citerefentry><refentrytitle>blend-update-menus</refentrytitle>
+<manvolnum>8</manvolnum></citerefentry>
+(see <xref linkend="blend-update-menus" />) script from
+<package>blends-common</package>. It has to be said that using
+<command>blend-update-menus</command> is not enough to change the menu of a
+user. To accomplish this a call of the general
+<command>update-menu</command> script for every single user of a Blend is
+necessary if this is not done by the
+<filename>postinst</filename> script of a metapackage. This can easily been
+done if the configuration file of a Debian Pure Blend
+<filename>/etc/blends/<varname><blend></varname>/<varname><blend></varname>.conf</filename> contains the
+line
+<programlisting language="shell">
+<![CDATA[
+ UPDATEUSERMENU=yes
+]]>
+</programlisting>
+
+</para>
+<para>
+It is strongly suggested to use the
+package <package>blends-dev</package> to build metapackages of a
+Debian Pure Blend that will move all necessary files right into place
+if there exists a
+<filename>menu</filename> directory with the menu entries. Note, that the users
+<filename>${HOME}/.menu</filename> directory remains untouched.
+</para>
+ </sect3>
+
+ <sect3 id="user-debconf">
+ <title>Managing Debian Pure Blend users with <command>debconf</command></title>
+
+<para>
+Using <package>blends-dev</package> it is very easy to build a
+<varname>blend</varname><package>-config</package> package that contains
+<command>debconf</command> 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.
+
+ <programlisting language="shell">
+<![CDATA[
+~> dpkg-reconfigure med-common
+
+Configuring med-common
+----------------------
+
+Here is a list of all normal users of the system. Now you can select those users who
+should get a Debian Med user menu.
+
+ 1. auser (normal user A) 6. fmeduser (med user F)
+ 2. bmeduser (med user B) 7. glexuser (lex user G)
+ 3. cjruser (jr user C) 8. hmeduser (med user H)
+ 4. djruser (jr user D) 9. iadmin (administrator I)
+ 5. eadmin (administrator E) 10. juser (normal user J)
+
+(Enter the items you want to select, separated by spaces.)
+
+:-! Please specify the Debian Med users! 2 8
+]]>
+ </programlisting>
+This example shows the situation when you
+<command>dpkg-reconfigure</command> <package>med-common</package> if
+<varname>med user B</varname> and <varname>med user H</varname> were defined as users
+of Debian Med previously and <varname>med user F</varname> should be added to
+the group of medical staff. (For sure it is more convenient to use the
+more comfortable interfaces to <package>debconf</package> but the used
+SGML DTD <ulink url="http://bugs.debian.org/140684" >does not yet
+ support screen shots</ulink>.)
+</para>
+ </sect3>
+ </sect2>
+ </sect1>
+
+ <sect1 id="devtools">
+ <title>Development tools</title>
+
+<para>
+Building a metapackage is more or less equal for each meta
+package. This was the reason to build a common source package
+<package>blend</package> that builds into two binary packages
+<variablelist>
+ <varlistentry>
+ <term><package>blends-dev</package></term>
+ <listitem><para>Helpful tools to build metapackages from a set of template
+ files. These tools are interesting for people who want to
+ build metapackages in the style Debian Edu and Debian Med
+ are currently doing this. The purpose of this package is to
+ make maintenance of metapackages as easy as possible.</para>
+ <para>This package is described in detail in appendix <xref
+ linkend="blends-dev" />.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><package>blends-common</package></term>
+ <listitem><para>This package provides some files that are common to meta
+ packages of Debian Pure Blends especially those that were
+ built using the tools of the package
+ <package>blends-dev</package>. It introduces a method to handle
+ system users in a group named according to the name of the
+ Blend. The user menu approach is explained in detail
+ in <xref linkend="userroles" />.</para>
+ <para>This package is described in detail in appendix <xref
+ linkend="blends-common" />.
+ </para></listitem>
+ </varlistentry>
+</variablelist>
+The usage of the tools that are contained in these packages are
+described now in detail.
+</para>
+</sect1>
+ <sect1 id="othertools">
+ <title>Other interesting tools</title>
+
+ <sect2 id="simple-cdd">
+ <title>Simple-CDD</title>
+
+<para>
+The tool <command>simple-cdd</command> is a limited though relatively easy
+tool to create a customized debian-installer CD.
+</para><para>
+It includes simple mechanisms to create "profiles" that define common
+system configurations, which can be selected during system
+installation. <command>Simple-cdd</command> also makes it easy to build CDs
+with language and country settings pre-configured, or to use a 2.6
+kernel by default.
+</para><para>
+This can be used to create a crude "Debian Pure Blend" using
+packages from Debian, with pre-configuration of packages that use
+<command>debconf</command>. Custom configuration scripts can be specified
+to handle packages that don't support <command>debconf</command>
+pre-configuration.
+</para><para>
+Testing CD images with <command>qemu</command> is also made simple with a
+provided script.
+</para><para>
+It has only been tested with <command>debian-cd</command> from Etch (other
+than <command>debpartial-mirror</command>), so if using a new
+<command>debian-cd</command> or <command>debian-installer</command>, it may
+require some tweaks.
+</para>
+ </sect2>
+ </sect1>
+</chapter>
+
+
+
Added: blends/trunk/blends/doc/docbook-xml/fr/07_starting.xml
URL: http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/docbook-xml/fr/07_starting.xml?rev=2414&op=file
==============================================================================
--- blends/trunk/blends/doc/docbook-xml/fr/07_starting.xml (added)
+++ blends/trunk/blends/doc/docbook-xml/fr/07_starting.xml Tue Oct 26 16:58:17 2010
@@ -1,0 +1,417 @@
+<chapter id="starting">
+ <title>How to start a Debian Pure Blend</title>
+
+<para>
+This chapter is based on the Debian Subproject HOWTO, which was
+written by Ben Armstrong <email>synrg at debian.org</email>.
+</para>
+
+ <sect1 id="planning">
+ <title>Planning to form a Debian Pure Blend</title>
+
+ <para>
+ In this section, issues to think about before starting a Debian Pure
+ Blend will be discussed. It is important to have a clear idea where
+ to head and how to get there before launching into this adventure.
+ </para>
+
+ <sect2 id="leadership">
+ <title>Leadership</title>
+ <para>
+ The existing Debian Pure Blends have clearly shown that they depend
+ on a person who keeps things running. If anybody wants to start a
+ project at first, he has to answer the question:
+ <emphasis>"Am I the right person for the job?"</emphasis> Surely this is a
+ question that may be faced with some amount of uncertainty. The way
+ Debian Pure Blends started in the past was for the person with the
+ idea for the project to just start doing the work. After some time
+ using this approach, it became clear that if the project lacked a
+ person to take leadership, the project would become stale. So the
+ initiator has to answer the question clearly, whether or not he is
+ able to continue in the <emphasis>job</emphasis> of leader, considering the
+ amount of time he will have to spend, and the technical and social
+ skills which are needed.
+ </para>
+ </sect2>
+
+ <sect2 id="defining_scope">
+ <title>Defining the scope of the Blend</title>
+ <para>
+ It is as important to decide what your group is not going to do as
+ it is what it is going to do. A clear borderline is essential for
+ the development of the project. Without it, outsiders might
+ either expect more from the project than it can accomplish, or may ignore
+ the project, finding it not helpful because they are
+ not able to find out the purpose.
+ </para>
+ <para>
+ By maintaining a good relationship with other Free Software projects,
+ some common tasks can be done very effectively. When efforts can be
+ shared, the amount of work for each project can be reduced.
+ </para>
+ <para>
+ Checking for cooperation with other Debian Pure Blends is always a
+ good idea. In technical terms, this is obvious, but sometimes there
+ are possibilities to share efforts when the goals of two projects
+ have parts in common.
+ </para>
+ <para>
+ The one who decides to start a Debian Pure Blend takes on a
+ responsibility for this project. It has to be for the good of
+ Debian as a whole, and should bring an extra reputation to our
+ common goal to build the best operating system.
+ </para>
+ </sect2>
+
+ <sect2 id="initial_discussion">
+ <title>Initial discussion</title>
+ <para>
+ By the time you have begun to think about forming the subproject,
+ have made the commitment to lead it, and have sketched out a
+ bit of where you want to go and how you'll get there, you have
+ likely already done some informal discussion with your peers.
+ It is time, if you haven't already, to take these ideas to the
+ broader Debian developer community, opening discussion on the
+ creation of your group.
+ </para>
+
+ <sect3 id="calling_all_developers">
+ <title>Calling all developers</title>
+ <para>
+ At this stage, you will want to reach as broad an audience as possible.
+ You have carefully thought out what you're going to do, and are able
+ to articulate it to Debian as a whole. Let everyone know through
+ the <email>debian-devel-announce at lists.debian.org</email> mailing
+ list, setting the <command>Reply-to:
+ </command><email>debian-devel at lists.debian.org</email> and listen to what
+ everyone has to say about your idea. You may learn some valuable
+ things about pitfalls that may lie ahead for your group. Maybe even
+ show-stoppers at that. You may also find a number of like-minded
+ individuals who are willing to join your group and help get it
+ established.
+ </para>
+ </sect3>
+
+ <sect3 id="steering_the_discussion">
+ <title>Steering the discussion</title>
+ <para>
+ It's all too easy to get lost in ever-branching-out sub-threads at
+ this point. Many people will be firing off ideas left, right and
+ centre about what your group should do. Don't worry too much about
+ containing the discussion and keeping it on track with your main
+ idea. You would rather not squelch enthusiasm at this point. But
+ do try to steer the discussion a bit, focusing on the ideas that
+ are central to your subproject and not getting lost in the details.
+ </para>
+ <para>
+ At some point, you'll decide you've heard enough, and you're ready
+ to get down to the business of starting your group.
+ </para>
+ </sect3>
+
+ </sect2>
+
+</sect1>
+
+<sect1 id="setting_up">
+ <title>Setting up</title>
+
+<sect2>
+ <title>Mailing list</title>
+ <para>
+ It is fairly important to enable some means for communication for
+ the project. The most natural way to do this is with a mailing
+ list.
+ </para>
+ <para>
+ Creating a new mailing list starts with a wishlist bug against
+ <varname>lists.debian.org</varname>. The format of this
+ bug has to follow
+ <ulink url="http://www.debian.org/MailingLists/HOWTO_start_list"
+ >certain rules</ulink>.
+ </para>
+ <para>
+ Before your list can be created, the listmasters will want assurance
+ that creation of the list is, in fact, necessary. So for this
+ reason, don't wait for your list to be created. Start discussing
+ your new project on <email>debian-devel at lists.debian.org</email>
+ immediately. To help distinguish your project's posts from the
+ large amount of traffic on this list, tag them in the Subject field
+ with an agreed-upon tag. An example bug report to create the
+ relevant list is bug
+ <ulink url="http://bugs.debian.org/237017" >#237017</ulink>.
+ </para>
+ <para>
+ When sufficient discussion on the developer's list has
+ taken place and it is time to move it to a subproject list,
+ add to your wishlist bug report some URLs pointing to these
+ discussions in the archives as justification for creation of
+ your list.
+ </para>
+</sect2>
+
+<sect2>
+ <title>Web space</title>
+ <para>
+ A simple possibility, and one which is fairly attractive because it
+ facilitates collaborative web site creation and maintenance, is to
+ put a page on the <ulink url="http://wiki.debian.org">Wiki</ulink>.
+ There is a
+ special <ulink url="http://wiki.debian.org/index.cgi?DebianPureBlends"
+ >Wiki page for Debian Pure Blends</ulink>.
+ </para>
+ <para>
+ A good place to put static web pages or even PHP code is the common
+ place on Alioth for all
+ Blends: <ulink url="http://blends.alioth.debian.org">http://blends.alioth.debian.org</ulink>. There is a
+ subdirectory for each Blend and it is very easy to create a simple
+ index page there which points to the automatically generated web
+ pages which are mentioned in <xref linkend="web_if" />. Following this
+ strategy is quite cheap and has a big effect when using the tools
+ provided by the Debian Pure Blends effort.
+ </para>
+ <para>
+ Sooner or later a Debian Pure Blend will establish an own project at
+ <ulink url="http://alioth.debian.org" >alioth.debian.org</ulink>, since
+ this enables many features for group maintaining packages, create
+ mailing lists for different purposes, maintain a version control
+ system like SVN or Git etc. The Alioth project enables to provide
+ web sites as well and the Debian Med project is using this since a
+ long time.
+ </para>
+ <para>
+ Finally, the best way is to have a page
+ under <ulink url="http://www.debian.org/devel">http://www.debian.org/devel</ulink>. While not as
+ straightforward as any of the other options, this approach has its
+ advantages. First, the site is mirrored everywhere. Second, the
+ Debian web site translators translate pages into many different
+ languages, reaching new potential audiences for your Debian Pure
+ Blend, and improving communication with other members of your
+ project and interested parties for whom English is not their most
+ comfortable language. Third, a number of templates are available to
+ make your site more integrated with the main web site, and to assist
+ with incorporating some dynamic content into your site. Before you
+ join the Debian Web team you
+ should <ulink url="http://www.debian.org/devel/website" >http://www.debian.org/devel/website</ulink>learn
+ more about building Debian web pages.
+ </para>
+ <para>
+ Once this is done, the Debian web pages team should be contacted via
+ the mailing list <email>debian-www at lists.debian.org</email> to add the
+ project to the <ulink url="http://www.debian.org/intro/organization"
+ >organisation page</ulink>.
+ </para>
+</sect2>
+
+<sect2>
+ <title>Repository</title>
+ <para>
+ On <ulink url="http://alioth.debian.org/" >alioth.debian.org</ulink> a
+ <ulink url="http://gforge.org/" >Gforge</ulink>-site is running to host
+ all Debian related project work. Creating a project on Alioth is a
+ good idea to start teamwork on the code a Debian Pure Blend is
+ releasing.
+ </para>
+</sect2>
+
+<sect2>
+ <title>Formal announcement</title>
+ <para>
+ Once there is a list, or at least enough preliminary discussion on
+ debian-devel to get started, and there is some information about the
+ newly planned Debian Pure Blend available on the web, it is time to
+ send a formal announcement to
+ <email>debian-devel-announce at lists.debian.org</email>. The
+ announcement should include references to past discussions, any web
+ pages and code which might already exist, and summarise in a well thought
+ out manner what the project is setting out to achieve. Enlisting the
+ help of fellow developers on irc or in private email to look over
+ the draft and work out the final wording before it is sent out is
+ always a good idea.
+ </para>
+ <para>
+ Emails to <email>debian-devel-announce at lists.debian.org</email> have to
+ be signed by the GPG key of an official Debian developer. However, it
+ should not be a very hard task if somebody wants to support Debian
+ while not yet being a developer to find a developer who volunteers
+ to sign an announcement of a reasonable project. It might be
+ reasonable to send this announcement also to other relevant non-Debian
+ lists. If your announcement is well done, it will draw a number
+ of responses from many outsiders, and will attract people to Debian.
+ </para>
+</sect2>
+
+<sect2>
+ <title>Explaining the project</title>
+ <para>
+ Now the real work starts. People who are involved in the project
+ should be aware that they have to answer questions about the project
+ whenever they show up at conferences or at an exhibition booth. So
+ being prepared with some flyers or posters is always a good idea.
+ </para>
+</sect2>
+</sect1>
+
+<sect1 id="structure">
+ <title>Project structure</title>
+
+<sect2 id="subsetting_debian">
+ <title>Sub-setting Debian</title>
+ <para>
+ While there are a variety of different kinds of work to be done in
+ Debian, and not all of them follow this pattern, this document
+ describes one particular kind of project. Our discussion about
+ Debian Pure Blends concerns sub-setting Debian. A sub-setting
+ project aims to identify, expand, integrate, enhance, and maintain a
+ collection of packages suitable for a particular purpose by a
+ particular kind of user.
+ </para>
+ <para>
+ Now, strictly speaking, a subset of packages could be more general
+ than described above. A subset could be a broad category like
+ "audio applications" or "network applications". Or it could be more
+ specific, such as "web browsers" or "text editors". But what a
+ sub-setting project such as Debian Jr. aims to do is not focus on the
+ kind of package, but rather the kind of user. In the case of Debian
+ Jr. it is a young child.
+ </para>
+ <para>
+ The sort of user the project looks after, and which of the needs the
+ project hopes to address are defined by the project's goals.
+ <!-- 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. -->
+ Thus, Debian Jr. first had to decide which children the project
+ would reach: "What age?" "English speaking children only, or
+ other languages as well?" Then the project had to determine
+ how and where they would be using Debian: "At home?" "In school?"
+ "Playing games?" "On their own systems?" "On their parents' systems?"
+ </para>
+ <para>
+ The answers to all of these questions are not straightforward. It is
+ very much up to the project to choose some arbitrary limits for the
+ scope of their work. Choose too broad a focus, or one which duplicates
+ work already done elsewhere, and the energy of the project dissipates,
+ making the project ineffective. Choose too narrow a focus and the
+ project ends up being marginal, lacking the critical mass necessary
+ to sustain itself.
+ </para>
+ <para>
+ A good example was the request to split the microbiology
+ related packages out of Debian Med into a Debian Bio project. This
+ is reasonable in principle, and should really be done. In fact, the
+ initiator of Debian Med would support this idea. So he gave the
+ answer: "Just start the Debian Bio project to take over all related
+ material. Until this happens, Debian Med will cover medical material
+ that deals with sequence analysis and so forth." Unfortunately,
+ there was silence from the Debian Bio proponents after this answer.
+ </para>
+ <para>
+ Of course, it sometimes turns out that you start working on a project
+ thinking you know what it is about, only to find out later that you
+ really had no idea what it would become until the user base has grown
+ beyond the small community of developers that started it. So, none of
+ the decisions you make about your project's scope at the beginning
+ should be taken as set in stone. On the other hand, it is your project,
+ and if you see it veering off in directions that are contrary to your
+ vision for it, by all means steer it back on course.
+ </para>
+</sect2>
+
+<sect2 id="tasksel">
+ <title>Using tasksel and metapackages</title>
+<para>
+ According to the plan of the project, the first metapackages (<xref
+ linkend="metapackages" />) should be developed. It is not always easy to
+ decide what should be included, and which metapackages should be
+ built. The best way to decide on this point is to discuss on the
+ mailing list some well thought out proposals.
+</para>
+<para>
+ Section <xref linkend="text_ui" /> mentions <command>tasksel</command> as a tool
+ to select a Debian Pure Blend, and explains why it is currently not
+ possible to get a Blend included into the task selection list.
+</para>
+ </sect2>
+
+</sect1>
+
+<sect1 id="first_release">
+ <title>First release</title>
+
+<sect2 id="release_announcement">
+ <title>Release announcement</title>
+ <para>
+ Beyond the release announcement for Debian itself, it is necessary
+ to put some thought and work into a release announcement for the
+ first release of a Debian Pure Blend. This will not only
+ be directed at the Debian developer community, but also at the users.
+ This will include potential new Debian users abroad, who may not be
+ on a Debian mailing list. Here, the same principle applies as for
+ the first announcement of the project: it is important to consider
+ sending the information to other relevant forums.
+ </para>
+</sect2>
+
+<sect2 id="users">
+ <title>Users of a Debian Pure Blend</title>
+ <para>
+ By this time, people have newly installed Debian along with the
+ material in the Blend, or have installed the metapackages on their
+ existing Debian systems. Now comes the fun part, building
+ relationships with the user community.
+ </para>
+
+<sect3 id="user_support">
+ <title>Devoting resources to the users</title>
+ <para>
+ Users are a mixed blessing. In the first development phase there are
+ some developers who are users, and some intrepid "early adopters."
+ But once it is released, the first version is "out there," and the
+ project will certainly attract all kinds of users who are not
+ necessarily as technically savvy as your small development user
+ community. Be prepared to spend some time with them. Be patient
+ with them. And be listening carefully for the underlying questions
+ beneath the surface questions. As draining as it can be to deal
+ with users, they are a very key component to keeping your
+ development effort vital.
+ </para>
+</sect3>
+
+<sect3 id="devel_vs_user_list">
+ <title>Developer vs. user mailing list</title>
+ <para>
+ Should a user list be created? It's not as cut-and-dried as it
+ might at first appear. When user help requests start coming in,
+ you might at first see them as a distraction from the development
+ effort. However, you don't necessarily want to "ghettoize" the
+ user community into a separate list early. That's a
+ recipe for developers to get out of touch very quickly with the
+ users. Tolerate the new user questions on the developer list
+ for a while. Once a user list is finally set up, courteously
+ redirect user questions to the user list. Treat your users as
+ the valuable resource about how your project is working "in the
+ field" that they are.
+ </para>
+</sect3>
+
+<sect3 id="user_support_beyond_debian">
+ <title>User support beyond Debian</title>
+ <para>
+ Fortunately, we're not in the business of supporting users alone.
+ Look beyond Debian for your allies in user support: Linux user
+ groups (LUGs) and the users themselves. Develop an awareness of who
+ has stakes in seeing your project succeed, and enlist their help
+ in getting a strong network of support established for your work.
+ </para>
+</sect3>
+
+</sect2>
+
+</sect1>
+
+</chapter>
+
+
Added: blends/trunk/blends/doc/docbook-xml/fr/08_websentinel.xml
URL: http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/docbook-xml/fr/08_websentinel.xml?rev=2414&op=file
==============================================================================
--- blends/trunk/blends/doc/docbook-xml/fr/08_websentinel.xml (added)
+++ blends/trunk/blends/doc/docbook-xml/fr/08_websentinel.xml Tue Oct 26 16:58:17 2010
@@ -1,0 +1,309 @@
+<chapter id="sentinel">
+ <title>The web sentinel</title>
+
+ <sect1 id="packageslist">
+ <title>Existing and prospective packages</title>
+
+<para>
+The so called tasks pages probably give the most interesting overview
+about what a Blend is actually doing for newcomers as well as a nice
+quality assurance tool for developers. If you want to see examples
+for tasks pages just have a look at the
+<ulink url="http://blends.alioth.debian.org/" >list of all Blends</ulink>
+using this technique and follow the links to the tasks pages once you
+selected one specific Blend.
+</para>
+<para>
+If a Debian Pure Blend should be presented one of the first questions
+is, what packages are available. The next question might be which
+packages are on the todo list for inclusion in Debian to make Debian
+even more attractive for people the Blend is targeting at. Both
+questions can be answered if you point people to the dynamically
+created tasks page. The page is rebuild daily to stay up to date
+according to recent developments of the Blend. The build process works
+as follows:
+ <itemizedlist>
+ <listitem><para>Read dependency information of the <filename>tasks</filename> files.</para></listitem>
+ <listitem><para>Verify whether there is really a package with this name and
+ print the description of this package.</para></listitem>
+ <listitem><para>If there is no such package in Debian try to parse
+ the <filename>tasks</filename> file whether there is some information
+ given and mark the result as prospective package for further
+ inclusion.</para></listitem>
+ </itemizedlist>
+</para>
+<para>
+The rationale behind this is to provide as much as possible
+information about packages that might be interesting for the target
+user of the Blend. Moreover the page can provide useful information for
+developers about things that might be a useful help for the project to
+work down the todo list and build Debian packages for software that is
+not yet included in Debian. To get the todo list builded it is
+necessary to add some additional information to the task files which
+are the main database of information for the Blend. The information is
+following the RFC822 syntax as all Debian control files do and is
+kept quite simple:
+<variablelist>
+ <varlistentry>
+ <term>Depends / Recommends / Suggests</term>
+ <listitem><para>Even if there is no Debian package available for the moment
+ the names of prospective packages are given as if they would
+ exists. The rationale behind is that once such a package
+ might exist the source of the metapackage does not have to
+ be changed and will work out of the box after rebuilding.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Ignore</term>
+ <listitem><para>The Ignore key should be the favourite way to use for
+ specifying prospective packages in case the packages should be
+ evaluated once it appears in the Debian package pool. If
+ "Depends", "Recommends" or "Suggests" are used for not yet
+ existing packages they will be turned into the list of Suggests
+ of the metapackage and thus might be possible to become
+ installed on a users machine if the user decides to install all
+ suggested packages. If some evaluation should be done first the
+ "Ignore" tag is your friend.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Homepage</term>
+ <listitem><para>This is the URL to the software that should be packaged.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>WNPP</term>
+ <listitem><para>In case there might be a WNPP bug filed for this software the
+ bug number is given here. This helps to keep track of the
+ ongoing effort to package the software.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Responsible</term>
+ <listitem><para>In case some developer claimed to care for the software
+ (perhaps by issuing the WNPP bug report) the e-mail address of
+ this developer is given here to enable an easy way to contact
+ this person.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>License</term>
+ <listitem><para>Debian cares always about the license. This information
+ about prospective packages should be easily available.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Vcs-Svn</term>
+ <listitem><para>If there is some Debian packaging stuff available this
+ can be addressed in this field. Unofficial packages which
+ have this field set are rendered in a separate section with
+ links to the packaging SVN.
+ </para><para>
+ The usage for this field is the same as it is described in
+ <ulink url="http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-vcs"
+ >paragraph 6.2.5 of Debian developers reference</ulink>
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Vcs-Git</term>
+ <listitem><para>If there is some Debian packaging stuff available this
+ can be addressed in this field. Unofficial packages which
+ have this field set are rendered in a separate section with
+ links to the packaging Git.
+ </para><para>
+ The usage for this field is the same as it is described in
+ <ulink url="http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-vcs"
+ >paragraph 6.2.5 of Debian developers reference</ulink>
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Vcs-Browser</term>
+ <listitem><para>If there is some Debian packaging stuff available this
+ can be addressed in this field. Unofficial packages which
+ have this field set are rendered in a separate section above
+ unofficial packages outside the official Debian mirrors.
+ If you have set <filename>Vcs-Svn</filename> or <filename>Vcs-Git</filename>
+ there is no need to set <filename>Vcs-Browser</filename> explicitely
+ because it is obtained automatically from the other fields.
+ But you might override this automatically generated URL if
+ needed.
+ </para><para>
+ The usage for this field is the same as it is described in
+ <ulink url="http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-vcs"
+ >paragraph 6.2.5 of Debian developers reference</ulink>
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Pkg-URL</term>
+ <listitem><para>In some cases there are unofficial packages for some software
+ which are prepared by a third party. It helps our users if
+ they could install such a package and thus the URL to it might
+ be a helpful hint. This is also true for developers because
+ they might have a look at this packaging before they start from
+ scratch. Often packages are available
+ at <ulink url="http://mentors.debian.net/"
+ >mentors.debian.net</ulink> and prepared by people who do not
+ yet have an official Debian maintainer status and thus are not
+ able to upload packages to the Debian mirror. The packages at
+ mentors are waiting for sponsoring of an official Debian
+ maintainer and if such a package shows up in the Blend tasks list
+ it might speed up the inclusion into official Debian
+ distribution.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Pkg-Description</term>
+ <listitem><para>This tag should give reasonable information about the
+ software as it normally is done in <filename>debian/control</filename>
+ files. It can be either a copy of the description of the WNPP
+ bug or could be used to file a WNPP bug and thus helps to
+ simplify the packaging work.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Remark</term>
+ <listitem><para>In some cases it makes perfectly sense to add a remark on
+ behalf of the Blends team to a package which is visible on the
+ tasks page. This can be done using the Remark field. It can
+ be used in the same syntax as a Description field in Debian
+ control files.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Registration</term>
+ <listitem><para>Sometimes, specifically in the case of scientific software,
+ the project authors ask for registration of their software to
+ get numbers of users of their software. These numbers enable
+ them to ask for further funding of their project. To support
+ this intend of authors the tasks pages can feature a link to
+ this registration page if the link is given in the tasks file
+ in the Registration field.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Published-*</term>
+ <listitem>
+ <para>Several scientific software asks users of the code to quote the
+ publication which was used to describe the algorithm.
+ There was a really long discussion on the
+ <ulink url="http://lists.debian.org/debian-science" >Mailing
+ list of Debian Science Blend</ulink>
+ (<ulink url="http://lists.debian.org/debian-science/2008/10/msg00033.html"
+ >see the start of the thread here</ulink>) how this might be
+ approached. There was some consensus that we need to define a
+ general control file featuring the citation information but the
+ problem has no real solution in the near future. To find an
+ intermediate solution which solves the situation for the tasks
+ pages of Blends some <varname>Published-*</varname> tags can be inserted
+ into the tasks file which are rendered on the according tasks
+ pages. Here comes a list of these tags:
+ </para>
+ <para>
+ <variablelist>
+ <varlistentry>
+ <term>Published-Authors</term>
+ <listitem><para>Authors of the publication. For consistency reasons it is
+ suggested to use <varname>Firstname1 Lastname1, Firstname2 Lastname2</varname>.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Published-Title</term>
+ <listitem><para>Title of the publication.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Published-URL</term>
+ <listitem><para>URL with online infos of the publication. The title will
+ feature a link to this URL - so please make sure there is a
+ Published-Title field if you specify Published-URL.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Published-In</term>
+ <listitem><para>Publication journal
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Published-Year</term>
+ <listitem><para>Publication year
+ </para></listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+ <para>Any suggestion to enhance these fields is welcome.
+ </para></listitem>
+</varlistentry>
+</variablelist>
+</para>
+
+ </sect1>
+
+ <sect1 id="ddtp">
+ <title>Debian Description Translation Project</title>
+
+<para>
+The <ulink url="http://ddtp.debian.net/" >Debian Description
+Translation Project</ulink> (see <xref linkend="documentation" />) provides users of
+non English languages with information about Debian packages. The
+sense of supporting especially the translations of descriptions which
+are in the focus of a Blend is to make the Blend even more usable for our
+target users. Moreover people interested in the special field of the
+Blend are most probably able to provide good translations if it comes to
+texts that are specific to their field of knowledge. Thus there is a
+web page automatically created that parses the tasks packages for
+package names and verifies the translation status of the package
+descriptions.
+</para>
+<para>
+Finally the DDTP descriptions can be used to create internationalised
+pages of existing packages which might help users with insufficient
+skills in English to easily find their software of interest.
+</para>
+
+ </sect1>
+
+ <sect1 id="bugs">
+ <title>Bugs overview</title>
+<para>
+The goal of a Blend is to support their user as best as possible. So a
+feature to have a quick overview about all packages in our focus might
+be helpful. This is solved by the bugs overview page. To create this
+page the <filename>tasks</filename> files are parsed for the listed
+dependencies. Then the Debian Bug Tracking System is consulted about
+known bugs of these packages. All bugs are listed and marked with
+different colours according to their severity. So the developers can
+easily check this page in case they plan to fix some bugs that are
+relevant for the Blend.
+</para>
+<para>
+If you want to see examples for those bugs pages just have a look at the
+<ulink url="http://blends.alioth.debian.org/" >list of all Blends</ulink>
+using this technique and follow the links to the bugs pages once you
+selected one specific Blend.
+</para>
+
+ </sect1>
+
+ <sect1 id="svnoverview">
+ <title>SVN overview</title>
+<para>
+This page gives a recent overview about the current development
+activities of the Blend developers.
+</para>
+ </sect1>
+
+ <sect1 id="qareport">
+ <title>Quality assurance report</title>
+
+<para>
+The Debian Quality Assurance group does a decent job in watching the
+status o f Debian packages. If a package features a
+valid <filename>debian/watch</filename> the tool <command>uscan</command> is able to
+verify the upstream source location for newer versions. The QA report
+page reports issues about the packages that are relevant for a Blend.
+</para>
+ </sect1>
+
+</chapter>
+
+
Added: blends/trunk/blends/doc/docbook-xml/fr/09_todo.xml
URL: http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/docbook-xml/fr/09_todo.xml?rev=2414&op=file
==============================================================================
--- blends/trunk/blends/doc/docbook-xml/fr/09_todo.xml (added)
+++ blends/trunk/blends/doc/docbook-xml/fr/09_todo.xml Tue Oct 26 16:58:17 2010
@@ -1,0 +1,469 @@
+<chapter id="todo">
+ <title>To do</title>
+
+ <sect1 id="communication">
+ <title>Establishing and using communication platforms</title>
+
+<para>
+Each Debian Pure Blend has an own mailing list for discussion of
+specific development issues. Because there are several common issues
+between all Blends also a common mailing list was created. People who
+are interested in working on common issues like building metapackages,
+technical issues of menu systems or how to create CDs for Blends
+could <ulink url="http://lists.debian.org/debian-custom/" >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
+<programlisting>
+ svn checkout svn://svn.debian.org/svn/blends blends
+</programlisting>
+for anonymous users. Developers should check out via
+<programlisting>
+ svn checkout svn+ssh://<varname>username</varname>@svn.debian.org/svn/blends blends
+</programlisting>
+The current layout for the repository is as follows:
+<programlisting>
+ blends -+- blends
+ | |
+ | +- tags -----+- cdd -+- 0.3 [older versions of cdd tools]
+ | | | +- 0.3.1
+ | | | ...
+ | | | +- <varname><latest></varname>
+ | | |
+ | | +- doc -+- 0.1 [older versions of this doc]
+ | | +- 0.2
+ | | +- 0.3
+ | | [Since 0.4.1 the doc is in blends directory]
+ | |
+ | +- trunk ----blends [code in development for blends source package]
+ | |
+ | +-- doc [this document = blends-doc package]
+ |
+ +- projects -+--- med ---+- tags
+ | |
+ | +- trunk [development version of Debian Med]
+ |
+ +- science -+- tags
+ | |
+ | +- trunk [development version of Debian Science]
+ |
+ +- ...
+ |
+ ...
+</programlisting>
+There is
+a <ulink url="http://lists.alioth.debian.org/mailman/listinfo/blends-commits"
+>mailing list</ulink> with subversion changes and
+a <ulink url="http://cia.navi.cx/stats/project/debian-custom" >CIA
+system</ulink> for tracking changes in the Debian Pure Blends projects in
+real-time.
+</para>
+ </sect1>
+
+ <sect1 id="visibility">
+ <title>Enhancing visibility</title>
+
+<para>
+If a user installs Debian via official install CDs the first chance to
+do a package selection to customise the box is <command>tasksel</command>.
+The first Debian Pure Blend Debian Junior is mentioned in the
+task selection list and thus it is clearly visible to the user who
+installs Debian.
+</para>
+<para>
+In bug <ulink url="http://bugs.debian.org/186085" >#186085</ulink> a
+request was filed to include Debian Med in the same manner. The
+problem with the <command>tasksel</command>-approach is that all included
+packages should be on the first install CD. This would immediately
+have the consequence that the first install CD would run out of space
+if all Blends would be included in the task selection list.
+</para>
+<para>
+How to enhance visibility of Debian Pure Blends for the user who
+installs Debian from scratch?
+<variablelist>
+ <varlistentry>
+ <term>Change <command>tasksel</command> policy.</term>
+ <listitem><para>If the <emphasis>packages must be on the first CD</emphasis> feature of
+ <command>tasksel</command> 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
+ <command>tasksel</command> or in addition to <command>tasksel</command>
+ in the installation procedure which presents a screen which
+ gives some very short information about Debian Pure Blends
+ (perhaps pointing to this document for further reference) and
+ enables the user to select from a list of the available
+ Blends.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Provide separate install CDs</term>
+ <listitem><para>By completely ignoring the installation of the official
+ installation CD each Blend can offer a separate installation
+ CD. This will be done anyway for certain practical reasons
+ (see for instance the Debian Edu - SkoleLinux approach). But
+ this is really no solution we could prefer because this does
+ not work if the user wants to install more than one Blend on
+ one computer.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Change overall distribution philosophy of Debian.</term>
+ <listitem><para>This way is concerned to some ideas from Debian developers
+ who took part in Open Source World Conference in Malaga and
+ is explained in Detail
+ in <xref linkend="new_ways_of_distribution" />. This would save the
+ problem of making Debian Pure Blends visible to users in a
+ completely different way because in this case Debian would be
+ released as its various flavours of Blends.
+ </para></listitem>
+ </varlistentry>
+</variablelist>
+</para>
+<para>
+Whichever way Debian developers will decide to go it is our vital
+interest to support users and <emphasis>show</emphasis> our users the tools we
+invented to support them.
+</para>
+ <sect2 id="webpages">
+ <title>Debian Pure Blends web pages</title>
+<para>
+Some Blends maintain their own web space under
+<command>http://www.debian.org/devel/BLEND-name</command> to provide general
+information which will be translated by the Debian web team. This is a
+good way to inform users about the progress of a project. This page
+should link to the apropriate autogenerated pages as described
+in <xref linkend="web_if" /> to make sure that the content of the page remains
+up to date at any time.
+</para>
+ </sect2>
+ </sect1>
+
+ <sect1 id="debtags">
+ <title>Debian Package Tags</title>
+
+<para>
+<ulink url="http://debtags.alioth.debian.org/" >Debian
+Package Tags</ulink> is a work to add more metadata to Debian packages.
+At the beginning it could be seen as a way to allow to specify
+multiple sections (called "tags") per package where now only one can
+be used.
+</para>
+<para>
+However, the system has evolved so that tags are organised in
+"facets", which are separate ontologies used to categorise the
+packages under different points of view.
+</para>
+<para>
+This means that the new categorisation system supports tagging
+different facets of packages. There can be a set of tags for the
+"purpose" of a package (like "chatting", "searching", "editing"),
+a set of tags for the technologies used by a package (like "html",
+"http", "vorbis") and so on.
+</para>
+<para>
+Besides being able to perform package selection more efficiently by
+being able to use a better categorisation, one of the first outcomes
+of Debian Package Tags for Blends is that every Blend could maintain
+its own set of tags organised under a "facet", providing
+categorisation data which could be used by its users and which
+automatically interrelates with the rest of the tags.
+</para>
+<para>
+For example, Debian Edu could look for "edu::administration" packages
+and then select "use::configuring". The "edu::administration"
+classification would be managed by the Debian Edu people, while
+"use::configuring" would be managed by Debian. At the same time, non
+Debian Edu users looking for "use::configuring" could have a look at
+what packages in that category are suggested by the Debian Edu
+community.
+</para>
+<para>
+It is not excluded that this could evolve in being able to create a
+Blend just by selecting all packages tagged by "edu::*" tags, plus
+dependencies; however, this option is still being investigated.
+</para>
+<para>
+Please write to the
+list <email>deb-usability-list at lists.alioth.debian.org</email> for
+more information about Debian Package Tags or if you want to get
+involved in Debian Package Tags development.
+</para>
+ </sect1>
+
+ <sect1 id="EnhancingTechnology">
+ <title>Enhancing basic technologies regarding Debian Pure Blends</title>
+
+<para>
+In section <xref linkend="future_handling" /> several issues where raised how
+handling of metapackages should be enhanced.
+</para>
+<para>
+Currently there is no solution to address the special configuration
+issue has to be addressed. In general developers of metapackages
+should provide patches for dependent packages if they need a certain
+configuration option and the package in question does feature a
+<command>debconf</command> configuration for this case. Then the
+metapackage could provide the needed options by pre-seeding the
+<command>debconf</command> database while using very low priority questions
+which do not came to users notice.
+</para>
+<para>
+If the maintainer of a package which is listed in a metapackage
+dependency and needs some specific configuration does not accept such
+kind of patch it would be possible to go with a <command>cfengine</command>
+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 <command>cfengine</command>
+script takes over the role of the local administrator: It just handles
+as an
+"automated-<command>cfengine</command>-driven-administrator-robot".
+</para>
+<para>
+If there is some agreement to use <command>cfengine</command> scripts to
+change configuration - either according to <command>debconf</command>
+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
+<programlisting>
+ /usr/share/blends/#BLEND#/#METAPACKAGE#/cf.#SOMETHING#
+</programlisting>
+</para>
+<para>
+There was another suggestion at the Valencia workshop: Make use of
+<command>ucf</command> for the purpose mentioned above. This is a topic
+for discussion. At least currently Debian Edu seems to have good
+experiences with <command>cfengine</command> but perhaps it is worth comparing
+both.
+</para>
+<para>
+A further option might be
+<ulink url="http://freedesktop.org/Software/CFG" >Config4GNU</ulink> from
+freedesktop.org but it is not even yet packaged for Debian.
+</para>
+ </sect1>
+
+ <sect1 id="liveCD">
+ <title>Building Live CDs of each Debian Pure Blend</title>
+
+<para>
+The first step to convince a user to switch to Debian is to show him
+how it works while leaving his running system untouched.
+<ulink url="http://www.knoppix.org/" >Knoppix</ulink> - <emphasis>the "mother" of
+all Debian-based live CDs</emphasis> - is a really great success and it is a
+fact that can not be ignored that Debian gains a certain amount of
+popularity because people want to know what distribution is working
+behind the scenes of Knoppix.
+</para>
+<para>
+But Knoppix is a very common demonstration and its purpose is to work
+in everyday live. There is no room left for special applications and
+thus people started to adopt it for there special needs. In fact
+there exist so many Debian based Live CDs that it makes hardly sense
+to list them all here. The main problem is that most of them
+containing special applications and thus are interesting in the Blends
+scope are out of date because they way the usually were builded was a
+pain. One exception is
+perhaps <ulink url="http://dirk.eddelbuettel.com/quantian.html"
+>Quantian</ulink> which is quite regularly updated and is intended for
+scientists.
+</para>
+<para>
+The good news is that the problem of orphaned or outdated Live CDs can
+easily solved by debian-live and the <package>live-helper</package>.
+This package turns all work to get an up to date ISO image for a Live
+CD into calling a single script. For the Blends tools this would
+simply mean that the tasks files have to be turned into a live-helper
+input file and the basic work is done. This will be done in a future
+<package>blends-dev</package> version.
+</para>
+
+ </sect1>
+
+ <sect1 id="new_ways_of_distribution">
+ <title>New way to distribute Debian</title>
+
+<para>
+<emphasis>This section is kind of "Request For Comments" in the sense that
+solid input and arguing is needed to find out whether it is worth
+implementing it or drop this idea in favour of a better solution.</emphasis>
+</para>
+<para>
+At Open Source World Conference in Malaga 2004 there was a workshop of
+Debian Developers. Among other things the topic was raised how the
+distribution cycle or rather the method of distribution could be
+changed to increase release frequency and to better fit user interests.
+</para>
+<para>
+There was a suggestion by Bdale Garbee <email>bdale at gag.com</email> to
+think about kind of sub-setting Debian in the following way: Debian
+developers upload their packages to <varname>unstable</varname>. The normal
+process which propagates packages to <varname>testing</varname> and releasing a
+complete <varname>stable</varname> 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 <emphasis>tested inside the subset</emphasis> distribution
+which leads to a <varname>stable</varname> subset release. The following graph
+might clarify this:
+
+<programlisting>
+<![CDATA[
+DD -> unstable --> testing --> stable
+ |
+ +---> BLEND_A testing --> stable BLEND_A
+ |
+ +---> BLEND_B testing --> stable BLEND_B
+ |
+ +---> ...
+]]>
+</programlisting>
+
+where <varname>BLEND_A</varname> / <varname>BLEND_B</varname> might be something like
+<varname>debian-edu</varname> / <varname>debian-med</varname>. To implement this
+sub-setting the following things are needed:
+<variablelist>
+ <varlistentry>
+ <term>Promotion rules</term>
+ <listitem><para>There was a general agreement that technical implementation
+ of this idea in the package pool scripts / database is not too
+ hard. In fact at LinuxTag Chemnitz 2004 Martin Loschwitz
+ <email>madkiss at debian.org</email> announced exactly this as
+ "nearly implemented for testing purpose" which should solve
+ the problem of outdated software for desktop users as a goal
+ of the <varname>debian-desktop</varname> project. Unfortunately this
+ goal was not realised finally.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Reasonable subsets</term>
+ <listitem><para>Once the promotion tools are able to work with sub-setting,
+ reasonable subsets have to be defined and maintained. A
+ decision has to be made (if this will be implemented at all)
+ whether this sub-setting should be done according to the
+ Blend layout or if there are better ways to find subsets.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>BTS support</term>
+ <listitem><para>The Bug Tracking System has to deal with different package
+ versions or even version ranges to work nicely together with
+ the sub-setting approach.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Security</term>
+ <listitem><para>As a consequence of having more than only a single
+ <varname>stable</varname> each Blend team has to form a security team
+ to care for those package versions that are not identically
+ with the "old" <varname>stable</varname>.
+ </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:
+
+<programlisting>
+DD -> unstable --> testing --> releasable --> stable
+ |
+ +---> stable BLEND_A
+ |
+ +---> stable BLEND_B
+ |
+ +---> ...
+</programlisting>
+
+A third suggestion was given at Congreso Software Libre Comunidad
+Valenciana:
+
+<programlisting>
+ testing_proposed_updated
+ |
+ |
+ v
+DD -> unstable --> testing --> stable
+ |
+ +---> stable BLEND_A
+ |
+ +---> stable BLEND_B
+ |
+ +---> ...
+</programlisting>
+
+The rationale behind these testing backports is that sometimes a
+Debian Pure Blend is able to reduce the set of releasable
+architectures. Thus some essential packages could be moved much
+faster to testing and these might be "backported" to testing
+for this special Blend. For instance this might make sense for Debian
+Edu where usually neither mainframes nor embedded devices are used.
+</para>
+<para>
+All these different suggestions would lead to a modification of the
+package pool scripts which could end up in a new way to distribute
+Debian. This might result from the fact that some Debian Pure Blends
+need a defined release cycle. For instance the education related
+distributions might trigger their release by the start-end-cycle of
+the school year. Another reason to change the package pool system is
+the fact that some interested groups, who provide special service for
+a certain Blend, would take over support only for the subset of
+packages which is included in the metapackage dependencies or
+suggestions but they refuse to provide full support for the whole
+range of Debian packages. This would lead to a new layout of the file
+structures of the Debian mirrors:
+
+<programlisting>
+ debian/dists/stable/binary-i386
+ /binary-sparc
+ /binary-...
+ /testing/...
+ /unstable/...
+ debian-BLEND_A/dists/stable/binary-[supported_architecture1]
+ /binary-[supported_architecture2]
+ /...
+ /testing/...
+ debian-BLEND_B/dists/testing/...
+ /stable/...
+ ...
+ pool/main
+ /contrib
+ /non-free
+</programlisting>
+To avoid flooding the archive with unnecessarily many versions of
+packages for each single Debian Pure Blend a common base of all these
+Blends has to be defined. Here some LSB conformance statement comes
+into mind: The base system of all currently released (stable) Debian
+Pure Blends is compliant to LSB version x.y.
+</para>
+<para>
+Regarding to security issues there are two ways: Either one Debian
+Pure Blend goes with the current stable Debian and thus the
+<filename>Packages.gz</filename> is just pointing to the very same versions
+which are also in debian/stable. Then no extra effort regarding to
+security issues is need. But if there would be a special support team
+which takes over maintenance and security service for the packages in
+a certain Blend they should be made reliable for this certain subset.
+</para>
+<para>
+This reduced subset of Debian packages of a Debian Pure Blend would
+also make it easier to provide special install CDs at is it currently
+done by Debian Edu.
+</para>
+ </sect1>
+</chapter>
+
+
Added: blends/trunk/blends/doc/docbook-xml/fr/A_devel.xml
URL: http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/docbook-xml/fr/A_devel.xml?rev=2414&op=file
==============================================================================
--- blends/trunk/blends/doc/docbook-xml/fr/A_devel.xml (added)
+++ blends/trunk/blends/doc/docbook-xml/fr/A_devel.xml Tue Oct 26 16:58:17 2010
@@ -1,0 +1,625 @@
+ <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
+<package><blend>-config</package> package from which
+all other metapackages of the <varname>Blend</varname> in question will
+depend. This <package><blend>-config</package> package
+instantiates the <varname>Blend</varname> in the common registry for all Blends in
+<filename>/etc/blends</filename>.
+</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 containig one single line
+
+<programlisting>
+ include /usr/share/blends-dev/Makefile
+</programlisting>
+
+(see <filename>/usr/share/doc/blends-dev/examples/Makefile</filename>). 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<varname>-tasks.desk</varname></title>
+
+<para>
+This target is the description file that is used in
+<command>tasksel</command> to enable selecting the tasks belonging to the
+Blend. The file will be moved to the
+<varname>blend</varname><package>-tasks</package>. All information is obtained
+from the single task files in the <filename>tasks</filename> directory of the
+Blend source.
+</para>
+
+</sect2>
+<sect2 id="debian_control">
+ <title><varname>debian/control</varname></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 <command>blend-gen-control</command> verifies whether these
+dependencies exist in the specified package pool and create
+the <filename>debian/control</filename> file 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>
+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 <command>apt-get</command> 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. Packages that are specified with
+ "Suggests" will not be taken over to
+ the <command>tasksel</command> 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 <command>tasksel</command> 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>
+ <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 <varname>stable</varname>, <varname>testing</varname>, <varname>unstable</varname> 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 <varname>-s </varname><varname>dist</varname> option of <citerefentry><refentrytitle>blend-gen-control</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+</para>
+<para>
+<emphasis role="strong">TODO:</emphasis> <emphasis>Either parse the available
+<filename>/etc/apt/sources.list</filename> or use a sane <command>debconf</command>
+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><!-- document type does not allow element "MANREF" here--><command>blend-role(8)</command></title>
+<para>
+<variablelist>
+ <varlistentry>
+ <term>NAME</term>
+ <listitem><para>
+ <command>blend-role</command> - add/remove roles in registered Debian Pure Blend
+
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>SYNOPSIS</term>
+ <listitem><para>
+ <command>blend-role</command> <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><para>
+ <variablelist>
+ <varlistentry>
+ <term><varname>Blend</varname></term>
+ <listitem><para>A registered Blend in /etc/blends, for example
+ one of <varname>med</varname>, <varname>junior</varname>,
+ <varname>edu</varname> or <varname>science</varname>
+ </para></listitem>
+ </varlistentry>
+ </variablelist>
+ </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>
+
+<sect2 id="blend-update-menus">
+ <title><!-- document type does not allow element "MANREF"
+ here--><command>blend-update-menus(8)</command></title>
+<para>
+<variablelist>
+ <varlistentry>
+ <term>NAME</term>
+ <listitem><para>
+ <command>blend-update-menus</command> - add menu of metapackage to all Blend users
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>SYNOPSIS</term>
+ <listitem><para>
+ <command>blend-update-menus</command> [<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><para>
+ <variablelist>
+ <varlistentry>
+ <term><varname>Blend</varname></term>
+ <listitem><para>one of the installed Blends, listed in /etc/blends/, for example
+ (if installed: <varname>med</varname>, <varname>junior</varname>,
+ <varname>edu</varname> or <varname>science</varname>.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>user</varname></term>
+ <listitem><para>system user</para></listitem>
+ </varlistentry>
+ </variablelist>
+ </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>
+
+<sect2>
+ <title><!-- document type does not allow element "MANREF" here--><command>blend-user(8)</command></title>
+<para>
+<variablelist>
+ <varlistentry>
+ <term>NAME</term>
+ <listitem><para>
+ <command>blend-user</command> - add/remove user to Role of a registered Blend
+
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>SYNOPSIS</term>
+ <listitem><para>
+ <command>blend-user</command> <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><para>
+ <variablelist>
+ <varlistentry>
+ <term><varname>Blend</varname></term>
+ <listitem><para>A registered Blend in /etc/blends, for example
+ one of <varname>med</varname>, <varname>junior</varname>,
+ <varname>edu</varname> or <varname>science</varname>.
+ </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>
+ </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>
+
+<sect2>
+ <title><command>blends.conf(5)</command></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/<varname><Blend></varname>/<varname><Blend></varname>.conf</filename>
+ for each single Blend.</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>SYNTAX</term>
+ <listitem><para>The following variables can be set:
+ <variablelist>
+ <varlistentry>
+ <term><varname>DBBACKEND</varname></term>
+ <listitem><para>Set the backend for the user role management system.
+ Currently the only implemented role management system is
+ <varname>unixgroups</varname> but others might be implemented
+ later. Unsetting this variable leads to use no roles at all.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>UPDATEUSERMENU</varname></term>
+ <listitem><para>If this is set to <varname>yes</varname>, 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><varname>SHAREDIR</varname></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><varname>DRYRUN</varname></term>
+ <listitem><para>This variable can be set for debugging. Normally it
+ should be left unset (<emphasis>NOT</emphasis> set to <varname>false</varname>
+ or anything else!). If set to <varname>true</varname> a dry run of
+ the tools is performed or <command>echo DRYRUN:</command> would
+ print debugging information.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>DEBUG</varname></term>
+ <listitem><para>If set to <varname>1</varname> debugging mode is switched on.</para></listitem>
+ </varlistentry>
+ </variablelist>
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>SEE ALSO</term>
+ <listitem><para>
+ <filename>blend-role (8)</filename>, <filename>blend-update-menus (8)</filename>,
+ <filename>blend-user (8)</filename>
+ </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 <filename>svn</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
+<programlisting>
+ svn checkout svn+ssh://<varname>username</varname>@svn.debian.org/svn/blends/blends/trunk/blends blends
+</programlisting>
+ or for the Debian Pure Blend <varname>BLEND-name</varname>
+<programlisting>
+ svn checkout svn+ssh://<varname>username</varname>@svn.debian.org/svn/blends/projects/<varname>BLEND-name</varname>/trunk
+</programlisting>
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Build source package</term>
+ <listitem><para>
+ Change into the created directory and type
+<programlisting>
+ make -f debian/rules get-orig-source
+</programlisting>
+ 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
+<programlisting>
+ #!/usr/bin/make -f
+ include /usr/share/blends-dev/Makefile
+</programlisting>
+ Which enables you to simply say
+<programlisting>
+ make dist
+</programlisting>
+ 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 <command>alioth.debian.org</command></para></listitem>
+ <listitem><para><command>cd /var/lib/gforge/chroot/home/groups/blends/webtools/</command></para></listitem>
+ <listitem><para><command>./tasks.py <blend-name></command></para></listitem>
+</orderedlist>
+</para>
+<para>
+To know what a valid <varname><blend-name></varname> might be have a look
+into
+<command>/var/lib/gforge/chroot/home/groups/blends/webtools/webconf</command>.
+Each Blend has an according config file there. Leave out
+the <varname>.conf</varname> extension and you have a
+valid <varname><blend-name></varname>.
+</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 <command>blends.debian.net</command> 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 SVN at
+<command>svn://svn.debian.org/blends/blends/trunk/webtools</command>. 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
+<command>svn://svn.debian.org/blends/blends/trunk/webtools/templates</command>.
+You can also influence some parameters of the web pages in the
+configuration files
+<command>svn://svn.debian.org/blends/blends/trunk/webtools/webconf</command>.
+Last but not least you can provide translations for the web pages in
+<command>svn://svn.debian.org/blends/blends/trunk/webtools/po</command>.
+</para>
+<para>
+Once something on the web pages was changed you can activate the
+changes as follows:
+</para>
+<para>
+<orderedlist>
+ <listitem><para>Login to <command>alioth.debian.org</command> or <command>blends.debian.net</command></para></listitem>
+ <listitem><para><command>cd /var/lib/gforge/chroot/home/groups/blends/webtools/</command></para></listitem>
+ <listitem><para><command>./deploy-svn</command></para></listitem>
+</orderedlist>
+</para>
+<para>
+Please note that the <varname>css</varname> and <varname>js</varname> 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 SVN at
+<command>svn://svn.debian.org/blends/blends/trunk/websites</command>.
+Once you have changed the content of the pages you can activate
+the changes by doing:
+</para>
+<para>
+<orderedlist>
+ <listitem><para>Login to <command>alioth.debian.org</command> or <command>blends.debian.net</command></para></listitem>
+ <listitem><para><command>cd /var/lib/gforge/chroot/home/groups/blends/webtools/</command></para></listitem>
+ <listitem><para><command>./deploy-static-pages</command></para></listitem>
+</orderedlist>
+</para>
+</sect1>
+ </appendix>
+
+
Added: blends/trunk/blends/doc/docbook-xml/fr/B_quickintro.xml
URL: http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/docbook-xml/fr/B_quickintro.xml?rev=2414&op=file
==============================================================================
--- blends/trunk/blends/doc/docbook-xml/fr/B_quickintro.xml (added)
+++ blends/trunk/blends/doc/docbook-xml/fr/B_quickintro.xml Tue Oct 26 16:58:17 2010
@@ -1,0 +1,219 @@
+ <appendix id="QuickIntro">
+ <title>Quick intro into building metapackages</title>
+
+<para>
+There are several descriptions available how to build Debian packages
+in general. The main resource might be the repository of
+<ulink
+url="http://www.debian.org/doc/packaging-manuals/"
+>Debian packaging manuals</ulink> (especially
+<ulink
+url="http://www.debian.org/doc/packaging-manuals/developers-reference/best-pkging-practices.html"
+>developers reference chapter 6, best packaging practices</ulink>).
+There are several external packaging HOWTOs for example the one from
+<ulink
+url="http://www-106.ibm.com/developerworks/linux/library/l-debpkg.html"
+>Joe 'Zonker' Brockmeier</ulink>.
+</para>
+
+ <sect1 id="Dependencies">
+ <title>Defining dependencies for metapackages</title>
+
+<para>
+This howto describes the building of metapackages by using the
+<package>blends-dev</package> package. It is perfectly possible to
+build a metapackage as any other normal Debian package but this HOWTO
+has the only purpose to describe the profit you might gain by using
+these tools.
+
+ <programlisting>
+~> cp -a /usr/share/doc/blends-dev/examples/tasks .
+~> cat tasks/README
+~> edit tasks/task1
+Description: <varname>short description
+ long description as in any debian/control file</varname>
+
+Depends: <varname>dependency1, dependency2, ...</varname>
+ </programlisting>
+
+For each metapackage this skeleton of a <filename>debian/control</filename>
+entry is needed. All necessary information is available in the
+directory <filename>/usr/share/doc/blends-dev/examples/tasks</filename>.
+</para>
+ </sect1>
+
+ <sect1 id="Packaging">
+ <title>The packaging directory</title>
+
+<para>
+To build any Debian package you always need a directory named
+<filename>debian</filename>, which contains a certain set of files. The
+package <package>blends-dev</package> provides a complete set of example
+files that only have to be copied and after editing some place
+holders are ready to use.
+<programlisting>
+~> cp -a /usr/share/doc/blends-dev/examples/debian .
+~> cat debian/README
+~> edit debian/control.stub
+</programlisting>
+Now the variables in the file <filename>control.stub</filename> change the
+variables named <varname>_BLEND_</varname>, <varname>_MAINTAINER_</varname> etc. to
+match the names of the Debian Pure Blend to be built. Please note
+that the file <filename>debian/control</filename> is and has to be a symbolic
+link to <filename>control.stub</filename> to let the
+<package>blends-dev</package> tools work.
+
+<programlisting>
+~> edit debian/rules
+</programlisting>
+
+Also in the <filename>debian/rules</filename> the name of the Blend has to be
+inserted where the template contains
+<varname>_BLEND_</varname>. Depending from the way the
+<filename>sources.list</filename> should be scanned the options for the
+<command>gen-control</command> call can be adjusted.
+</para>
+<para>
+You have to build the tarball using the command
+<programlisting>
+~> make -f debian/rules get-orig-source
+</programlisting>
+For your comfort you might like to create a file
+<filename>Makefile</filename> containing
+<programlisting>
+#!/usr/bin/make -f
+include /usr/share/blends-dev/Makefile
+</programlisting>
+which enables you to simply use
+<programlisting>
+~> make dist
+</programlisting>
+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
+<programlisting>
+~> debuild
+</programlisting>
+</para>
+<para>
+That's all for the very simple case when the metapackages should not
+contain user menus. Even if user menus are suggested they are not
+necessary. The following paragraphs describe how to use the
+<package>blends-dev</package> tools to support these menus.
+</para>
+
+ </sect1>
+
+ <sect1 id="common-metapackage">
+ <title>The common metapackage</title>
+
+<para>
+The creation of a common package is optional, but suggested, because it
+adds some special features like menus, user groups, and probably more
+in the future. It is automatically built by
+<filename>blend-install-helper</filename>, which is called in
+<filename>debian/rules</filename>, if the <filename>common</filename> directory exists.
+The easiest way to create this is as follows:
+<programlisting>
+~> cp -a /usr/share/doc/blends-dev/examples/common .
+~> cat common/README
+~> edit common/conf common/control common/common.1
+</programlisting>
+The variables (<varname>_BLEND_</varname>) in these three files have to be
+adjusted to the name of the Debian Pure Blend in question.
+This <filename><varname>blend</varname>-config</filename> cares for the initialisation
+of the role based menu system and might contain adjustments of the
+general configuration inside the <package>blends-common</package>.
+</para>
+<para>
+If the metapackage <package>blend-config</package> will be
+created according to these rules all other metapackages will depend
+automatically from this common package. For the friends of
+<command>auto-apt</command>, a helper
+<filename>/usr/bin/<metapackage-name></filename> will be
+installed as well, which just prints some information about the meta
+package. All in all, the usage of the common package is strongly
+suggested to have a common registry for stuff like user roles and
+possibly other things that will be implementd in the future.
+</para>
+ </sect1>
+ <sect1 id="metapackage-menus">
+ <title>The metapackage menus</title>
+
+<para>
+As explained in <xref linkend="menu_tools" /> the metapackages can contain
+user menus. This optional feature can be implemented easily by using
+the template from the <package>blends-dev</package> in the following way:
+
+<programlisting>
+~> cp -a /usr/share/doc/blends-dev/examples/menu .
+~> cat menu/README
+~> edit menu/task1
+ <varname>Edit the example to legal menu entries of the
+ dependencies of this metapackage</varname>
+~> cp menu/task1 menu/<varname><metapackage name></varname>
+</programlisting>
+
+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
+<varname>package</varname> field, which has to be changed from
+<package><dependent package></package> to
+<package>blend-task</package>. All other entries
+might remain unchanged. This is a good point to check whether the
+menu entries of the packages you depend from are formated nicely and
+print the necessary information (for instance make use of "hints").
+Here the metapackage maintainer has a good chance for quality
+assurance work, which is also part of the Debian Pure Blends
+issue.
+</para>
+<para>
+In principle these menu items could be created automatically either at
+metapackage build time or even better in the <filename>postinst</filename>
+script of the metapackage because it is granted that the needed menu
+files are installed on the system, which is not really necessary on
+the metapackage build machine. This might be implemented in later
+versions of <package>blends-dev</package>. Currently the policy is that
+we like to have a little bit of control about the menu entries for the
+quality assurance issue mentioned above. Last, but not least, there are
+packages that do not provide a menu entry. If this is the case
+because the package maintainer just forgot it a bug report should be
+filed. On the other hand, there are packages with programs that
+provide a command line interface that does not allow a reasonable
+menu entry. A solution for this case is provided in the next
+paragraph.
+</para>
+
+ </sect1>
+ <sect1 id="any-dependency--menus">
+ <title>Menu for any dependency</title>
+
+<para>
+The idea of the metapackage menu is to provide the user with easily
+viewable traces of any installed package that helps solving everyday
+tasks. So if there are packages that do not contain a menu, a screen
+with relevant documentation should be provided in a viewer by the
+creator of the metapackage. Such documentation can be created using
+the following templates:
+
+<programlisting>
+~> cp -a /usr/share/doc/blends-dev/examples/docs .
+~> cat docs/README
+~> edit docs/task1/dep1
+ <varname>Provide information about a package <dep1> that is
+ a dependency of the metapackage <task1>, but does not
+ contain a useful menu entry.</varname>
+~> cp docs/task1/dep1 docs/task1/<varname><dependent pkg></varname>
+~> cp -a docs/task1 docs/<varname><metapackage name></varname>
+</programlisting>
+
+This ensures that our users become aware of all interesting packages
+on their system. The documentation files should contain hints to man
+pages to read, URLs that should be visited to learn more about the
+package or some short introduction how to get started.
+</para>
+</sect1>
+</appendix>
Added: blends/trunk/blends/doc/docbook-xml/fr/C_bts.xml
URL: http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/docbook-xml/fr/C_bts.xml?rev=2414&op=file
==============================================================================
--- blends/trunk/blends/doc/docbook-xml/fr/C_bts.xml (added)
+++ blends/trunk/blends/doc/docbook-xml/fr/C_bts.xml Tue Oct 26 16:58:17 2010
@@ -1,0 +1,94 @@
+ <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
+<command>program_xy</command> 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 <command>reportbug</command> for this purpose.
+</para>
+<para>
+If you use wnpp sanely you can even tag this bug for the intended
+purpose to include it in a certain Debian Pure Blend. This was
+described
+in <ulink url="http://lists.debian.org/debian-devel-announce/2005/09/msg00002.html"
+>a mail of Anthony Towns</ulink> and
+<ulink
+url="http://wiki.debian.org/DebianScience/Sponsoring"
+>the Debian wiki</ulink>. It was also described in
+<ulink url="http://lists.debian.org/debian-custom/2005/04/msg00017.html"
+>a mail of Ben Armstrong</ulink> and in short works like this:
+
+<itemizedlist>
+ <listitem><para>
+ Add an usertag to an existing bug by sending to
+ request at bugs.debian.org a mail containing
+ <programlisting>
+ user <email>
+ usertag <bug number> + wnpp <metapackage name>
+ </programlisting>,
+ where email is the electronic address of the person or mailing
+ list which coordinates the relevant Debian Pure Blend.
+ </para>
+ <para>
+ For instance if you want to tag an ITP with bug number
+ #123456 for Debian Med section biology you would send the
+ following mail to <email>request at bugs.debian.org </email>:
+ <programlisting>
+ user debian-med at lists.debian.org
+ usertag 123456 + wnpp med-bio
+ thanks
+ </programlisting>
+ </para>
+ <para>
+ <emphasis role="strong">Note:</emphasis> Because the search is case sensitive
+ please always use lower case tags!
+ </para>
+ </listitem>
+ <listitem><para>To search for WNPP bugs of a certain Debian Pure Blend just
+ visit the URL
+<programlisting>
+http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=wnpp;users=<varname>email</varname>
+</programlisting>
+ </para></listitem>
+</itemizedlist>
+
+
+</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 <command>reportbug</command> 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 <command>reportbug</command>.
+</para>
+
+</sect1>
+
+</appendix>
+
+
Added: blends/trunk/blends/doc/docbook-xml/fr/sgml2xml
URL: http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/docbook-xml/fr/sgml2xml?rev=2414&op=file
==============================================================================
--- blends/trunk/blends/doc/docbook-xml/fr/sgml2xml (added)
+++ blends/trunk/blends/doc/docbook-xml/fr/sgml2xml Tue Oct 26 16:58:17 2010
@@ -1,0 +1,131 @@
+#!/usr/bin/python
+# -*- coding: utf-8 -*-
+
+"""
+transformation de Docbook-sgml en Docbook-xml
+"""
+import re, sys
+
+def changeTag1(source, from_, to_):
+ """
+ Change les tags, sans récupérer les attributs du tag ouvrant
+ @param source un texte source
+ @param from_ le tag de départ
+ @param to_ le tag de remplacement
+ @return le texte modifié.
+ """
+ openPattern="<%s>" %from_
+ closePattern="</%s>" %from_
+ out1=re.sub(openPattern,"<%s>" %to_, source)
+ out2=re.sub(closePattern,"</%s>" %to_, out1)
+ return out2
+
+def changeTag2(source, from_, to_):
+ """
+ Change les tags, en récupérant les attributs du tag ouvrant
+ @param source un texte source
+ @param from_ le tag de départ
+ @param to_ le tag de remplacement
+ @return le texte modifié.
+ """
+ openPattern="<%s(([^1-9][^>]*)?)>" %from_
+ closePattern="</%s>" %from_
+ out1=re.sub(openPattern,"<%s\\1>" %to_, source)
+ out2=re.sub(closePattern,"</%s>" %to_, out1)
+ return out2
+
+def changeItems(source):
+ """
+ change les <item>...</item> en <listitem><para>...</para></listitem>
+ @param source un texte source
+ @return le texte modifié.
+ """
+ out1=re.sub("<item>", "<listitem><para>", source)
+ out2=re.sub("</item>", "</para></listitem>", out1)
+ return out2
+
+def retireLocalVar(source):
+ """
+ retire la partie consacrée aux variables locales
+ @param source un texte source
+ @return le texte modifié.
+ """
+ out1=re.sub("<!-- Keep this comment at the end of the file[^>]*-->",
+ "", source)
+ return out1
+
+def traiteStrong(source):
+ """
+ traite les balises <strong>...</strong>
+ @param source un texte source
+ @return le texte modifié.
+ """
+ out1=re.sub("<strong>", "<emphasis role=\"strong\">", source)
+ out2=re.sub("</strong>", "</emphasis>", out1)
+ return out2
+
+def traiteUlink(source):
+ """
+ traite les balises <ulink> qui sont insuffisamment travaillées avant ça
+ @param source un texte source
+ @return le texte modifié.
+ """
+ out1=re.sub("<ulink([^>]*)id=[\"']([^\"']+)[\"']([^>]*)>",
+ "<ulink\\1url=\"\\2\"\\3>", source)
+ out2=re.sub("<ulink([^>]*)name=[\"']([^\"']+)[\"']([^>]*)>",
+ "<ulink\\1\\3>\\2</ulink>", out1)
+ return out2
+
+def traiteXref(source):
+ """
+ traite les balises <xref> qui sont insuffisamment travaillées avant ça
+ @param source un texte source
+ @return le texte modifié.
+ """
+ out1=re.sub("<xref([^>]*)id=[\"']([^\"']+)[\"']([^>]*)>",
+ "<xref\\1linkend=\"\\2\"\\3 />", source)
+ return out1
+
+if __name__=="__main__":
+ changes1=["p", "para",
+ "tag","term",
+ "em","emphasis",
+ "file","filename",
+ "var","varname",
+ "prgn","command",
+ "example","programlisting"
+ ]
+ changes2=["chapt","chapter",
+ "heading","title",
+ "sect2","sect3",
+ "sect1","sect2",
+ "sect","sect1",
+ "list","itemizedlist",
+ "enumlist","orderedlist",
+ "taglist","variablelist",
+ "url", "ulink",
+ "ref","xref",
+ ]
+ infile=open(sys.argv[1],"r")
+ source=infile.read()
+ infile.close()
+ for i in range(0, len(changes1),2):
+ from_=changes1[i]
+ to_=changes1[i+1]
+ source=changeTag1(source, from_, to_)
+ for i in range(0, len(changes2),2):
+ from_=changes2[i]
+ to_=changes2[i+1]
+ source=changeTag2(source, from_, to_)
+ source=changeItems(source)
+ source=traiteStrong(source)
+ source=traiteUlink(source)
+ source=traiteXref(source)
+ source=retireLocalVar(source)
+ if len (sys.argv) > 2 and sys.argv[2]=="change" :
+ outfile=open(sys.argv[1]+".tmp","w")
+ outfile.write(source)
+ else:
+ print source,
+
+
Propchange: blends/trunk/blends/doc/docbook-xml/fr/sgml2xml
------------------------------------------------------------------------------
svn:executable = *
More information about the Blends-commit
mailing list