File: 08_todo.sgml

package info (click to toggle)
cdd-doc 0.3
  • links: PTS
  • area: main
  • in suites: etch, etch-m68k, sarge
  • size: 228 kB
  • ctags: 17
  • sloc: makefile: 87
file content (844 lines) | stat: -rw-r--r-- 37,560 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
<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/trunk -+-- cdd [code for cdd source package]
       |             |
       |             +-- doc [this document = cdd-doc package]
       |
       +- projects -+- med/trunk    [Debian-Med source for meta packages]
                    |
                    +- junior/trunk [Debian-Jr]
                    |
                    ...
</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@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 webpages 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 - HArmonization 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 inofficial 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 alphabethical 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>
  </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 organized in
"facets", which are separate ontologies used to categorize the
packages under different points of view.
</p>
<p>
This means that the new categorization 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 categorization, one of the first outcomes
of Debian Package Tags for CDDs is that every CDD could maintain its
own set of tags organized under a "facet", providing categorization
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 dependancies; however, this option is still being
investigated.
</p>
<p>
Please write to the list <email>deb-usability-list@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 dependend 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.  This
adaptation can have different focuses:
<taglist>
  <tag>Distribution</tag>
   <item>The original Knoppix CD is based on a mixture of Debian
         <tt>testing</tt>, <tt>unstable</tt> and even packages from
	 other sources than the official Debian mirror.  There are
	 Knoppix derivatives like <url id="http://www.gnoppix.org/"
	 name="Gnoppix"> which try to stick to <tt>stable</tt> or at
	 least to one defined set of Debian packages.

   </item>
  <tag>User interface</tag>
   <item>Knoppix has a highly customised KDE environment which just
         works as it is.  There are efforts to release live CDs with
	 Gnome interface (Gnoppix), XFCE or other desktops which are
	 able to cope with less system resources.
   </item>
  <tag>Kernel</tag>
   <item>There are certain reasons to exchange the kernel of the
         Knoppix CD like in the <url
	 id="http://bofh.be/clusterknoppix/"
	 name="ClusterKnoppix">-Project which uses an OpenMosix kernel.
   </item>
  <tag>Special applications</tag>
   <item>Most of the Knoppix derivatives aim at providing special
         applications for the purpose of demonstration, training of a
	 classroom using the Knoppix net-boot feature or just having
	 the favourite application always available by just carrying a
	 CD in the wallet.  Examples are:
       <taglist>
         <tag><url id="http://www.osef.org/"
                   name="Knoppix4Kids"></tag>
          <item>Knoppix for Children - connected to Debian-Jr.</item>
         <tag><url id="http://dirk.eddelbuettel.com/quantian.html"
                   name="Quantian"></tag>
          <item>Remastered "ClusterKnoppix" for the needs of Mathematicians</item>
         <tag><url
	           id="http://sourceforge.net/project/showfiles.php?group_id=9295"
                   name="LiveOIO">
          <item>Knoppix with PostgreSQL and Zope to run OIO -
                interesting for Debian-Med.</item>
         <tag><url
	           id="http://marvin.ba-loerrach.de/gnumed.iso"
                   name="ISO image of GnuMed Knoppix">
          <item>Knoppix with PostgreSQL and GnuMed -
                interesting for Debian-Med.</item>
         <tag><url
	           id="http://www.vigyaancd.org/"
                   name="Vigyaan">
          <item>Knoppix for computational biology and computational
                chemistry containing ClustalX, BLAST (NCBI-tools),
                Open Babel, EMBOSS tools, GROMACS, Ghemical, PyMOL and
		others.</item> 
         <tag><url
	           id="http://bioknoppix.hpcf.upr.edu/"
                   name="BioKnoppix">
          <item>A very similar project to the previous which
                specialises Knoppix for computational biology
                chemistry containing EMBOSS, Jemboss, Artemis,
                ClustalX, Cn3D, ImageJ, BioPython, Rasmol, BioPerl,
                Bioconductor and others.</item> 
       </taglist>
   </item>
  <tag>Similar projects</tag>
   <item>In the past there was some confusion about of the goals of
         Live-CD building projects.  Even at the Debian development
	 plattform <url id="alioth.debian.org"> do some similar
	 projects exist.
       <taglist>
        <tag><url id="http://alioth.debian.org/projects/debix/"
	          name="Debix">
         <item><p>Debix is a collection of scripts to create live
               filesystems ranging from cloning any existing linux
	       system, providing a comfortable environment for the
	       boot-floppies and debian installer up to a full blown
	       live filesystem comparable with Knoppix.</p>
               <p>When the author Goswin von Brederlow
	       <email>brederlo@informatik.uni-tuebingen.de</email> was
	       asked about his goals he answered: "Debix is a level
	       below knoppix I would say. If you handle the knoppix
	       debs and scripts you could use debix to make seemingly
	       writeable cd images out of a tar.gz or a directory
	       containing the knoppix tree."
               </p>
               <p>Debix is more than one thing:
                <enumlist>
                  <item>A tool to make a live-cd out of any linux system.</item>
                  <item>Premade sets of package lists and configuration and patches to
                        automatically create nice live-cds like knoppix.</item>
                </enumlist>
                In cvs (on alioth) is a version of Debix that can be
                called "proof of concept" of part 1. Work is in
                progress of changing the build scripts to be modular
                and flexible so part 2 can be started. 
               </p>
               <p>Debix can provide the infrastructure. Knoppix has to
	       supply the debs that should be in a Knoppix set for
	       debix. The 2 parts mean that Debix is suposed as tool
	       to create a live-cd from an existing or hand build
	       system but also a tool that can build such system
	       automatically according to preset rules (list of debs
	       and some cleanup scripts if needed).
               </p>
         </item>
        <tag><url id="http://alioth.debian.org/projects/metadistros/" name="Metadistros">
	 <item><p>Debian Metadistros goal is to allow you easily
               remastering Live-CD distributions like Knoppix to fit
               your or you users needs, within Debian.</p>
               <p>It is a little bit hard to get information about
               this project, because most of the information is in
               Spanish language.</p>
               <p>One piece of the docs which Sergio Talens-Oliag
                  <email>sto@debian.org</email> has kindly translated
                  says: "... the main problem is that Debian wants a
                  Debian tool to make its own LiveCDs but Metadistros
                  wants to give tools to let anyone create a
                  distribution that can be used as LiveCD and/or
                  installed and be based in whatever linux
                  distribution the user  wants.  Anyway, he said that
                  if they can cooperate in any way they will be happy
                  to do it."
               </p>
         </item>
        <tag><url id="http://www.morphix.org/" name="Morphix">
	 <item><p>Morphix is a modular GNU/Linux distribution on livecd's
               (you burn the CD, you put it in your CD-Rom drive, you
               boot and it works... no harddisk-installation
               necessary, doesn't touch your data). Also, installing
               Morphix on a harddisk is a breeze, if you want to. Just
               click on the icon on the desktop, or choose the
               installer from the morphix/babytux submenu. Morphix
               should still be considered experimental in nature. No
               guarentees are given, use Morphix at your own risk!</p>
	       <p>
               ISO's with XFCE4, Gnome2.4, KDE3.1, a game iso and a
               large number of derivatives are available. Morphix is an Open
               Source/Free software project, based on Debian GNU/Linux
               and Knoppix.</p>
         </item>
        <tag><url id="http://ibuild.livecd.net/howto.en.php" name="Intellibuild">
	 <item><p>Intellibuild (iBuild) is a set of python scripts
               designed to make the creation/remaster of a Morphix or
               Knoppix LiveCD very simple and easy to do.  You can
               easily modify changes and test them without having to
               remember all of the syntax of the remastering
               commands.</p>
               <p>The idea is to be able to write xml file that would
	       call python scripts that install debian packages and
	       costumize system for you. It is still under heavy
	       development but Slo-Tech Linux and GNUSTEP livecd
	       already use it.</p>
               <p>Currently work is done to build a GUI that will
	       allow you select modules via scripts.  It's currently
	       morphix based even though it could be easily tuned for
	       knoppix or any other debian approaches to livecds.
               </p>
         </item>
     </taglist>
   </item>
</taglist>

So building Live CDs is a common issue for each Custom Debian
Distribution and the goal is to develop a mastering system which
drastically decreases the effort to build such live CDs.  To
accomplish this goal the <url
id="http://alioth.debian.org/projects/debian-knoppix"
name="debian-knoppix"> project on Alioth was created.
</p>
<p>
Currently <em>re-mastering</em> is a top-down strategy:  People who want to
build there own Knoppix-based live CD proceed this way
<enumlist>
  <item>Download a complete ISO image.  Even with
        <package>bittorrent</package> or similar techniques it makes
	no sense to download 700MBytes for each new Knoppix version if
	you might probably need only half of this size for your
	intended use.  Moreover regarding to the fact that Knoppix
	consists mostly of installed Debian packages you might have
	nearly all stuff you need on a local (or at least nearby)
	Debian mirror with a fast connection.
  </item>
  <item>Copy the stuff from the CD to a temporary space.
  </item> 
  <item>Remove packages which are not needed.  This requires some
        research for packages which are worth removing (regarding the
	space which is gained) and which are not needed later on.
  </item>
  <item>After these steps (all of these are quite time consuming and
        need a certain amount of knowledge) some further packages can
	be installed.  In case you want to include some database
	applications or some other applications that need to write a
	certain amount of data your are more or less on your own to
	invent techniques to find out how to do that.  Except from
	some postings in the Knoppix-Mailing list there is no
	reasonable documentation, how to do this right.
  </item>
  <item>Create ISO image from chroot environment and burn it.
  </item>
</enumlist>

It would make much more sense to use a bottom-up strategy and
<em>master</em> the CD instead of re-mastering.  It might even make
sense to build a Custom Debian Distribution for itself to build the
necessary tools for this <em>mastering a Knoppix-Live-CD</em>
approach.  The general way would be as follows:

<enumlist>
  <item>Use <package>debootstrap</package> to build a basic system you
        could <prgn>chroot</prgn> into.
  </item>
  <item>Install Knoppix stuff into chroot environment.  This is the
        hardware detection stuff, the special configuration, etc.
        After this step the system should be in a state like after
        step 3. of the re-mastering process above.  The tricky part to
        accomplish this is to build reasonable Debian packages like
        this:
     <taglist>
        <tag><package>knoppix-hardware</package></tag>
         <item>Contains all the hardware detection stuff</item>
        <tag><package>knoppix-x</package></tag>
         <item>Contains stuff from Knoppix which cares for X.  This is
               not necessarily needed for simple rescue CDs.
         </item>
        <tag><package>knoppix-config</package></tag>
         <item>Special configuration stuff.  Please note these
               packages will be installed into a chroot environment
               which is <em>not</em> a Debian host system.  It might be
               necessary to change the configuration of some packages
               installed in this chroot environment which conflicts to
               Debian policy in a <em>real</em> Debian system.  But
               here we face a special part of our hard-disk (say
               <file>/var/cache/knoppix/etc</file>) which is not
               covered by policy.  The only point is to make sure that
               this <package>knoppix-config</package> package will not
               be installed on a Debian host system (if and only if anything
               is really needed which would not comply with the policy).
         </item>
         <tag><package>knoppix-misc</package></tag>
          <item>Whatever might be needed and is not covered by the
                things above.  Here user support for integrating
                database applications might be integrated.
          </item>
     </taglist>
  </item>
  <item>Customise chroot environment for intended purpose. This is
        the same as in the re-mastering step 4. but it could be
        supported by some tools from <package>knoppix-misc</package>.
  </item>
  <item>Create ISO image from chroot environment and burn it.  While
        this is the same as step 5. but it might also be supported by
        some nifty tools which would simplify things for anybody
        wanting to build their own CD.
  </item>
</enumlist>

This approach would have the additional advantage of being portable
also to non-i386 architectures and in fact Fabian Franz
<email>FabianFranz@gmx.de</email> managed to prove this true for
Power-PC architecture.
  </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@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@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:
-->