[Cdd-commits] r543 - in cdd/trunk/cdd/doc: . en

CDD Subversion Commit noreply at alioth.debian.org
Tue Feb 5 21:36:40 UTC 2008


Author: tille
Date: Tue Feb  5 21:36:40 2008
New Revision: 543

Added:
   cdd/trunk/cdd/doc/en/08_websentinel.sgml
   cdd/trunk/cdd/doc/en/09_todo.sgml
Removed:
   cdd/trunk/cdd/doc/en/08_todo.sgml
Modified:
   cdd/trunk/cdd/doc/debian-cdd.en.sgml
Log:
Added description of web sentinel tools


Modified: cdd/trunk/cdd/doc/debian-cdd.en.sgml
==============================================================================
--- cdd/trunk/cdd/doc/debian-cdd.en.sgml	(original)
+++ cdd/trunk/cdd/doc/debian-cdd.en.sgml	Tue Feb  5 21:36:40 2008
@@ -9,7 +9,8 @@
     <!entity ch-inside          system "en/05_inside.sgml">
     <!entity ch-technology	system "en/06_technology.sgml">
     <!entity ch-starting        system "en/07_starting.sgml">
-    <!entity ch-todo            system "en/08_todo.sgml">
+    <!entity ch-websentinel     system "en/08_websentinel.sgml">
+    <!entity ch-todo            system "en/09_todo.sgml">
     <!entity ap-devel           system "en/A_devel.sgml">
     <!entity ap-quickintro      system "en/B_quickintro.sgml">
     <!entity ap-bts             system "en/C_bts.sgml">
@@ -29,6 +30,7 @@
     &ch-inside;
     &ch-technology;
     &ch-starting;
+    &ch-websentinel;
     &ch-todo;
 
     &ap-devel;

Added: cdd/trunk/cdd/doc/en/08_websentinel.sgml
==============================================================================
--- (empty file)
+++ cdd/trunk/cdd/doc/en/08_websentinel.sgml	Tue Feb  5 21:36:40 2008
@@ -0,0 +1,168 @@
+<chapt id="sentinel">
+  <heading>The web sentinel</heading>
+
+  <sect id="packageslist">
+  <heading>Existing and prospective packages</heading>
+
+<p>
+If a Custom Debian Distribution 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 CDD 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 CDD.  The build process works
+as follows:
+ <list>
+ <item>Read dependency information of the <file>tasks</file> files.</item>
+ <item>Verify whether there is really a package with this name and
+       print the description of this package.</item>
+ <item>If there is no such package in Debian try to parse
+       the <file>tasks</file> file whether there is some information
+       given and mark the result as prospective package for further
+       inclusion.</item>
+ </list>
+</p>
+<p>
+The rationale behind this is to provide as much as possible
+information about packages that might be interesting for the target
+user of the CDD.  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 CDD.  The information is
+following the RFC822 syntax as all Debian control files do and is
+kept quite simple:
+<taglist>
+  <tag>Depends / Recommends / Suggests</tag>
+   <item>Even if there is no Debian package available for the moment
+         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 meta package does not have to
+         be changed and will work out of the box after rebuilding.
+   </item>
+  <tag>Homepage</tag>
+   <item>This is the URL to the software that should be packaged.
+   </item>
+  <tag>WNPP</tag>
+   <item>In case there might be a WNPP bug filed for this software the
+       bug number is given here.  This helps to keep track of the
+       ongoing effort to package the software.
+   </item>
+  <tag>Responsible</tag>
+   <item>In case some developer claimed to care for the software
+       (perhaps by issuing the WNPP bug report) the e-mail address of
+       this developer is given here to enable an easy way to contact
+       this person.
+   </item>
+  <tag>License</tag>
+   <item>Debian cares always about the license.  This information
+       about prospective packages should be easily available.
+   </item>
+  <tag>Pkg-URL</tag>
+   <item>In some cases there are unofficial packages for some software
+       which are prepared by a third party.  It helps our users if
+       they could install such a package and thus the URL to it might
+       be a helpful hint.  This is also true for developers because
+       they might have a look at this packaging before they start from
+       scratch.  Often packages are available
+       at <url id="http://mentors.debian.net/"
+       name="mentors.debian.net"> and prepared by people who do not
+       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 CDD tasks list
+       it might speed up the inclusion into official Debian
+       distribution.
+   </item>
+  <tag>Pkg-Description</tag>
+   <item>This tag should give reasonable information about the
+       software as it normally is done in <file>debian/control</file>
+       files.  It can be either a copy of the description of the WNPP
+       bug or could be used to file a WNPP bug and thus helps to
+       simplify the packaging work.
+   </item>
+</taglist>
+</p>
+
+  </sect>
+
+  <sect id="ddtp">
+  <heading>Debian Description Translation Project</heading>
+
+<p>
+The <url id="http://ddtp.debian.net/" name="Debian Description
+Translation Project"> (see <ref id="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 CDD is to make the CDD even more usable for our
+target users.  Moreover people interested in the special field of the
+CDD 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.
+</p>
+<p>
+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.
+</p>
+
+  </sect>
+
+   <sect id="bugs">
+  <heading>Bugs overview</heading>
+<p>
+The goal of a CDD is to support their user as best as possible.  So a
+feature to have a quick overview about all packages in our focus might
+be helpful.  This is solved by the bugs overview page.  To create this
+page the <file>tasks</file> files are parsed for the listed
+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 CDD.
+</p>
+   </sect>
+
+   <sect id="svnoverview">
+  <heading>SVN overview</heading>
+<p>
+This page gives a recent overview about the current development
+activities of the CDD developers.
+</p>
+  </sect>
+
+  <sect id="qareport">
+   <heading>Quality assurance report</heading>
+
+<p>
+The Debian Quality Assurance group does a decent job in watching the
+status o f Debian packages.  If a package features a
+valid <file>debian/watch</file> the tool <prgn>uscan</prgn> is able to
+verify the upstream source location for newer versions.  The QA report
+page reports issues about the packages that are relevant for a CDD.
+</p>
+  </sect>
+
+</chapt>
+
+<!-- Keep this comment at the end of the file
+Local variables:
+mode: sgml
+sgml-omittag:nil
+sgml-shorttag:t
+sgml-namecase-general:t
+sgml-general-insert-case:lower
+sgml-minimize-attributes:nil
+sgml-always-quote-attributes:t
+sgml-indent-step:2
+sgml-indent-data:t
+sgml-parent-document:("../debian-cdd.en.sgml" "book" "chapt")
+sgml-exposed-tags:nil
+sgml-local-catalogs:nil
+sgml-local-ecat-files:nil
+End:
+-->

Added: cdd/trunk/cdd/doc/en/09_todo.sgml
==============================================================================
--- (empty file)
+++ cdd/trunk/cdd/doc/en/09_todo.sgml	Tue Feb  5 21:36:40 2008
@@ -0,0 +1,644 @@
+<chapt id="todo">
+  <heading>To do</heading>
+
+  <sect id="communication">
+  <heading>Establishing and using communication platforms</heading>
+
+<p>
+Each Custom Debian Distribution has an own mailing list for discussion
+of specific development issues.  Because there are several common
+issues between all Custom Debian Distributions also a common mailing
+list was created. People who are interested in working on common
+issues like building meta packages, technical issues of menu systems
+or how to create CDs for Custom Debian Distributions could <url
+id="http://lists.debian.org/debian-custom/" name="subscribe to this
+list or read the list archive">.
+</p>
+<p>
+Moreover the project <url
+id="http://alioth.debian.org/projects/cdd/" name="cdd"> on Alioth was
+started.  The <url id="http://svn.debian.org/viewcvs/cdd/"
+name="subversion repository"> can be browsed or checked out by
+by
+<example>
+  svn checkout svn://svn.debian.org/svn/cdd/cdd/trunk
+</example>
+for anonymous users. Developers should check out via
+<example>
+  svn checkout svn+ssh://<var>username</var>@svn.debian.org/svn/cdd/cdd/trunk cdd
+</example>
+The current layout for the repository is as follows:
+<example>
+  cdd -+- cdd -+- branches -+- cdd -+- 0.3.x
+       |       |
+       |       +- tags -----+- cdd -+- 0.3   [older versions of cdd tools]
+       |       |            |       +- 0.3.1
+       |       |            |          ...
+       |       |            |       +- <var>&lt;latest&gt;</var>
+       |       |            |
+       |       |            +- doc -+- 0.1   [older versions of this doc]
+       |       |                    +- 0.2
+       |       |                    +- 0.3
+       |       |                        [Since 0.4.1 the doc is in cdd directory]
+       |       |
+       |       +- trunk ----cdd [code in development for cdd source package]
+       |                     |
+       |                     +-- doc [this document = cdd-doc package]
+       |
+       +- projects -+--- med ---+- branches
+                    |           |
+                    |           +- tags
+                    |           |
+                    |           +- trunk [development version of Debian-Med]
+                    |
+                    +- science -+- branches
+                    |           |
+                    |           +- tags
+                    |           |
+                    |           +- trunk [development version of Debian-Science]
+                    |
+                    +- ...
+                    |
+                    ...
+</example>
+There is a <url
+id="http://lists.alioth.debian.org/mailman/listinfo/cdd-commits"
+name="mailing list"> with subversion changes and a <url
+id="http://cia.navi.cx/stats/project/debian-custom" name="CIA system">
+for tracking changes in the Custom Debian Distributions projects in
+real-time.
+</p>
+  </sect>
+
+  <sect id="visibility">
+  <heading>Enhancing visibility</heading>
+
+<p>
+If a user installs Debian via official install CDs the first chance to
+do a package selection to customise the box is <prgn>tasksel</prgn>.
+The first Custom Debian Distribution Debian-Junior is mentioned in the
+task selection list and thus it is clearly visible to the user who
+installs Debian.
+</p>
+<p>
+In bug <url id="http://bugs.debian.org/186085" name="#186085"> a
+request was filed to include Debian-Med in the same manner.  The
+problem with the <prgn>tasksel</prgn>-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 Custom Debian Distributions would be included in the task
+selection list.
+</p>
+<p>
+How to enhance visibility of Custom Debian Distributions for the user
+who installs Debian from scratch?
+<taglist>
+  <tag>Change <prgn>tasksel</prgn> policy.</tag>
+   <item>If the <em>packages must be on the first CD</em> feature of
+         <prgn>tasksel</prgn> would be dropped all Custom Debian
+	 Distributions could be listed under this topic in the task
+	 selection list.
+   </item>
+  <tag>Custom Debian Distributions information screen.</tag>
+   <item>Alternatively a new feature could be added to
+         <prgn>tasksel</prgn> or in addition to <prgn>tasksel</prgn>
+	 in the installation procedure which presents a screen which
+	 gives some very short information about Custom Debian
+	 Distributions (perhaps pointing to this document for further
+	 reference) and enables the user to select from a list of the
+	 available Custom Debian Distributions.
+   </item>
+  <tag>Provide separate install CDs</tag>
+   <item>By completely ignoring the installation of the official
+         installation CD each Custom Debian Distribution 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 Custom Debian Distribution on one
+	 computer.
+   </item>
+  <tag>Change overall distribution philosophy of Debian.</tag>
+   <item>This way is concerned to some ideas from Debian developers
+         who took part in Open Source World Conference in Malaga and
+	 is explained in Detail in <ref
+	 id="new_ways_of_distribution">. This would save the problem
+	 of making Custom Debian Distribution visible to users in a
+	 completely different way because in this case Debian would be
+	 released as its various flavours of Custom Debian
+	 Distributions.
+   </item>
+</taglist>
+</p>
+<p>
+Whichever way Debian developers will decide to go it is our vital
+interest to support users and <em>show</em> our users the tools we
+invented to support them.
+</p>
+   <sect1 id="webpages">
+  <heading>Custom Debian Distributions web pages</heading>
+<p>
+Most Custom Debian Distributions maintain their own web space under 
+<tt>http://www.debian.org/devel/cdd</tt> 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.  A special
+way to announce what is done and what is planed is the list of yet
+packaged software and software which is intended to be included.  To
+do this in a nice manner Tobias Toedter
+<email>t.toedter at gmx.net</email> defined a new tag for Debian-Med
+in order to ease translation by making use of the 
+<prgn>gettext</prgn> functionality. In the meantime, this new tag was
+extended to be useful for other Custom Debian Distributions as well.
+</p>
+<p>
+As a result, a new <file>.pot</file> file was created, called
+<file>debian-cdd.pot</file>.  Translators of the web pages should
+update their <file>.po</file> files and translate this new file into
+their language.  For the translation teams who have already begun to
+translate the web pages of the Debian-Med Custom Debian Distribution,
+here is a short explanation of the newly introduced tag and its use.
+The tag is called <tt>project</tt>, and it takes a few attributes. The
+complete (empty) tag looks like this:
+
+<example>
+&lt;project name=&quot;&quot;
+  url=&quot;&quot;
+  license=&quot;&quot;
+  deb=&quot;&quot;
+  anchorid=&quot;&quot;&gt;
+  Here goes the description of the project.
+&lt;/project&gt;
+</example>
+
+The meaning of the attributes is as follows:
+
+<taglist>
+  <tag>name</tag>
+   <item>This is the name of the project which is yet packaged or
+         should be packaged for the Custom Debian Distribution in
+         question. In most cases, you won't have to translate this
+         attribute.</item>
+  <tag>url</tag>
+   <item>This is the URL of the homepage of the project. You will
+         almost never have to do any translational work here. At least
+         I can't think of any.
+   </item>
+  <tag>license</tag>
+   <item>The license under which the project is released. In most
+         cases (e.g. GPL, BSD) you don't have to modify anything
+         here. Some projects use a custom license or there's anything
+         other which requires some more explanation in plain text. Of
+         course, this plain text should be translated. 
+   </item>
+  <tag>deb</tag>
+   <item>This is the URL of a Debian package. If the project is
+         available as an official Debian package (i.e. it is included
+         in the Debian distribution or available in the contrib or
+         non-free section) or if the project is being packaged by
+         someone, but not stored on the Debian servers, this attribute
+         is used. If there's no package available at all, this
+         attribute is either left blank or omitted completely. There's
+         no need to change this value in your translations.
+   </item>
+  <tag>anchorid</tag>
+   <item>Every project gets an automatically created HTML anchor. This
+         auto-anchor is created by using the project's name (Convert
+         all ASCII characters into lowercase and replace any other
+         character with the underscore. Silly example: "BioSig - For
+         Everyone" -> "biosig___for_everyone"). If for some reason
+         this is not wanted, the id and name of the anchor can be
+         specified with this attribute. An example of the use of this
+         attribute can be found in other.wml. The project's name is
+         "HARP - HArmonisation for the secuRity of web technologies
+         and aPplications", which is awfully long. The anchorid
+         attribute in this case is set to "harp". Note that you should
+         never have to change anything here, if it is already defined
+         in the English page.  If you have to translate the name of
+         the project, the automatic creation of the anchorid will
+         naturally give a different result then the English
+         anchorid. In this case, please use this attribute to manually
+         specify the anchor which should be used, according to the
+         rules above: Convert all (ASCII) characters into lowercase,
+         and replace any other character with an underscore.  So in
+         conclusion, you should always use the anchorid attribute if
+         you've translated the name attribute.
+   </item>
+</taglist>
+
+The interesting part of the <tt>project</tt>-tag is the body, between
+the opening and the closing tag. This is the description of the
+project, and this is the part where you're going to have to translate
+the text.  The best way to learn the usage of this tag is to have a
+look at the Debian-Med examples.
+</p>
+<p>
+Moreover it might make sense to sort the list of projects according to
+the following keys:
+<taglist>
+  <tag>available Debian package</tag>
+   <item>Top most you should list all packages which are just inside
+         Debian and thus (hopefully) included in the meta package
+	 dependencies.  This should be followed by the projects which
+	 has unofficial packages outside Debian.  A last group should
+	 list all not yet packaged projects which are interesting for
+	 the Custom Debian Distribution.  These groups are using a
+	 certain green-yellow-red color code.
+   </item>
+  <tag>alphabetically</tag>
+   <item>Inside each of these three groups an alphabetical order is
+         proposed to gain some consistency between all Custom Debian
+	 Distributions.
+   </item>
+</taglist>
+The users who are visiting the web pages will like this comfortable
+overview ...
+</p>
+   </sect1>
+   <sect1 id="graphingwebpages">
+  <heading>Automatically graphing the meta-package dependencies for web
+  pages</heading>
+<p>
+The new <package>cddtk</package> contains a tool which allows browsing
+a <file>Packages</file> file for all packages that are listed in the
+dependency list of a package. 
+
+<example>
+   pkgtool -p UNCOMPRESSED_PACKAGES_FILE pdeps LIST_OF_PACKAGE_NAMES
+</example>
+
+This could be used as a start to build the web-pages as suggested above
+automatically - at least for the packages which are just at the
+Debian-Mirror.  For the unofficial packages and not yet existing
+packages a fake-<file>Packages</file> following the same syntax could
+be created and processed with the same tool.
+</p>
+   </sect1>
+  </sect>
+
+  <sect id="debtags">
+   <heading>Debian Package Tags</heading>
+
+<p>
+<url id="http://deb-usability.alioth.debian.org/debtags/" name="Debian
+Package Tags">  is a work to add more metadata to Debian packages.
+At the beginning it could be seen as a way to allow to specify
+multiple sections (called "tags") per package where now only one can
+be used.
+</p>
+<p>
+However, the system has evolved so that tags are organised in
+"facets", which are separate ontologies used to categorise the
+packages under different points of view.
+</p>
+<p>
+This means that the new categorisation system supports tagging
+different facets of packages.  There can be a set of tags for the
+"purpose" of a package (like "chatting", "searching", "editing"),
+a set of tags for the technologies used by a package (like "html",
+"http", "vorbis") and so on.
+</p>
+<p>
+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 CDDs is that every CDD could maintain its
+own set of tags organised under a "facet", providing categorisation
+data which could be used by its users and which automatically
+interrelates with the rest of the tags.
+</p>
+<p>
+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.
+</p>
+<p>
+It is not excluded that this could evolve in being able to create a
+Custom Debian Distribution just by selecting all packages tagged by
+"edu::*" tags, plus dependencies; however, this option is still being
+investigated.
+</p>
+<p>
+Please write to the list <email>deb-usability-list at lists.alioth.debian.org</email>
+for more information about Debian Package Tags or if you want to get
+involved in Debian Package Tags development.
+</p>
+  </sect>
+
+  <sect id="EnhancingTechnology">
+  <heading>Enhancing basic technologies regarding Custom Debian Distributions</heading>
+
+<p>
+In section <ref id="future_handling"> several issues where raised how
+handling of meta packages should be enhanced.
+</p>
+<p>
+Regarding to building meta packages for all Custom Debian
+Distributions consistently it might make sense to use the following
+approach:
+</p>
+  <!-- FIXME: How to indent a paragraph??? -->
+  <p>
+   The method how Debian-Edu currently builds its meta packages from a
+   kind of <em>database</em> (in the <file>tasks</file> directory of the source)
+   was generalised in the packages <package>cdd-dev</package> (<ref
+   id="cdd-dev">) and <package>cdd-common</package> (<ref
+   id="cdd-common">).  This approach definitely needs some
+   enhancements to fit the needs of all Custom Debian Distributions.
+   It might be a good idea to maintain a more general kind of database
+   than this <file>tasks</file> directory approach currently represents
+   for each Custom Debian Distribution.  From
+   this database the control files for all meta packages could be
+   built on demand to build the necessary files of the
+   <file>debian</file> directory in the package build process
+   dynamically.  The extra plus would be that it would be easy to
+   build tools which parse this database to generate docs and websites
+   dynamically.  It would drastically reduce the amount of work for
+   keeping the project related web sites up to date if this could be
+   done automatically.  Some tools like the following might be easily
+   done to support maintenance and documentation of the meta packages:
+<example>
+       build_cdd-package med bio
+       build_cdd-package junior toys
+       build_cdd-package education [all]
+
+       build_cdd-wml-template nonprofit &lt;foo&gt;
+       build_cdd-wml-template demudi    &lt;bar&gt;
+
+       cdd-package-info.php?cdd=&lt;foo&gt;&amp;pkg=&lt;bar&gt;
+</example>
+   If the database structure is well thought (perhaps using XML or by
+   stealing the format of other databases which are usually used in
+   Debian) not really hard to implement.
+</p>
+<p>
+Last but not least the special configuration issue has to be
+addressed.  In general developers of meta packages should provide
+patches for dependent packages if they need a certain configuration
+option and the package in question does feature a
+<prgn>debconf</prgn> configuration for this case.  Then the
+meta package could provide the needed options by pre-seeding the
+<prgn>debconf</prgn> database while using very low priority questions
+which do not came to users notice.
+</p>
+<p>
+If the maintainer of a package which is listed in a meta package
+dependency and needs some specific configuration does not accept such
+kind of patch it would be possible to go with a <prgn>cfengine</prgn>
+script which just does the configuration work.  According to the
+following arguing this is no policy violation:  A local maintainer can
+change the configuration of any package and the installation scripts
+have to care for these changes and are not allowed to disturb these
+adaptations.  In the case described above the <prgn>cfengine</prgn>
+script takes over the role of the local administrator: It just handles
+as an
+"automated-<prgn>cfengine</prgn>-driven-administrator-robot".
+</p>
+<p>
+If there is some agreement to use <prgn>cfengine</prgn> scripts to
+change configuration - either according to <prgn>debconf</prgn>
+questions or even to adapt local configuration for Custom Debian
+Distribution 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 meta package the suggestion would be to
+store this stuff under
+<example>
+   /usr/share/cdd/#CDD#/#METAPACKAGE#/cf.#SOMETHING#
+</example>
+</p>
+<p>
+There was another suggestion at the Valencia workshop: Make use of
+<prgn>ucf</prgn> for the purpose mentioned above.  This is a topic
+for discussion.  At least currently Debian-Edu seems to have good
+experiences with <prgn>cfengine</prgn> but perhaps it is worth comparing
+both.
+</p>
+<p>
+A further option might be 
+<url id="http://freedesktop.org/Software/CFG" name="Config4GNU"> from
+freedesktop.org but it is not even yet packaged for Debian.
+</p>
+  </sect>
+
+  <sect id="liveCD">
+  <heading>Building Live CDs of each Custom Debian Distribution</heading>
+
+<p>
+The first step to convince a user to switch to Debian is to show him
+how it works while leaving his running system untouched.
+<url id="http://www.knoppix.org/" name="Knoppix"> - <em>the "mother" of
+all Debian-based live CDs</em> - is a really great success and it is a
+fact that can not be ignored that Debian gains a certain amount of
+popularity because people want to know what distribution is working
+behind the scenes of Knoppix.
+</p>
+<p>
+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 CDD
+scope are out of date because they way the usually were builded was a
+pain.  One exception is perhaps <url id="http://dirk.eddelbuettel.com/quantian.html"
+name="Quantian"> which is quite regularly updated and is intended for
+scientists.
+</p>
+<p>
+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 CDD 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
+cdd-dev version.
+</p>
+
+  </sect>
+
+  <sect id="new_ways_of_distribution">
+  <heading>New way to distribute Debian</heading>
+
+<p>
+<em>This section is kind of "Request For Comments" in the sense that
+solid input and arguing is needed to find out whether it is worth
+implementing it or drop this idea in favour of a better solution.</em>
+</p>
+<p>
+At Open Source World Conference in Malaga 2004 there was a workshop of
+Debian Developers. Among other things the topic was raised how the
+distribution cycle or rather the method of distribution could be
+changed to increase release frequency and to better fit user interests.
+</p>
+<p>
+There was a suggestion by Bdale Garbee <email>bdale at gag.com</email> to
+think about kind of sub-setting Debian in the following way: Debian
+developers upload their packages to <tt>unstable</tt>.  The normal
+process which propagates packages to <tt>testing</tt> and releasing a
+complete <tt>stable</tt> distribution also remains untouched.  The new
+thing is that the package pool could be enhanced to store more package
+versions which belong to certain subsets alias Custom Debian
+Distributions which all have a set of <tt>tested inside the
+subset</tt> distribution which leads to a <tt>stable</tt> subset
+release.  The following graph might clarify this:
+
+<example>
+DD -> unstable   -->  testing  -->  stable
+         |
+         +--->  CDD_A testing  -->  stable CDD_A
+         |
+         +--->  CDD_B testing  -->  stable CDD_B
+         |
+         +--->  ...
+</example>
+
+where <tt>CDD_A</tt> / <tt>CDD_B</tt> might be something like
+<tt>debian-edu</tt> / <tt>debian-med</tt>. To implement this
+sub-setting the following things are needed:
+<taglist>
+  <tag>Promotion rules</tag>
+   <item>There was a general agreement that technical implementation
+         of this idea in the package pool scripts / database is not too
+	 hard.  In fact at LinuxTag Chemnitz 2004 Martin Loschwitz
+	 <email>madkiss at debian.org</email> announced exactly this as
+	 "nearly implemented for testing purpose" which should solve
+	 the problem of outdated software for desktop users as a goal
+	 of the <tt>debian-desktop</tt> project.
+   </item>
+  <tag>Reasonable subsets</tag>
+   <item>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
+	 Custom Debian Distribution layout or if there are better ways
+	 to find subsets.
+   </item>
+  <tag>BTS support</tag>
+   <item>The Bug Tracking System has to deal with different package
+         versions or even version ranges to work nicely together with
+	 the sub-setting approach.
+   </item>
+  <tag>Security</tag>
+   <item>As a consequence of having more than only a single
+         <tt>stable</tt> each CDD-team has to form a security team to
+	 care for those package versions that are not identically with
+         the "old" <tt>stable</tt>.
+   </item>
+</taglist>
+</p>
+<p>
+A not so drastically change would be to find a <em>common</em> set of
+packages which are interesting for all Custom Debian Distributions
+which will obtained from the "releasable set" of testing (i.e. no
+RC-bugs).  This would make the structure above a little bit more flat:
+
+<example>
+DD -> unstable --> testing --> releasable --> stable
+                                   |
+                                   +--->      stable CDD_A
+                                   |
+                                   +--->      stable CDD_B
+                                   |
+                                   +--->  ...
+</example>
+
+A third suggestion was given at Congreso Software Libre Comunidad
+Valenciana:
+
+<example>
+           testing_proposed_updated
+                      |
+                      |
+                      v
+DD -> unstable --> testing --> stable
+                      |
+                      +--->    stable CDD_A
+                      |
+                      +--->    stable CDD_B
+                      |
+                      +--->  ...
+</example>
+
+The rationale behind these testing backports is that sometimes a
+Custom Debian Distribution 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 Custom Debian Distribution.  For instance this might make
+sense for Debian-Edu where usually i386 architecture is used.
+</p>
+<p>
+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 Custom Debian
+Distributions 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 Custom Debian Distribution,
+would take over support only for the subset of packages which is
+included in the meta package 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:
+
+<example>
+  debian/dists/stable/binary-i386
+                     /binary-sparc
+                     /binary-...
+              /testing/...
+              /unstable/...
+  debian-CDD_A/dists/stable/binary-[supported_architecture1]
+                           /binary-[supported_architecture2]
+                           /...
+                    /testing/...
+  debian-CDD_B/dists/testing/...
+                    /stable/...
+  ...
+  pool/main
+      /contrib
+      /non-free
+</example>
+To avoid flooding the archive with unnecessarily many versions of
+packages for each single Custom Debian Distribution a common base of
+all these Custom Debian Distributions has to be defined.  Here some
+LSB conformance statement comes into mind: The base system of all
+currently released (stable) Custom Debian Distributions is compliant
+to LSB version x.y.
+</p>
+<p>
+Regarding to security issues there are two ways: Either one Custom
+Debian Distribution goes with the current stable Debian and thus the
+<file>Packages.gz</file> 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
+one certain Custom Debian Distribution they should be made reliable
+for this certain subset.
+</p>
+<p>
+This reduced subset of Debian packages of a Custom Debian Distribution
+would also make it easier to provide special install CDs at is it
+currently done by Debian-Edu.
+</p>
+  </sect>
+</chapt>
+
+<!-- Keep this comment at the end of the file
+Local variables:
+mode: sgml
+sgml-omittag:nil
+sgml-shorttag:t
+sgml-namecase-general:t
+sgml-general-insert-case:lower
+sgml-minimize-attributes:nil
+sgml-always-quote-attributes:t
+sgml-indent-step:2
+sgml-indent-data:t
+sgml-parent-document:("../debian-cdd.en.sgml" "book" "chapt")
+sgml-exposed-tags:nil
+sgml-local-catalogs:nil
+sgml-local-ecat-files:nil
+End:
+-->



More information about the Cdd-commits mailing list