[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ A ] [ B ] [ C ] [ next ]
Each Debian Pure Blend has an own mailing list for discussion of specific
development issues. Because there are several common issues between all Blends
also a common mailing list was created. People who are interested in working
on common issues like building metapackages, technical issues of menu systems
or how to create CDs for Blends could subscribe to this list or read
the list archive
.
Moreover the project Blends
on Alioth
exists to organise the cooperation of developers. The subversion repository
can
be browsed or checked out by by
svn checkout svn://svn.debian.org/svn/blends blends
for anonymous users. Developers should check out via
svn checkout svn+ssh://username@svn.debian.org/svn/blends blends
The current layout for the repository is as follows:
blends -+- blends | | | +- tags -----+- blends -+- 0.3 [older versions of blends tools] | | | +- 0.3.1 | | | ... | | | +- <latest> | | | | | +- doc -+- 0.1 [older versions of this doc] | | +- 0.2 | | +- 0.3 | | [Since 0.4.1 the doc is in blends directory] | | | +- trunk ----blends [code in development for blends source package] | | | +-- doc [this document = blends-doc package] | +- projects -+--- med ---+- tags | | | +- trunk [development version of Debian Med] | +- science -+- tags | | | +- trunk [development version of Debian Science] | +- ... | ...
There is a mailing
list
with subversion changes and a CIA system
for
tracking changes in the Debian Pure Blends projects in real-time.
If a user installs Debian via official install CDs the first chance to do a
package selection to customise the box is tasksel
. The first
Debian Pure Blend Debian Junior is mentioned in the task selection list and
thus it is clearly visible to the user who installs Debian.
In bug #186085
a
request was filed to include Debian Med in the same manner. The problem with
the tasksel
-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 Blends would be included in the
task selection list.
How to enhance visibility of Debian Pure Blends for the user who installs Debian from scratch?
tasksel
policy.
If the packages must be on the first CD feature of
tasksel
would be dropped all Blends could be listed under this
topic in the task selection list.
Alternatively a new feature could be added to tasksel
or in
addition to tasksel
in the installation procedure which presents a
screen which gives some very short information about Debian Pure Blends
(perhaps pointing to this document for further reference) and enables the user
to select from a list of the available Blends.
By completely ignoring the installation of the official installation CD each Blend 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 Blend on one computer.
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 New way to distribute Debian, Section 9.6. This would save the problem of making Debian Pure Blends visible to users in a completely different way because in this case Debian would be released as its various flavours of Blends.
Whichever way Debian developers will decide to go it is our vital interest to support users and show our users the tools we invented to support them.
Some Blends maintain their own web space under http://www.debian.org/devel/BLEND-name 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. This page should link to the apropriate autogenerated pages as described in Web interfaces, Section 6.2.4 to make sure that the content of the page remains up to date at any time.
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.
However, the system has evolved so that tags are organised in "facets", which are separate ontologies used to categorise the packages under different points of view.
This means that the new categorisation 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.
Besides being able to perform package selection more efficiently by being able to use a better categorisation, one of the first outcomes of Debian Package Tags for Blends is that every Blend could maintain its own set of tags organised under a "facet", providing categorisation data which could be used by its users and which automatically interrelates with the rest of the tags.
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.
It is not excluded that this could evolve in being able to create a Blend just by selecting all packages tagged by "edu::*" tags, plus dependencies; however, this option is still being investigated.
Please write to the list mailto:deb-usability-list@lists.alioth.debian.org
for more information about Debian Package Tags or if you want to get involved
in Debian Package Tags development.
In section Future handling of metapackages, Section 6.2.5 several issues where raised how handling of metapackages should be enhanced.
Currently there is no solution to address the special configuration issue has
to be addressed. In general developers of metapackages should provide patches
for dependent packages if they need a certain configuration option and the
package in question does feature a debconf
configuration for this
case. Then the metapackage could provide the needed options by pre-seeding the
debconf
database while using very low priority questions which do
not came to users notice.
If the maintainer of a package which is listed in a metapackage dependency and
needs some specific configuration does not accept such kind of patch it would
be possible to go with a cfengine
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
cfengine
script takes over the role of the local administrator: It
just handles as an
"automated-cfengine
-driven-administrator-robot".
If there is some agreement to use cfengine
scripts to change
configuration - either according to debconf
questions or even to
adapt local configuration for Debian Pure Blend 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 metapackage the suggestion would
be to store this stuff under
/usr/share/blends/#BLEND#/#METAPACKAGE#/cf.#SOMETHING#
There was another suggestion at the Valencia workshop: Make use of
ucf
for the purpose mentioned above. This is a topic for
discussion. At least currently Debian Edu seems to have good experiences with
cfengine
but perhaps it is worth comparing both.
A further option might be Config4GNU
from
freedesktop.org but it is not even yet packaged for Debian.
The first step to convince a user to switch to Debian is to show him how it
works while leaving his running system untouched. Knoppix
- the "mother"
of all Debian-based live CDs - 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.
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. In fact there exist so many
Debian based Live CDs that it makes hardly sense to list them all here. The
main problem is that most of them containing special applications and thus are
interesting in the Blends scope are out of date because they way the usually
were builded was a pain. One exception is perhaps Quantian
which is
quite regularly updated and is intended for scientists.
The good news is that the problem of orphaned or outdated Live CDs can easily
solved by debian-live and the live-helper
. This package turns all
work to get an up to date ISO image for a Live CD into calling a single script.
For the Blends tools this would simply mean that the tasks files have to be
turned into a live-helper input file and the basic work is done. This will be
done in a future blends-dev
version.
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.
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.
There was a suggestion by Bdale Garbee mailto:bdale@gag.com
to think about kind
of sub-setting Debian in the following way: Debian developers upload their
packages to unstable. The normal process which propagates
packages to testing and releasing a complete stable
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 Debian Pure Blends which all have a set of tested inside
the subset distribution which leads to a stable subset
release. The following graph might clarify this:
DD -> unstable --> testing --> stable | +---> BLEND_A testing --> stable BLEND_A | +---> BLEND_B testing --> stable BLEND_B | +---> ...
where BLEND_A / BLEND_B might be something like debian-edu / debian-med. To implement this sub-setting the following things are needed:
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 mailto:madkiss@debian.org
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
debian-desktop project. Unfortunately this goal was not realised
finally.
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 Blend layout or if there are better ways to find subsets.
The Bug Tracking System has to deal with different package versions or even version ranges to work nicely together with the sub-setting approach.
As a consequence of having more than only a single stable each Blend team has to form a security team to care for those package versions that are not identically with the "old" stable.
A not so drastically change would be to find a common set of packages which are interesting for all Debian Pure Blends 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:
DD -> unstable --> testing --> releasable --> stable | +---> stable BLEND_A | +---> stable BLEND_B | +---> ...
A third suggestion was given at Congreso Software Libre Comunidad Valenciana:
testing_proposed_updated | | v DD -> unstable --> testing --> stable | +---> stable BLEND_A | +---> stable BLEND_B | +---> ...
The rationale behind these testing backports is that sometimes a Debian Pure Blend 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 Blend. For instance this might make sense for Debian Edu where usually neither mainframes nor embedded devices are used.
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 Debian Pure Blends 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 Blend, would take over support only for the subset of packages which is included in the metapackage 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:
debian/dists/stable/binary-i386 /binary-sparc /binary-... /testing/... /unstable/... debian-BLEND_A/dists/stable/binary-[supported_architecture1] /binary-[supported_architecture2] /... /testing/... debian-BLEND_B/dists/testing/... /stable/... ... pool/main /contrib /non-free
To avoid flooding the archive with unnecessarily many versions of packages for each single Debian Pure Blend a common base of all these Blends has to be defined. Here some LSB conformance statement comes into mind: The base system of all currently released (stable) Debian Pure Blends is compliant to LSB version x.y.
Regarding to security issues there are two ways: Either one Debian Pure Blend
goes with the current stable Debian and thus the Packages.gz
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 a certain Blend they should be made reliable for this certain
subset.
This reduced subset of Debian packages of a Debian Pure Blend would also make it easier to provide special install CDs at is it currently done by Debian Edu.
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ A ] [ B ] [ C ] [ next ]
Debian Pure Blends
22 May 2013mailto:tille@debian.org