[Cdd-commits] r979 - cdd/trunk/docs/papers/200808_cdd
CDD Subversion Commit
noreply at alioth.debian.org
Sun Jul 13 14:05:08 UTC 2008
Author: tille
Date: Sun Jul 13 14:05:07 2008
New Revision: 979
Modified:
cdd/trunk/docs/papers/200808_cdd/cdd-paper.tex
Log:
Paper as uploaded to Penta
Modified: cdd/trunk/docs/papers/200808_cdd/cdd-paper.tex
==============================================================================
--- cdd/trunk/docs/papers/200808_cdd/cdd-paper.tex (original)
+++ cdd/trunk/docs/papers/200808_cdd/cdd-paper.tex Sun Jul 13 14:05:07 2008
@@ -194,7 +194,7 @@
the target audience. Considering this we tried to develop simple ways
to categorise packages that are useful for certain tasks. This is
done in so called tasks files which are processed using the
-\package{cdd-dev} package to build meta packages. The other
+\package{cdd-dev} package to build metapackages. The other
application of these tasks files is building internationalised web
pages which display the packages that are relevant for a certain CDD
task with the descriptions of the packages. The translation for the
@@ -256,15 +256,15 @@
There are some similar efforts like CDD in other distributions for
instance there is a comparable effort to package biological Free
Software done by
-\printurl{http://kambing.ui.edu/gentoo-portage/sci-biology/}{Gentoo}
-or \printurl{http://www.freebsdsoftware.org/biology/}{FreeBSD} because
+\printurl{kambing.ui.edu/gentoo-portage/sci-biology/}{Gentoo}
+or \printurl{www.freebsdsoftware.org/biology/}{FreeBSD} because
also other distributors realised the problem described above. The
difference between such kind of installable software collections and
a CDD is that a Custom Debian Distribution tries to do more than
just packaging specific software. It is rather about forming a team
of maintainers who try to build a consistent system around several
tasks in a specific field, care for easily installation using
-meta-packages, making sure that everything works together smoothly and
+metapackages, making sure that everything works together smoothly and
working actively as missing link between upstream developers and users.
@@ -272,7 +272,7 @@
The main work of a distributor is providing precompiled binaries of
Free Software, caring for smooth installation and upgrades as well as
-security fixes for the distributet packages. In the case of Debian
+security fixes for the distributed packages. In the case of Debian
which maintains the largest pool of ready to install binary software
packages this is quite a large amount of work. The huge amount of
software includes larger subset of software for very specific use and
@@ -284,26 +284,84 @@
on a technical level because several jobs to do are at least similar.
This idea is the basis of the whole CDD effort: Making sure that the
wheel that drives a certain CDD is only invented once and adopted for
-all others. The
-
-
-Attracting derivers
+all others. There is a similar situation in the internationalisation
+teams: There is a well defined group of users (speakers of a certain
+language) who need special support (translations at various places)
+and it make sense if language teams just work together and use common
+tools like DDTP server and others.
+
+While this translation work is one part of the internationalisation
+team it can not stop here. It is also about proving that Debian is
+flexible enough to incorporate this kind of changes instead of forcing
+users to make language based forks of Debian. Unfortunately there are
+many people out there who feature a wrong concept of using Free
+Software. They read the license as they are allowed to modify the
+software as modifying their local copy and tweak it until it fits
+their needs. They treat this constant forking as the normal way to
+customise their distribution. The internationalisation team has done
+a good job in propagating the idea that it is better to include
+translations into Debian than adding translations over and over for
+every new release of Debian.
+
+In principle the maintainers of a CDD have the same job: Attracting
+derivers who have not yet understood the power of internal
+customisation inside a CDD to reach their goal -- optimal support of
+their users -- more efficiently. The most convincing example how a
+CDD managed to merge a derivative back to Debian is that the
+educational branch of \printurl{www.linex.org}{LinEx} is
+working on unification with Debian Edu since end of year 2007.
\section{Techniques}
-\subsection{Building metapackages}
+The techniques used are based on sorting certain packages of the
+Debian pool into certain remits or in the terminology we have chosen
+in CDDs ``tasks''. So the tasks files are listing dependencies from
+Debian packages and different tools are using these as common source
+of information.
+
+\subsection{Building metapackages and tasksel descriptions}
+
+The \package{cdd-dev} can be used to build a set of metapackages and
+tasksel descriptions. Because the technique is described in very
+detail in the \printurl{cdd.alioth.debian.org/cdd}{article about CDD}
+there is no need to repeat the content here. I would rather ask you
+to follow the link and especially read section {\em 6.1 Metapackages}.
+
+The build process using \package{cdd-dev} also included the creation
+of a \package{CDD-tasks} package which contains information for
+tasksel to enable the tasks of a CDD via tasksel.
-\subsection{Web pages based on common scripts}
-\section{Summary}
+\subsection{Web pages based on common scripts}
-Custom Debian Distributions might solve future structural problems of
-Debian while fitting better user interests. If done the right way it
-makes Debian stronger and is sometimes refered to as: ``\emph{The last,
- final step towards Total World Domination.}''
-
-From a \Debian developers point of view we are really {\em
- universal}. From a random users point of view we are not -- but we
-are perfectly able to reach this goal.
+A quite new feature are the web pages that are builded based on the
+very same information that is used to build the metapackages. This
+enables users to get a very quick overview because they see all
+packages included in the task together with the description. Because
+the target audience does not necessarily is comfortable with English
+language the descriptions are even translated in case there is such a
+translation provided by the \printurl{ddtp.debian.net}{Debian
+ Description Translation Project}. Such pages are available for
+the following projects:
+
+\begin{itemize}
+ \item \printurl{cdd.alioth.debian.org/edu/tasks}{Debian Edu}
+ \item \printurl{cdd.alioth.debian.org/gis/tasks}{Debian GIS}
+ \item \printurl{cdd.alioth.debian.org/junior/tasks}{Debian Junior}
+ \item \printurl{debian-med.alioth.debian.org/tasks}{Debian Med}
+ \item \printurl{cdd.alioth.debian.org/science/tasks}{Debian Science}
+\end{itemize}
+
+In addition to the packages existing inside Debian there is an easy
+way to specify prospective packages that should be included into
+Debian in the future. These packages are listed on the web pages
+as well. To read more about this feature just have a look into the
+\printurl{cdd.alioth.debian.org/cdd}{article about CDD} especially
+section {\em 8.1 Existing and prospective packages}.
+
+There is no need to copy the information of the just existing article
+about CDD which is continuously updated and thus this document ends
+here with the strong recommendation to read the technical details
+there.
\end{document}
More information about the Cdd-commits
mailing list