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>
<project name=""
url=""
license=""
deb=""
anchorid="">
Here goes the description of the project.
</project>
</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 <foo>
build_cdd-wml-template demudi <bar>
cdd-package-info.php?cdd=<foo>&pkg=<bar>
</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:
-->
|