[Blends-commit] [SCM] blends-gsoc branch, master, updated. aaccbb9b9a8175d72ac9e3d3d00cc52d19fe6a0f
Emmanouil Kiagias
e.kiagias at gmail.com
Fri Sep 20 13:12:15 UTC 2013
The following commit has been merged in the master branch:
commit aaccbb9b9a8175d72ac9e3d3d00cc52d19fe6a0f
Author: Emmanouil Kiagias <e.kiagias at gmail.com>
Date: Fri Sep 20 15:11:59 2013 +0200
added doc/en/06_technology.bug.xml converted documentation. this page is still buggy/contains errors, to be fixed(mostly orgname tags and package tags)
diff --git a/doc/debian-blends.en.xml b/doc/debian-blends.en.xml
index 9512602..a6c5b22 100644
--- a/doc/debian-blends.en.xml
+++ b/doc/debian-blends.en.xml
@@ -9,6 +9,7 @@
<!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"> -->
]>
@@ -21,5 +22,6 @@
&ch-general-ideas;
&ch-existing-blends;
&ch-inside;
+ <!-- &ch-technology; -->
</book>
\ No newline at end of file
diff --git a/doc/en/06_technology.bug.xml b/doc/en/06_technology.bug.xml
new file mode 100644
index 0000000..6cbd38c
--- /dev/null
+++ b/doc/en/06_technology.bug.xml
@@ -0,0 +1,962 @@
+<chapter id="technology">
+ <title>Technology</title>
+
+ <sect1 id="metapackages">
+ <title>Metapackages</title>
+
+ <sect2 id="defmetapackages">
+ <title>Metapackage definition</title>
+
+<para>
+A metapackage, as used by Blends, is a Debian package that contains:
+
+<itemizedlist>
+ <listitem><para>Dependencies on other Debian packages (essential)</para>
+ <variablelist>
+
+ <varlistentry>
+ <term>Depends</term>
+ <listitem><para>Use "Depends" for packages that are definitely needed
+ for all basic stuff of the Blend in question.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Recommends</term>
+ <listitem><para>The packages that are listed as "Recommends" in the
+ tasks file should be installed on the machine where the
+ metapackage is installed and which are needed to work
+ on a specific task.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Suggests</term>
+ <listitem><para>Use "Suggests" for others of lesser importance that
+ might be possibly useful, or non-free packages. When a
+ package is not available for the target distribution at
+ metapackage build time the "Recommends" is turned into
+ a "Suggests" to enable a flawless installation of the
+ metapackage.</para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </listitem>
+ <listitem>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>
+ </listitem>
+ <listitem>
+ <para>Configuration stuff (optional)</para>
+ <itemizedlist>
+ <listitem><para><orgname>debconf</orgname> questions or pre-seeding</para></listitem>
+ <listitem><para><orgname>cfengine</orgname> scripts (or similar see <!-- <xref linkend="EnhancingTechnology"/>-->)</para></listitem>
+ </itemizedlist>
+ </listitem>
+ <listitem><para>Special metapackages:</para>
+ <itemizedlist>
+ <listitem><para><package><varname><blend></varname>-tasks</package>:
+ Contains information for <orgname>tasksel</orgname></para></listitem>
+ <listitem><para><package><varname><blend></varname>-config</package>:
+ Special configurations, basic stuff for user menus</para></listitem>
+ </itemizedlist>
+ </listitem>
+</itemizedlist>
+
+</para>
+
+<para>
+Metapackages are small packages with nearly no contents. The main
+feature of this type of package is its dependencies on other
+packages. The naming of metapackages follows the pattern
+<varname><blend></varname>-<varname><task></varname>
+where <varname><blend></varname> stands for the short name of a Debian
+Pure Blend, e.g. <package>junior</package> for Debian
+Jr. or <package>med</package> for Debian Med,
+and <varname><task></varname> means the certain task inside the Blend,
+e.g. puzzle or bio.
+</para>
+
+<para>
+
+Examples:
+<variablelist>
+
+<varlistentry>
+ <term><package>junior-puzzle</package></term>
+ <listitem><para>Debian Jr. Puzzles</para></listitem>
+</varlistentry>
+
+<varlistentry>
+ <term><package>education-tasks</package></term>
+ <listitem><para>Tasksel files for SkoleLinux systems</para></listitem>
+</varlistentry>
+
+<varlistentry>
+ <term><package>med-bio</package></term>
+ <listitem><para>Debian Med micro-biology packages</para></listitem>
+</varlistentry>
+
+</variablelist>
+</para>
+
+</sect2>
+ <sect2 id="collection">
+ <title>Collection of specific software</title>
+
+<para>
+When using metapackages, no research for available software inside Debian is
+necessary. It would not be acceptable for normal users to have to browse the
+descriptions of the whole list of the 20000 packages in Debian to find
+everything they need. So, metapackages are an easy method to help users to
+find the packages that are interesting for their work quickly.
+</para>
+<para>
+If the author of a metapackage includes several packages with similar
+functionality, an easy comparison between software covering the same task is
+possible.
+</para>
+<!-- This is not true any more since we turn Depends into Recommends
+ to explicitely *enable* users to remove certain packages.
+
+Moreover, the installation of a metapackage ensures that no package
+that is necessary for the intended task can be removed without
+explicit notice that also the metapackage has to be removed. This
+helps non specialist administrators to keep the installation fit for
+the specialized users.
+ -->
+<para>
+By defining conflicts with some other packages inside the metapackage,
+it is possible to ensure that a package that might conflict for some
+reasons for the intended task can not be installed at the same time as
+the metapackage is installed.
+</para>
+<para>
+All in all, metapackages enable an easy installation from scratch, and
+keep the effort required for administration low.
+</para>
+
+</sect2>
+ <sect2 id="categorisation">
+ <title>Packages showing up in more than one metapackage</title>
+
+<para>
+This seems to be an FAQ: If a package <subjectterm>A</subjectterm> is in the list of
+dependencies of metapackage <subjectterm>m</subjectterm> is it allowed or reasonable to
+add it to the list of dependencies of metapackage <subjectterm>n</subjectterm>?
+</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 <subjectterm>x</subjectterm> depends from package
+<subjectterm>libc</subjectterm> no other package is allowed to add <subjectterm>libc</subjectterm> to its
+depends. So why not adding a dependency to more than one metapackage if
+it is just useful for a certain task?
+</para>
+
+<para>
+The important thing is to support our users. A specific user wants to
+solve a certain task (and thus installs a certain metapackage). The
+question whether some Dependencies are also mentioned in a different
+metapackage is completely useless for this task. So in fact we do
+<emphasis>not</emphasis> build a categorisation tree but build pools of useful
+software for certain tasks which can definitely have overlaps.
+</para>
+
+<para>
+To give a certain example which was asked by a member of Debian
+Multimedia team: A user who is seeking for his optimal sound player is
+not served best if we "hide" an application from his view by
+including it into sound recorders exclusively. While chances might be
+good that a sound recorder is not as lightweight as a pure player the
+user will find out this quickly if he is looking for only a
+lightweight player - but perhaps he becomes happy later about the
+"added value" of his favourite player if it also is able to record
+sound.
+</para>
+
+ </sect2>
+
+ <sect2 id="configuration">
+ <title>Adapted configuration inside metapackages</title>
+
+<para>
+Besides the simplification of installing relevant packages by
+dependencies inside metapackages, these packages might contain special
+configuration for the intended task. This might either be
+accomplished by pre-seeding <orgname>debconf</orgname> questions, or by
+modifying configuration files in a <orgname>postinst</orgname> 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
+<orgname>postinst</orgname> script takes over the role of a local
+administrator.
+<!-- FIXME:
+ An improved version of the pre-seeding scripts are included in newer
+ debconf versions. I just replaced the debian-edu scripts with the
+ scripts from debconf. Look at debconf-set-selections and
+ debconf-get-selections.
+ -->
+</para>
+
+ </sect2>
+
+ <sect2 id="documentation">
+ <title>Documentation packages</title>
+
+<para>
+A "traditional" weakness of Free Software projects is missing
+documentation. To fix this, Debian Pure Blends try to provide
+relevant documentation to help users to solve their problems. This
+can be done by building <package>*-doc</package> packages of existing
+documentation, and by writing extra documentation, like manpages, etc.
+By supplying documentation, Debian Pure Blends fulfil their role in
+addressing the needs of specialised users, who have a great need for
+good documentation in their native language.
+</para>
+<para>
+Thus, translation is a very important thing to make programs more
+useful for the target user group. Debian has established
+a <ulink url="http://ddtp.debian.net/">Debian Description
+Translation Project</ulink>, which has the goal to translate package
+descriptions. There is a good chance this system could also be used
+for other types of documentation, which might be a great help for
+Debian Pure Blends.
+</para>
+
+ </sect2>
+ </sect1>
+
+ <sect1 id="mp_handling">
+ <title>Handling of metapackages</title>
+
+<para>
+<!-- [BA] I think we need to qualify what 'handle' means, because there
+ certainly are other tools that 'handle' them (e.g. synaptic) if that term
+ is taken in its broadest sense.
+ [AT] ACK, here that we have to define 'handle'. The term
+ 'nicely' was intended to be the keyword because metapackages are
+ currently handled as any other package which is fine, but no help
+ for users who do not know anything about metapackages. We need
+ special tools to gain all profits we could have. Could you set
+ this into good English???
+ -->
+In short, there are no special tools available to handle metapackages
+nicely. But there are some tricks that might help, for the moment.
+</para>
+
+ <sect2 id="cmdline">
+ <title>Command line tools</title>
+
+<para>
+<variablelist>
+
+<varlistentry>
+ <term><orgname>apt-cache</orgname></term>
+ <listitem><para>
+ The program <orgname>apt-cache</orgname> is useful to search for
+ relevant keywords in package descriptions. With it, you could search
+ for a certain keyword connected to your topic (for instance
+ "<subjectterm>med</subjectterm>") and combine it reasonably with <orgname>grep</orgname>:</para>
+ <example>
+~> 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
+ </example>
+ <para>
+ This is <emphasis>not really straightforward</emphasis>, and
+ absolutely unacceptable for end users.
+ </para>
+
+ </listitem>
+</varlistentry>
+
+<varlistentry>
+ <term><orgname>grep-dctrl</orgname></term>
+ <listitem><para>
+ The program <orgname>grep-dctrl</orgname> is a grep for Debian package
+ information, which is helpful for extracting specific package details
+ matching certain patterns:</para>
+ <example>
+~> 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 ...
+ </example>
+ <para>
+ This is, like the <orgname>apt-cache</orgname> example, <emphasis>also
+ a bit cryptic</emphasis>, and again is not acceptable for end users.
+ </para>
+ </listitem>
+</varlistentry>
+
+<varlistentry>
+ <term><orgname>auto-apt</orgname></term>
+ <listitem><para>
+ The program <orgname>auto-apt</orgname> 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
+ <orgname>auto-apt</orgname> in the following manner to guarantee that you
+ have all of the files or programs you need:</para>
+ <example>
+~> 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
+ </example>
+
+ <para>
+ Just do your normal business - in the above example, <subjectterm>less
+ /usr/share/doc/med-bio/copyright</subjectterm> - and if the necessary
+ package is not yet installed, <orgname>auto-apt</orgname> will care for
+ the installation and proceed with your command. While this is
+ really cool, this is <emphasis>not really intended for a production
+ machine</emphasis>.
+ </para>
+
+ </listitem>
+</varlistentry>
+
+</variablelist>
+
+The short conclusion here is: <emphasis>There are no sophisticated tools
+that might be helpful to handle metapackages as they are used in
+Debian Pure Blends - just some hacks using the powerful tools inside
+Debian.</emphasis>
+</para>
+
+ </sect2>
+
+ <sect2 id="text_ui">
+ <title>Text user interfaces</title>
+<para>
+
+<variablelist>
+
+<varlistentry>
+ <term><orgname>tasksel</orgname></term>
+ <listitem>
+ <para>
+ The Debian task installer <orgname>Tasksel</orgname> is the first
+ interface for package selection that is presented to the user when
+ installing a new computer. The <subjectterm>End-user</subjectterm> section should
+ contain an entry for each Debian Pure Blend.
+ Unfortunately, there are some issues that prevent Blends
+ from being included in the <orgname>tasksel</orgname> 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, <orgname>tasksel</orgname> is a good
+ tool for easy installation of Blends.
+ </para>
+ <para>
+ As a workaround for this problem the <orgname>blends-dev</orgname>
+ framework creates a package <subjectterm>BLEND-tasks</subjectterm> which contains
+ a <orgname>tasksel</orgname> control file. If you install this package
+ all tasks of the Blend will be added to the default list of tasks
+ inside <orgname>tasksel</orgname>. 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><orgname>aptitude</orgname></term>
+ <listitem><para>
+ This is a better replacement for <orgname>dselect</orgname>, and has
+ some useful support for searching for and grouping of packages.
+ While this is not bad, it was not intended for the purpose of
+ handling Debian Pure Blends, and thus there could be some better
+ support to handle metapackages more cleverly.</para>
+ </listitem>
+</varlistentry>
+
+</variablelist>
+
+Short conclusion: <emphasis>There is a good chance metapackages could be
+handled nicely by the text based Debian package administration tools,
+but this is not yet implemented.</emphasis>
+</para>
+
+ </sect2>
+
+ <sect2 id="gui">
+ <title>Graphical user interfaces</title>
+<para>
+Debian <emphasis>Woody</emphasis> does not contain a really nice graphical
+user interface for the Debian package management system. But the
+efforts to support users with an easy to use tool have increased, and
+so there there will be some usable options in Sarge.
+
+<variablelist>
+
+<varlistentry>
+ <term><orgname>gnome-apt</orgname></term>
+ <listitem><para>This is the native GNOME flavour of graphical user interfaces
+ to apt. It has a nice <subjectterm>Search</subjectterm> feature that can be
+ found in the <subjectterm>Package</subjectterm> menu section. If for instance
+ the packages of the Debian Jr. project come into the focus of
+ interest a search for "<subjectterm>junior-*</subjectterm>" 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><orgname>synaptic</orgname></term>
+ <listitem><para>Even more sophisticated and perhaps the best choice for users
+ of Debian Pure Blends. <orgname>Synaptic</orgname> has a nice
+ filter feature, which makes it a great tool here.
+ Moreover <orgname>synaptic</orgname> is currently the only user
+ interface that supports Debian Package Tags
+ (see <!-- <xref linkend="debtags"/> --> ).</para>
+ </listitem>
+</varlistentry>
+
+<varlistentry>
+ <term><orgname>kpackage</orgname></term>
+ <listitem><para>This is the user interface of choice for KDE lovers.
+ Regarding its features (with exception of Debian Package Tags)
+ it is similar to both above.</para>
+ </listitem>
+</varlistentry>
+
+</variablelist>
+
+Short conclusion: <emphasis>As well as the text based user interfaces
+these tools are quite usable but need enhancements to be regarded as
+powerful tools for Debian Pure Blends.</emphasis>
+</para>
+ </sect2>
+
+ <sect2 id="web_if">
+ <title>Web interfaces</title>
+
+<para>
+
+<variablelist>
+
+<varlistentry>
+ <term>Tasks pages</term>
+ <listitem><para>The tasks pages probably provide the best overview about
+ the actual work which is done in a Debian Pure Blend. These
+ pages are automatically generated by reading the tasks files
+ (see <!-- <xref linkend="debian_control"/> -->) and verifying the existence
+ of the packages that are mentioned as dependencies. On the
+ resulting web page the packages are listed with some meta
+ information and the description of the package. As user
+ oriented pages they are translated into more than 10
+ languages while translated means, the navigation text of the
+ page generating code is using <orgname>gettext</orgname> 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
+ <example>
+ http://blends.alioth.debian.org/BLEND/tasks
+ </example>
+ where <subjectterm>BLEND</subjectterm> has to be replaced by the name of the
+ Blend. Currently these pages are available for the Blends:
+ <example>
+ accessibility, edu, gis, junior, lex, science, debichem
+ </example>
+ The tasks pages are available for Debian Med as well but for
+ historical reasons the URL for these pages is
+ <example>
+ http://debian-med.alioth.debian.org/tasks
+ </example>
+ 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
+ <example>
+ http://blends.alioth.debian.org/BLEND/bugs
+ </example>
+ where <subjectterm>BLEND</subjectterm> has to be replaced by the name of the
+ Blend. Currently these pages are available for the Blends:
+ <example>
+ accessibility, edu, gis, junior, lex, science, debichem
+ </example>
+ The bugs pages are available for Debian Med as well but for
+ historical reasons the URL for these pages is
+ <example>
+ http://debian-med.alioth.debian.org/bugs
+ </example>
+ 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>
+<!-- <comment>FIXME: & is sometimes broken!!!
+<url id="http://packages.debian.org/cgi-bin/search_packages.pl?keywords=med-&subword=1">
+ ^^^^^
+</comment> -->
+<ulink url="http://packages.debian.org/cgi-bin/search_packages.pl?keywords=med-&subword=1"/>
+ </para>
+ <para>
+ As a result you will get a list of all Debian Med packages.</para>
+ </listitem>
+</varlistentry>
+
+<varlistentry>
+ <term><ulink url="http://qa.debian.org/developer.php">Package Tracking System</ulink></term>
+ <listitem><para>
+ The Package Tracking System is a really great tool that
+ provides essential information about packages. Most Debian
+ Pure Blends are using a mailing list address as Maintainer of
+ their key packages which includes the metapackages. This so
+ called team maintenance of packages is on one hand very handy
+ from a developers point of view on the other hand it enables
+ using the Package Tracking System to get a quick overview:
+ </para>
+ <variablelist>
+ <varlistentry>
+ <term>Debian Jr:</term>
+ <listitem><para>
+ <ulink url="http://qa.debian.org/developer.php?login=debian-jr@lists.debian.org"/>
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Debian Med:</term>
+ <listitem> <para>
+ <ulink url="http://qa.debian.org/developer.php?login=debian-med-packaging@lists.alioth.debian.org"/>
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Debian Edu:</term>
+ <listitem><para>
+ <ulink url="http://qa.debian.org/developer.php?login=debian-edu@lists.debian.org"/>
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Debian Science:</term>
+ <listitem><para>
+ <ulink url="http://qa.debian.org/developer.php?login=debian-science-maintainers@lists.alioth.debian.org"/>
+ </para>
+ </listitem>
+ </varlistentry>
+
+ </variablelist>
+ <para>
+ Hint: If you append the option <orgname>&ordering=3</orgname> you
+ might get some sectioning of this page according to the
+ metapackage categories. This result is approached by a tool
+ which subscribes all dependent packages to the group
+ maintenance address and adds a section according to a
+ metapackage name.
+ </para>
+ <para>
+ The other way to use the Package Tracking System is to search
+ for packages starting with a certain letter:
+ <variablelist>
+ <varlistentry>
+ <term>Debian Jr:</term>
+ <listitem><para>
+ <ulink url="http://packages.qa.debian.org/j"/></para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Debian Med:</term>
+ <listitem><para>
+ <ulink url="http://packages.qa.debian.org/m"/></para>
+ </listitem>
+ </varlistentry>
+
+ </variablelist>
+ But the list that is obtained by this method is much larger
+ than it would be useful for a good overview.
+ </para>
+ </listitem>
+</varlistentry>
+
+<varlistentry>
+ <term><orgname>list-junior.sh</orgname></term>
+ <listitem><para>The package <package>junior-doc</package> contains a script
+ <filename>/usr/share/doc/junior-doc/examples/scripts/list-junior.sh</filename>
+ that checks for the installed packages of a Blend and builds
+ a simple web page describing these packages. (The BTS
+ contains a patch to let this script work also for other
+ Blends.)</para>
+ </listitem>
+</varlistentry>
+
+</variablelist>
+
+Short conclusion: <emphasis>The Debian Pure Blends provide some nice web
+ tools for a whole set of packages for a certain working field that
+ provide a better overview than the usual Debian tools that are
+ basically dealing with single packages..</emphasis>
+</para>
+ </sect2>
+
+ <sect2 id="future_handling">
+ <title>Future handling of metapackages</title>
+
+<para>
+Obviously there are no nifty tools as you might know them from Debian
+available yet. The user interfaces for <orgname>apt-get</orgname> 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 <orgname>aptitude</orgname>,
+ <orgname>synaptic</orgname>, etc.</para></listitem>
+ <listitem><para>Special <orgname>tasksel</orgname> 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 <!-- <manref name="blend-update-menus" section="8"> -->(see
+<!-- <xref linkend="blend-update-menus"/> -->) script from
+<package>blends-common</package>. It has to be said that using
+<orgname>blend-update-menus</orgname> is not enough to change the menu of a
+user. To accomplish this a call of the general
+<orgname>update-menu</orgname> script for every single user of a Blend is
+necessary if this is not done by the
+<filename>postinst</filename> script of a metapackage. This can easily been
+done if the configuration file of a Debian Pure Blend
+<filename>/etc/blends/<varname><blend></varname>/<varname><blend></varname>.conf</filename> contains the
+line
+<example>
+ UPDATEUSERMENU=yes
+</example>
+
+</para>
+<para>
+It is strongly suggested to use the
+package <package>blends-dev</package> to build metapackages of a
+Debian Pure Blend that will move all necessary files right into place
+if there exists a
+<filename>menu</filename> directory with the menu entries. Note, that the users
+<filename>${HOME}/.menu</filename> directory remains untouched.
+</para>
+ </sect3>
+
+ <sect3 id="user-debconf">
+ <title>Managing Debian Pure Blend users with <orgname>debconf</orgname></title>
+
+<para>
+Using <package>blends-dev</package> it is very easy to build a
+<varname>blend</varname><package>-config</package> package that contains
+<orgname>debconf</orgname> scripts to configure system users who should
+belong to the group of users of the Debian Pure Blend <varname>blend</varname>.
+For example see the <package>med-common</package> package.
+
+ <example>
+~> 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
+ </example>
+This example shows the situation when you
+<orgname>dpkg-reconfigure</orgname> <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 <orgname>simple-cdd</orgname> 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. <orgname>Simple-cdd</orgname> also makes it easy to build CDs
+with language and country settings pre-configured, or to use a 2.6
+kernel by default.
+</para><para>
+This can be used to create a crude "Debian Pure Blend" using
+packages from Debian, with pre-configuration of packages that use
+<orgname>debconf</orgname>. Custom configuration scripts can be specified
+to handle packages that don't support <orgname>debconf</orgname>
+pre-configuration.
+</para><para>
+Testing CD images with <orgname>qemu</orgname> is also made simple with a
+provided script.
+</para><para>
+It has only been tested with <orgname>debian-cd</orgname> from Etch (other
+than <orgname>debpartial-mirror</orgname>), so if using a new
+<orgname>debian-cd</orgname> or <orgname>debian-installer</orgname>, it may
+require some tweaks.
+</para>
+ </sect2>
+ </sect1>
+
+</chapter>
+
--
Git repository for blends-gsoc code
More information about the Blends-commit
mailing list