[Blends-commit] r2881 - in /blends/trunk/blends/doc/en: 01_introduction.sgml 02_about.sgml

tille at users.alioth.debian.org tille at users.alioth.debian.org
Thu Jul 7 11:38:10 UTC 2011


Author: tille
Date: Thu Jul  7 11:38:09 2011
New Revision: 2881

URL: http://svn.debian.org/wsvn/blends/?sc=1&rev=2881
Log:
Inject summary of current discussion about the difference between Blend and derivative into the docs

Modified:
    blends/trunk/blends/doc/en/01_introduction.sgml
    blends/trunk/blends/doc/en/02_about.sgml

Modified: blends/trunk/blends/doc/en/01_introduction.sgml
URL: http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/en/01_introduction.sgml?rev=2881&op=diff
==============================================================================
--- blends/trunk/blends/doc/en/01_introduction.sgml (original)
+++ blends/trunk/blends/doc/en/01_introduction.sgml Thu Jul  7 11:38:09 2011
@@ -9,7 +9,7 @@
   packages tailored in a different way.
 </p>
 <p>
-Debian Pure Blends (formerly known as Custom Debian Distributions)
+Debian Pure Blends
 provide support for special user interests.  They implement a new
 approach to cover interests of specialised users, who might be
 children, lawyers, medical staff, visually impaired people, etc.  Of
@@ -17,6 +17,14 @@
 those is to make installation and administration of computers for
 their target users as easy as possible, and to serve in the role as
 the missing link between software developers and users well.
+</p>
+<p>
+To clarify the relation between a Blend and a derivative which is
+frequently mixed up Ben Armstrong said in a
+<url id="http://lists.debian.org/debian-blends/2011/07/msg00010.html"
+     name="discussion on the Blends mailing list">:
+"While a Blend strives to mainstream with Debian, a derivative
+ strives to differentiate from Debian."
 </p>
 <p>
 Using the object oriented approach as an analogy, if Debian as a whole

Modified: blends/trunk/blends/doc/en/02_about.sgml
URL: http://svn.debian.org/wsvn/blends/blends/trunk/blends/doc/en/02_about.sgml?rev=2881&op=diff
==============================================================================
--- blends/trunk/blends/doc/en/02_about.sgml (original)
+++ blends/trunk/blends/doc/en/02_about.sgml Thu Jul  7 11:38:09 2011
@@ -224,6 +224,78 @@
 </p>
 </sect>
 
+<sect>
+  <heading>Difference between a Blend and a derivative</heading>
+
+<sect1>
+<heading>Technical</heading>
+<p>
+The process for creation of a blend involves starting with a Debian or
+derivative repository and creating an image directly from that (live,
+install or otherwise) that contains a selection of material from that
+repository delivered in such a way that it is usable by a particular
+target user for a particular purpose with a minimum of effort.
+</p>
+<p>
+By contrast, the process of remastering generally involves first
+downloading an image produced by the parent distro (live, install or
+otherwise,) then tearing it apart and reassembling it with your
+customizations applied.
+</p>
+</sect1>
+
+<sect1>
+<heading>Philosophical</heading>
+<p>
+The blends philosophy is to work as closely with the parent distro as
+possible. If possible, the project should be done entirely within the
+distro as a subproject, containing only material supplied by the parent
+distro. We call this a "Pure Blend".
+</p>
+<p>
+The remastering philosophy (if it can be called that) seems to be
+"whatever works" and involves little or no interaction with the parent
+distro. It's a lazy approach used by people who have newly discovered
+that they can hack images to make them into custom images to make
+something uniquely theirs. Probably fine for quick-and-dirty results,
+but hard to support in the long run.
+</p>
+<p>
+The users of a blend are served better than the users of a
+remaster because of the following advantages:
+</p>
+
+<sect2>
+<heading>Technical advantage</heading>
+<p>
+A new version of a well-crafted blend ought to be able to be produced at
+any time directly from the repository simply by building it; the user
+has some assurance that the resulting system remains 'untainted' by
+hacking it up with scripts that 'damage' the original system by removing
+files from packages, changing files in packages, etc. something that
+hurts maintainability / support for such a system.
+</p>
+</sect2>
+
+<sect2>
+<heading>Community advantage</heading>
+<p>
+A blend project aims to leverage support resources from the existing
+community to serve some sub-community within it. They accomplish this by
+not violating Debian packaging policy, producing something that is
+either pure Debian (a "pure blend") or Debian + additional packages,
+rather than some frankendistro artlessly stitched together from someone
+else's distro with scripts that change things everywhere with no regard
+to policy. Thus, normal support channels can be used with a pure blend
+since what you end up with is not a derivative at all, but just Debian,
+set up and ready to go for whatever you wanted to use it for.
+</p>
+</sect2>
+
+</sect1>
+
+</sect>
+
 </chapt>
 
 <!-- Keep this comment at the end of the file




More information about the Blends-commit mailing list