blends-0.6.16.4ubuntu2/0000755000000000000000000000000012240414671011431 5ustar blends-0.6.16.4ubuntu2/sources.list.raring0000644000000000000000000000007312147323454015276 0ustar deb http://archive.ubuntu.com/ubuntu/ raring main universe blends-0.6.16.4ubuntu2/templates/0000755000000000000000000000000012147323735013435 5ustar blends-0.6.16.4ubuntu2/templates/po/0000755000000000000000000000000012147323735014053 5ustar blends-0.6.16.4ubuntu2/templates/po/templates.pot0000644000000000000000000000446012147323454016577 0ustar # # Translators, if you are not familiar with the PO format, gettext # documentation is worth reading, especially sections dedicated to # this format, e.g. by running: # info -n '(gettext)PO Files' # info -n '(gettext)Header Entry' # # Some information specific to po-debconf are available at # /usr/share/doc/po-debconf/README-trans # or http://www.debian.org/intl/l10n/po-debconf/README-trans # # Developers do not need to manually edit POT or PO files. # #, fuzzy msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2004-06-28 15:58+0200\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=CHARSET\n" "Content-Transfer-Encoding: 8bit\n" #. Type: multiselect #. Description #: ../config.templates:4 msgid "#BLENDNAME# users:" msgstr "" #. Type: multiselect #. Description #: ../config.templates:4 msgid "" "Please select, among the whole system user list, users who should get a " "#BLENDNAME# user menu." msgstr "" #. Type: select #. Choices #: ../config.templates:10 msgid "Each package installation, End of installation, Never" msgstr "" #. Type: select #. Description #: ../config.templates:12 msgid "Build user menus at:" msgstr "" #. Type: select #. Description #: ../config.templates:12 msgid "" "The metapackages of the #BLENDNAME# Debian Pure Blend contain extra " "role based menus for users. These will be built when a user who is " "registered to a given role uses the \"update-menus\" utility. This can be " "done automatically for all users who are registered for #BLENDNAME# after " "installation of each single metapackage, at the end of the whole " "installation process to save time in case of installing more than one meta " "package or just leave the call of \"update-menus\" to the users themselves.\n" " * Each package installation : Call \"update-menus\" after each meta " "package\n" " (time consuming);\n" " * End of installation : Call \"update-menus\" only once at the end " "of\n" " the whole installation/upgrading process;\n" " * Never : Do not call \"update-menus\" at all." msgstr "" blends-0.6.16.4ubuntu2/templates/po/fr.po0000644000000000000000000000761212147323454015026 0ustar # translation of fr.po to French # # Translators, if you are not familiar with the PO format, gettext # documentation is worth reading, especially sections dedicated to # this format, e.g. by running: # info -n '(gettext)PO Files' # info -n '(gettext)Header Entry' # # Some information specific to po-debconf are available at # /usr/share/doc/po-debconf/README-trans # or http://www.debian.org/intl/l10n/po-debconf/README-trans # # Developers do not need to manually edit POT or PO files. # Christian Perrier , 2004. # msgid "" msgstr "" "Project-Id-Version: #BLEND#-config\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2004-06-28 15:58+0200\n" "PO-Revision-Date: 2004-06-29 08:04+0200\n" "Last-Translator: Eric Madesclair \n" "Language-Team: French \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "X-Generator: KBabel 1.3.1\n" "Plural-Forms: Plural-Forms: nplurals=2; plural=n>1;\n" #. Type: multiselect #. Description #: ../config.templates:4 msgid "#BLENDNAME# users:" msgstr "Utilisateurs de #BLENDNAME# :" #. Type: multiselect #. Description #: ../config.templates:4 msgid "" "Please select, among the whole system user list, users who should get a " "#BLENDNAME# user menu." msgstr "" "Veuillez choisir parmi tous les utilisateurs du système ceux qui auront un " "menu #BLENDNAME#." #. Type: select #. Choices #: ../config.templates:10 msgid "Each package installation, End of installation, Never" msgstr "À chaque installation de paquet, À la fin de l'installation, Jamais" #. Type: select #. Description #: ../config.templates:12 msgid "Build user menus at:" msgstr "Construction des menus des utilisateurs :" #. Type: select #. Description #: ../config.templates:12 msgid "" "The metapackages of the #BLENDNAME# Debian Pure Blend contain extra " "role based menus for users. These will be built when a user who is " "registered to a given role uses the \"update-menus\" utility. This can be " "done automatically for all users who are registered for #BLENDNAME# after " "installation of each single metapackage, at the end of the whole " "installation process to save time in case of installing more than one meta " "package or just leave the call of \"update-menus\" to the users themselves.\n" " * Each package installation : Call \"update-menus\" after each meta " "package\n" " (time consuming);\n" " * End of installation : Call \"update-menus\" only once at the end " "of\n" " the whole installation/upgrading process;\n" " * Never : Do not call \"update-menus\" at all." msgstr "" "Les méta-paquets de la distribution Debian spécialisée #BLENDNAME# comportent " "des menus additionnels suivant le rôle attribué aux utilisateurs. Ces menus " "sont construits quand un utilisateur enregistré dans un rôle donné lancera " "la commande « update-menus ». Cette opération peut se faire automatiquement " "après l'installation de chaque méta-paquet pour chaque utilisateur " "enregistré pour #BLENDNAME# ou à la fin du processus d'installation pour " "gagner du temps si plu sd'un méta-paquet est installé. Il est également " "possible de laisser aux utilisateurs l'initiative de lancer eux-même la " "commande.\n" " - À chaque installation de paquet : lancer « update-menus » après\n" " l'installation de chaque méta-paquet\n" " (cette opération peut être longue) ;\n" " - À la fin de l'installation  : lancer « update-menus » seulement\n" " à la fin de la procédure\n" " d'installation ou de mise à jour ;\n" " - Jamais  : ne pas du tout lancer « update-menus »." blends-0.6.16.4ubuntu2/templates/po/POTFILES.in0000644000000000000000000000005312147323454015624 0ustar [type: gettext/rfc822deb] config.templates blends-0.6.16.4ubuntu2/templates/po/de.po0000644000000000000000000000657012147323454015011 0ustar # # Translators, if you are not familiar with the PO format, gettext # documentation is worth reading, especially sections dedicated to # this format, e.g. by running: # info -n '(gettext)PO Files' # info -n '(gettext)Header Entry' # # Some information specific to po-debconf are available at # /usr/share/doc/po-debconf/README-trans # or http://www.debian.org/intl/l10n/po-debconf/README-trans # # Developers do not need to manually edit POT or PO files. # msgid "" msgstr "" "Project-Id-Version: #BLEND#-config\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2004-06-28 15:58+0200\n" "PO-Revision-Date: 2008-10-26 07:42+0100\n" "Last-Translator: Andreas Tille \n" "Language-Team: German \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. Type: multiselect #. Description #: ../config.templates:4 msgid "#BLENDNAME# users:" msgstr "#BLENDNAME# Nutzer:" #. Type: multiselect #. Description #: ../config.templates:4 msgid "" "Please select, among the whole system user list, users who should get a " "#BLENDNAME# user menu." msgstr "" "Bitte wählen Sie aus der Liste aller Nutzer des Systems diejenigen aus, die " "ein #BLENDNAME# Nutzermenü erhalten sollen." #. Type: select #. Choices #: ../config.templates:10 msgid "Each package installation, End of installation, Never" msgstr "Paketinstallation, Installationsende, Nie" #. Type: select #. Description #: ../config.templates:12 msgid "Build user menus at:" msgstr "Erzeugen der Nutzermenüs bei:" #. Type: select #. Description #: ../config.templates:12 msgid "" "The metapackages of the #BLENDNAME# Debian Pure Blend contain extra " "role based menus for users. These will be built when a user who is " "registered to a given role uses the \"update-menus\" utility. This can be " "done automatically for all users who are registered for #BLENDNAME# after " "installation of each single metapackage, at the end of the whole " "installation process to save time in case of installing more than one meta " "package or just leave the call of \"update-menus\" to the users themselves.\n" " * Each package installation : Call \"update-menus\" after each meta " "package\n" " (time consuming);\n" " * End of installation : Call \"update-menus\" only once at the end " "of\n" " the whole installation/upgrading process;\n" " * Never : Do not call \"update-menus\" at all." msgstr "" "Die Metapakete der Debian Pure Blend #BLENDNAME# enthalten Rollen " "basierte Nutzermenüs. Diese werden erzeugt, wenn ein Nutzer, der für eine " "bestimmte Rolle registriert ist, das Programm \"update-menus\" aufruft. Das " "kann automatisch für alle für #BLENDNAME# registrierten Nutzer geschehen und " "zwar nach der Installation jedes einzelnen Metapaketes oder zeitsparend am " "Ende des Installationsprozesses mehrerer Metapakete. Alternativ kann " "\"update-menus\" auch manuell durch jeden Nutzer aufgerufen werden.\n" " * Paketinstallation : \"update-menus\" nach jeder Metapaketinstallation\n" " aufrufen (zeitintensiv).\n" " * Installationsende : \"update-menus\" einmalig am Ende des\n" " Installations- oder Updateprozesses aufrufen.\n" " * Nie : \"update-menus\" nicht aufrufen.\n" blends-0.6.16.4ubuntu2/templates/po/pt_BR.po0000644000000000000000000000711012147323454015416 0ustar # # Translators, if you are not familiar with the PO format, gettext # documentation is worth reading, especially sections dedicated to # this format, e.g. by running: # info -n '(gettext)PO Files' # info -n '(gettext)Header Entry' # # Some information specific to po-debconf are available at # /usr/share/doc/po-debconf/README-trans # or http://www.debian.org/intl/l10n/po-debconf/README-trans # # Developers do not need to manually edit POT or PO files. # msgid "" msgstr "" "Project-Id-Version: blends-dev\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2004-06-28 15:58+0200\n" "PO-Revision-Date: 2004-06-29 22:00-0300\n" "Last-Translator: André Luís Lopes \n" "Language-Team: Debian-BR Project \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. Type: multiselect #. Description #: ../config.templates:4 msgid "#BLENDNAME# users:" msgstr "Usuários #BLENDNAME# : " #. Type: multiselect #. Description #: ../config.templates:4 msgid "" "Please select, among the whole system user list, users who should get a " "#BLENDNAME# user menu." msgstr "" "Por favor, selecione dentre a lista de usuários de todo o sistema os " "usuários que devem obter um menu de usuário do #BLENDNAME#." #. Type: select #. Choices #: ../config.templates:10 msgid "Each package installation, End of installation, Never" msgstr "A cada instalação de pacote, Ao final da instalação, Nunca" #. Type: select #. Description #: ../config.templates:12 msgid "Build user menus at:" msgstr "Construir menus de usuários :" #. Type: select #. Description #: ../config.templates:12 msgid "" "The metapackages of the #BLENDNAME# Debian Pure Blend contain extra " "role based menus for users. These will be built when a user who is " "registered to a given role uses the \"update-menus\" utility. This can be " "done automatically for all users who are registered for #BLENDNAME# after " "installation of each single metapackage, at the end of the whole " "installation process to save time in case of installing more than one meta " "package or just leave the call of \"update-menus\" to the users themselves.\n" " * Each package installation : Call \"update-menus\" after each meta " "package\n" " (time consuming);\n" " * End of installation : Call \"update-menus\" only once at the end " "of\n" " the whole installation/upgrading process;\n" " * Never : Do not call \"update-menus\" at all." msgstr "" "Os meta-pacotes da Debian Pure Blend #BLENDNAME# contém " "menus extras para usuários com base em suas funções. Tais menus serão " "gerados quando um usuário registrado para uma função específica utilizar " "o utilitário \"update-menus\". Isso pode ser feito automaticamente para " "todos os usuários que estejam registrados para o #BLENDNAME# após a " "instalação de cada meta-pacote, ao final de todo o processo de instalação " "para economizar tempo no caso da instalação de mais de um meta-pacote ou " "deixar a execução do utilitário \"update-menus\" por conta dos prórios" "usuários.\n" " * A cada instalação de pacote : Executa \"update-menus\" após cada meta " "pacote\n" " (consome muito tempo);\n" " * Ao final da instalação : Executa \"update-menus\" uma única vez " "no final\n" " do processo completo de instalação/atualização;\n" " * Nunca : Não executa \"update-menus\"." blends-0.6.16.4ubuntu2/templates/po/ca.po0000644000000000000000000000716012147323454015000 0ustar # # Translators, if you are not familiar with the PO format, gettext # documentation is worth reading, especially sections dedicated to # this format, e.g. by running: # info -n '(gettext)PO Files' # info -n '(gettext)Header Entry' # # Some information specific to po-debconf are available at # /usr/share/doc/po-debconf/README-trans # or http://www.debian.org/intl/l10n/po-debconf/README-trans # # Developers do not need to manually edit POT or PO files. # msgid "" msgstr "" "Project-Id-Version: blends 0.4\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2004-06-28 15:58+0200\n" "PO-Revision-Date: 2004-09-07 20:59+0200\n" "Last-Translator: Guillem Jover \n" "Language-Team: Catalan \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. Type: multiselect #. Description #: ../config.templates:4 msgid "#BLENDNAME# users:" msgstr "Usuaris de #BLENDNAME#:" #. Type: multiselect #. Description #: ../config.templates:4 msgid "" "Please select, among the whole system user list, users who should get a " "#BLENDNAME# user menu." msgstr "" "Si us plau seleccioneu, de la llista de tots els usuaris del sistema, " "aquells usuaris que han d'obtenir un menú d'usuari de #BLENDNAME#." #. Type: select #. Choices #: ../config.templates:10 msgid "Each package installation, End of installation, Never" msgstr "En cada instal·lació d'un paquet, Al final de la instal·lació, Mai" #. Type: select #. Description #: ../config.templates:12 msgid "Build user menus at:" msgstr "Construir els menús d'usuari a:" #. Type: select #. Description #: ../config.templates:12 msgid "" "The meta packages of the #BLENDNAME# Debian Pure Blend contain extra " "role based menus for users. These will be built when a user who is " "registered to a given role uses the \"update-menus\" utility. This can be " "done automatically for all users who are registered for #BLENDNAME# after " "installation of each single meta package, at the end of the whole " "installation process to save time in case of installing more than one meta " "package or just leave the call of \"update-menus\" to the users themselves.\n" " * Each package installation : Call \"update-menus\" after each meta " "package\n" " (time consuming);\n" " * End of installation : Call \"update-menus\" only once at the end " "of\n" " the whole installation/upgrading process;\n" " * Never : Do not call \"update-menus\" at all." msgstr "" "Els meta paquets de la distribució de Debian adaptada #BLENDNAME# contenen " "menús extra basats en rols per als usuaris. Aquests seran construïts quan " "un usuari que estigui registrat en algun dels rols faci servir la utilitat " "«update-menus». Això es pot fer automàticament per a tots els usuaris que " "estiguin registrats per #BLENDNAME# després de la instal·lació de cada meta " "paquet, al final de tot el procés d'instal·lació per a estalviar temps en " "cas d'instal·lar més d'un meta paquet o senzillament deixar l'execució de " "«update-menus» als propis usuaris.\n" " * En cada instal·lació d'un paquet: Executar «update-menus» després de cada\n" " meta paquet (consumeix molt de temps);\n" " * Al final d'instal·lació : Executar «update-menus» només al final\n" " de tota la instal·lació o procés\n" " d'actualització;\n" " * Mai : No executar mai «update-menus»." blends-0.6.16.4ubuntu2/templates/apt.conf0000644000000000000000000000041612147323454015067 0ustar /* * APT configuration file for #BLEND#-config package */ DPkg { Post-Invoke {"test -f /var/run/#BLEND#-config.usermenu && if [ -x /usr/sbin/blend-update-usermenus ] ; then /usr/sbin/blend-update-usermenus #BLEND# ; fi ; rm -f /var/run/#BLEND#-config.usermenu";}; } blends-0.6.16.4ubuntu2/templates/config.install0000644000000000000000000000005512147323454016270 0ustar debian/90#BLEND#-config etc/apt/apt.conf.d blends-0.6.16.4ubuntu2/templates/README.Debian0000644000000000000000000000166212147323454015501 0ustar This is a metapackage which is used by Debian Pure Blends --------------------------------------------------------- This package is a metapackage; it depends on several other packages to make them be installed when it is installed. If you want to remove one of those packages, you have to remove this package as well. The other packages won't be touched. There exists an comprehensive documentation about Debian Pure Blends which can be found at http://blends.alioth.debian.org/blends/. The metapackages should always be installable on a Debian system. Thus no dependency on a non-available package (ie. a package available outside of Debian) have been used. However such dependencies have been downgraded to Suggests. Sometimes some non-free packages are suggested when no good free alternatives are known. You're encouraged to find good free replacements. Perhaps type-handling might gives us a way to specify arch-dependant dependencies. blends-0.6.16.4ubuntu2/templates/prerm0000755000000000000000000000341212147323454014506 0ustar #!/bin/sh set -e # This is the default prerm file from the blends-dev package which is used # in all meta packages. If there is a certain need to provide extra # prerm files for some meta packages this template will be appended. Thus # it will be checked whether debconf was just initialized. # # You should not insert the _DEBHELPER_ template in the special postscript # file because it is in the end of this template anyway. ########################################################################### # If the user menus are not needed/wished for a Blend (like for instance # Debian Edu there is no need to install blends-common package. Thus we # have to make sure that postinst does not try to include the menu stuff if [ -d /etc/blends -a -f /etc/blends/blends.conf ] ; then # Also verify that this Blend provides special configuration # If not there is no need to execute the user menu code if [ -d /etc/blends/#BLEND# -a -s /etc/blends/#BLEND#/#BLEND#.conf -a -s /etc/blends/blends.conf ] ; then if [ -x /usr/sbin/blend-update-usermenus ] ; then . /etc/blends/blends.conf . /etc/blends/#BLEND#/#BLEND#.conf blend-update-menus --blend #BLEND# # Initialize debconf if not yet done if [ _"$DEBCONF_REDIR" = _"" ]; then . /usr/share/debconf/confmodule db_version 2.0 fi case "$1" in deconfigure|failed-upgrade|upgrade) ;; remove|purge) db_get "shared/#BLEND#-config/usermenus" || true case "$RET" in "Each package installation") blend-update-usermenus #BLEND# ;; "End of installation") touch /var/run/#BLEND#-config.usermenu ;; esac ;; *) echo "prerm called with unknown argument \`$1'" >&2 exit 1 ;; esac fi fi fi #DEBHELPER# exit 0 blends-0.6.16.4ubuntu2/templates/config.templates0000644000000000000000000000332212147323454016620 0ustar Template: #BLEND#-config/group Type: multiselect Choices: ${users} _Description: #BLENDNAME# users: Please select, among the whole system user list, users who should get a #BLENDNAME# user menu. Template: shared/#BLEND#-config/usermenus Type: select _Choices: Each package installation, End of installation, Never Default: never _Description: Build user menus at: The metapackages of the #BLENDNAME# Debian Pure Blend contain extra menus that will be auto generated from existing packages. If the role based user menu option was choosen these menus will be built when a user who is registered to a given role uses the "update-menus" utility. This can be done automatically for all users who are registered for #BLENDNAME# after installation of each single metapackage, at the end of the whole installation process to save time in case of installing more than one metapackage or just leave the call of "update-menus" to the users themselves. * Each package installation : Call "update-menus" after each metapackage (time consuming); * End of installation : Call "update-menus" only once at the end of the whole installation/upgrading process; * Never : Do not call "update-menus" at all. Template: shared/#BLEND#-config/useusermenus Type: boolean _Description: Do you want user menus? The menus for the #BLENDNAME# Debian Pure Blend could be implemented as user menus which means they are visible only for those users that will be selected explicitely. Be warned that selecting the users from a large list does not scale very well so it makes no real sense to activate this feature if there are more than 50 users on this machine. blends-0.6.16.4ubuntu2/templates/config.postinst0000755000000000000000000000262512147323454016515 0ustar #!/bin/sh -e # if blends-common package is not yet installed we have to stop here if [ ! -f /etc/blends/blends.conf ] ; then echo "Debian Pure Blends configuration file /etc/blends/blends.conf is missing." exit -1 fi . /etc/blends/blends.conf if [ ! -f /etc/blends/#BLEND#/#BLEND#.conf ] ; then echo "#BLENDNAME# configuration file /etc/blends/#BLEND#/#BLEND#.conf is missing." exit -1 fi . /etc/blends/#BLEND#/#BLEND#.conf # Source debconf library. . /usr/share/debconf/confmodule db_version 2.0 # If $USEUSERMENU is not set in /etc/blends/#BLEND#/#BLEND#.conf read it from debconf database if [ -z $USEUSERMENU ] ; then db_get shared/#BLEND#-config/useusermenus if [ $RET ] ; then USEUSERMENU="yes" fi fi if [ "$USEUSERMENU" = "yes" ] ; then db_get #BLEND#-config/group CURRENTBLENDUSERS=`getUsersInRole #BLEND# #BLEND# 1` # Add those users which were selected but are not yet in the group for user in `echo "$RET" | sed "s/([^)]*)//g" | sed "s/ //g" | tr ',' '\n'` ; do if [ `echo "${CURRENTBLENDUSERS}" | grep -c -w "$user"` -eq 0 ] ; then blend-user add #BLEND# $user fi done # Del those users which were obviousely removed from list of Blend users for user in `getAllUsers 1` ; do if [ `echo "$RET" | grep -c -w "$user"` -eq 0 ] && [ `getent group #BLEND# | grep -c -w $user` -gt 0 ] ; then blend-user del #BLEND# $user fi done fi #DEBHELPER# blends-0.6.16.4ubuntu2/templates/config.links0000644000000000000000000000010612147323454015737 0ustar usr/share/blends/blend-task-lister usr/lib/tasksel/#BLEND#-task-files blends-0.6.16.4ubuntu2/templates/config.config0000755000000000000000000000276012147323454016077 0ustar #!/bin/sh -e # Initialize debconf if not yet done if [ _"$DEBCONF_REDIR" = _"" ]; then . /usr/share/debconf/confmodule db_version 2.0 db_capb backup fi db_input "medium" "shared/#BLEND#-config/useusermenus" || true db_go db_get shared/#BLEND#-config/useusermenus if [ $RET ] ; then db_input "medium" "shared/#BLEND#-config/usermenus" || true db_go fi # if blends.config package is not yet installed we have to stop here if [ ! -f /etc/blends/blends.conf ] ; then db_stop exit 0 fi [ -s /etc/blends/blends.conf ] && . /etc/blends/blends.conf [ -s /etc/blends/#BLEND#/#BLEND#.conf ] && . /etc/blends/#BLEND#/#BLEND#.conf # Add at least one default role for each Blend addRole #BLEND# #BLEND# # Login names of all users of the system as comma separated list USERS=`getAllUsers 0 ,` # "login (Real Name)" of users registered to the Debian Pure Blend #BLEND# BLENDUSERS=`getUsersInRole #BLEND# #BLEND# 0 ,` db_set #BLEND#-config/group "$BLENDUSERS" db_subst #BLEND#-config/group users "$USERS" db_get #BLEND#-config/group db_input high #BLEND#-config/group || true db_go db_stop if [ -d /etc/blends/#BLEND#/ ] ; then if [ ! -f /etc/blends/#BLEND#/#BLEND#.conf ] ; then # Due to a bug in blends-common the real Blend config file was moved to #BLEND#.conf~. This is fixed here if [ -f /etc/blends/#BLEND#/#BLEND#.conf~ ] ; then cp -a /etc/blends/#BLEND#/#BLEND#.conf~ /etc/blends/#BLEND#/#BLEND#.conf fi fi fi exit 0 blends-0.6.16.4ubuntu2/templates/postinst0000755000000000000000000000456012147323454015251 0ustar #!/bin/sh set -e # This is the default postinst file from the blends-dev package which is used # in all meta packages. If there is a certain need to provide extra # postinst files for some meta packages this template will be appended. Thus # it will be checked whether debconf was just initialized. # # You should not insert the _DEBHELPER_ template in the special postscript # file because it is in the end of this template anyway. # summary of how this script can be called: # * `configure' # * `abort-upgrade' # * `abort-remove' `in-favour' # # * `abort-remove' # * `abort-deconfigure' `in-favour' # `removing' # # for details, see http://www.debian.org/doc/debian-policy/ or # the debian-policy package ########################################################################### # If the user menus are not needed/wished for a Blend (like for instance # Debian Edu there is no need to install blends-common package. Thus we # have to make sure that postinst does not try to include the menu stuff if [ -d /etc/blends -a -f /etc/blends/blends.conf ] ; then # Also verify that this Blend provides special configuration # If not there is no need to execute the user menu code if [ -d /etc/blends/#BLEND# -a -f /etc/blends/#BLEND#/#BLEND#.conf ] ; then test -x /usr/sbin/blend-update-menus && blend-update-menus --blend #BLEND# # Initialize debconf if not yet done if [ _"$DEBCONF_REDIR" = _"" ]; then . /usr/share/debconf/confmodule db_version 2.0 fi . /etc/blends/blends.conf if [ -s /etc/blends/#BLEND#/#BLEND#.conf ] ; then . /etc/blends/#BLEND#/#BLEND#.conf ; fi case "$1" in abort-deconfigure|abort-remove|abort-upgrade) ;; configure|upgrade) db_get "shared/#BLEND#-config/usermenus" || true case "$RET" in "Each package installation") blend-update-usermenus #BLEND# ;; "End of installation") touch /var/run/#BLEND#-config.usermenu ;; esac ;; *) echo "postinst called with unknown argument \`$1'" >&2 exit 1 ;; esac db_stop fi fi #DEBHELPER# exit 0 blends-0.6.16.4ubuntu2/sources.list.oneiric0000644000000000000000000000007412147323454015445 0ustar deb http://archive.ubuntu.com/ubuntu/ oneiric main universe blends-0.6.16.4ubuntu2/TODO0000644000000000000000000000052512147323454012127 0ustar sources.list It would be a good idea to parse /etc/apt/sources.list for the Debian-Mirror which is used on the building box instead of using ftp.debian.org blend-gen-control should handle versioned dependencies blend-install-helper This script is currently more or less a hack. It might be reasonable to modularize this script. blends-0.6.16.4ubuntu2/sources.list.testing0000644000000000000000000000005612147323454015472 0ustar deb http://ftp.debian.org/debian testing main blends-0.6.16.4ubuntu2/blend-update-menus.80000644000000000000000000000176112147323454015224 0ustar .TH blend\-update\-menus 8 "2008/11/02" "" "Debian Pure Blends" .SH NAME .B blend\-update\-menus \- add menu of meta package to all Debian Pure Blend users .SH SYNOPSIS .B blend\-update\-menus [ \-\-blend|\-b < .B Blend > | \-\-user|\-u < .B user > ] .SH DESCRIPTION blend\-update\-menus behaves differently depending on who run the command: If it's called by a user, it adds and keeps updated menu entries for the user who runs it. If it's called by root, it adds and keeps updated user's menu entries (see menu package for users' menus) for all users who belong to the group of the specified Debian Pure Blend, or only for a specified user, depending on which parameter is passed to the script. .SH OPTIONS .TP .B Blend one of the installed Blends, listed in /etc/blends/, for example (if installed): .I edu , .I gis , .I junior , .I med or .I science .TP .B user a user present on the system and belonging to a Blend .SH AUTHOR Andreas Tille , Cosimo Alfarano blends-0.6.16.4ubuntu2/COPYING0000644000000000000000000004311012147323454012467 0ustar GNU GENERAL PUBLIC LICENSE Version 2, June 1991 Copyright (C) 1989, 1991 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too. When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things. To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it. For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software. Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations. Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all. The precise terms and conditions for copying, distribution and modification follow. GNU GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you". Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does. 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code. 4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it. 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. 7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation. 10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Programs If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms. To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Also add information on how to contact you by electronic and paper mail. If the program is interactive, make it output a short notice like this when it starts in an interactive mode: Gnomovision version 69, Copyright (C) year name of author Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details. The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu items--whatever suits your program. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the program, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the program `Gnomovision' (which makes passes at compilers) written by James Hacker. , 1 April 1989 Ty Coon, President of Vice This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License. blends-0.6.16.4ubuntu2/AUTHORS0000644000000000000000000000020512147323454012502 0ustar Authors: Andreas Tille Petter Reinholdtsen Cosimo Alfarano blends-0.6.16.4ubuntu2/sources.list.precise0000644000000000000000000000007412147323454015447 0ustar deb http://archive.ubuntu.com/ubuntu/ precise main universe blends-0.6.16.4ubuntu2/examples/0000755000000000000000000000000012147323735013255 5ustar blends-0.6.16.4ubuntu2/examples/README0000644000000000000000000000034512147323454014135 0ustar This is an example directory layout for building metapackages for a Debian Pure Blend with the name Debian-_BLEND_. So search for the string _BLEND_ and replacing it with a real name would provide a basic skeleton to work with. blends-0.6.16.4ubuntu2/examples/menu/0000755000000000000000000000000012147323735014221 5ustar blends-0.6.16.4ubuntu2/examples/menu/README0000644000000000000000000000240012147323454015073 0ustar If this directory exists, menu entries for the single metapackages can be provided here. The files should have the same name as the files in the tasks directory and ideally each single task should have its own menu. See for instance Debian Med packages. In general a metapackage should provide a menu for every dependent package. This menu entry should either point to a package executable (perhaps with some special hints assigned) or to a pager call which provides some extra information how the special package can be used. For instance this can be done via text files /usr/share/doc/_BLEND_task1/deppkg1.txt (see Debian Med). The idea is to provide a special _BLEND_ menu with the relevant parts for the users of the _BLEND_. At install time the existing dependencies are checked for their menu entries. These are taken over into the user menu. If the metapackage maintainer wants to override this entry he is able to provide menu//.menu files. If there is no reasonable menu entry for a package extra documentation can be provided which can be viewed via menu entries. This can either be given as plain text files menu//.txt or HTML files menu//.html. The created menu entry calls sensible-pager or sensible-browser, respectively. blends-0.6.16.4ubuntu2/examples/menu/task1/0000755000000000000000000000000012147323735015244 5ustar blends-0.6.16.4ubuntu2/examples/menu/task1/README0000644000000000000000000000136512147323454016127 0ustar Here you can place overrides for the package maintainer menu entries in normal menu syntax as files .menu . Sometimes it is not possible to provide a useful menu entry for a package and thus we would fail to create a menu entry for a dependency inside a metapackage. This sucks in term of user support and thus it is strongly suggested to provide some information about each dependant package which has no reasonable menu entry. This can easily done by creating a text file with the name of the dependency, i.e. dep2.txt. Alternatively you can provide HTML formated description as dep3.html. These files should provide all information which is necessary to use this package, like man pages online documentation, usage examples, upstream URL, etc. blends-0.6.16.4ubuntu2/examples/menu/task1/dep2.txt0000644000000000000000000000061312147323454016635 0ustar dep2: Short description of package dep2 Some information about dep2 from the Debian-_BLEND_ project. long description of dep2 More infromation about the dep2 package can be obtained from the following manpages: dep2_a.1 dep2_b.1 ... You can use this package in the following way: ... More information about dep2 can be obtained from the home page at http://www.dep2.org/ blends-0.6.16.4ubuntu2/examples/menu/task1/dep3.html0000644000000000000000000000041012147323454016756 0ustar Description of dep3

dep3: Short description of package dep3

long description of dep3

For more detailed information see:

blends-0.6.16.4ubuntu2/examples/menu/task1/dep1.menu0000644000000000000000000000026212147323454016761 0ustar ?package(dep1): needs = "X11" \ section = "_BLEND_/Task1" \ title = "DepPkg1" \ command = "/usr/bin/deppkg1" \ hints = "Use of DepPkg1" blends-0.6.16.4ubuntu2/examples/debian/0000755000000000000000000000000012147323735014477 5ustar blends-0.6.16.4ubuntu2/examples/debian/control.stub0000644000000000000000000000045312147323466017061 0ustar Source: debian-_BLEND_ Section: misc Priority: extra Maintainer: _MAINTAINER_ <_maintainer_@debian.org> Uploaders: _OPTIONAL-FURTHER-MAINTAINER_ <_optional-further-maintainer_@debian.org> Build-Depends-Indep: debhelper (>= 9), blends-dev (>= 0.6.16.4) Standards-Version: 3.9.4 blends-0.6.16.4ubuntu2/examples/debian/README0000644000000000000000000000023512147323454015355 0ustar You always need this directory to build metapackages. Just change control.stub and replace the variables _BLEND_ and _MAINTAINER_ to the apropriate strings. blends-0.6.16.4ubuntu2/examples/debian/compat0000644000000000000000000000000212147323466015676 0ustar 9 blends-0.6.16.4ubuntu2/examples/debian/dis-task1.install0000644000000000000000000000021112147323454017657 0ustar ### this file is optional and only needed if the install directory is needed install/task1/extra-script-which-is-needed-in-task1 usr/bin blends-0.6.16.4ubuntu2/examples/debian/rules0000755000000000000000000000007012147323454015552 0ustar #!/usr/bin/make -f include /usr/share/blends-dev/rules blends-0.6.16.4ubuntu2/examples/debian/dis-task1.manpages0000644000000000000000000000020312147323454020005 0ustar ### this file is optional and only needed if the install directory is needed install/task1/extra-script-which-is-needed-in-task1.1 blends-0.6.16.4ubuntu2/examples/config/0000755000000000000000000000000012147323735014522 5ustar blends-0.6.16.4ubuntu2/examples/config/conf0000644000000000000000000000041412147323454015367 0ustar ## This is a configuration file for the Debian _BLEND_ Blend ## It is read after /etc/blends/blends.conf and can override or add variables ## Some Blends do not build their name generic like Debian #BLEND# so ## we need the correct name here BLENDNAME=Debian-_BLEND_ blends-0.6.16.4ubuntu2/examples/config/common.10000644000000000000000000000102312147323454016066 0ustar .TH _BLEND_-common 1 "October 24, 2008" "Debian-_BLEND_" .SH NAME .B _BLEND_-common .B _BLEND_- \- package information and auto-apt helper .SH SYNOPSIS .B _BLEND_-common .B _BLEND_- .SH DESCRIPTION Print just a simple information page about every _BLEND_-* package of the Debian _BLEND_ Blend. Each metapackage has a .I /usr/bin/_BLEND_- file which should print some usefull informations and could be serve as auto-apt helper. .SH AUTHOR Andreas Tille . blends-0.6.16.4ubuntu2/examples/config/README0000644000000000000000000000014412147323454015377 0ustar If this directory exists a _BLEND_-common package is created. See for instance Debian Med packages. blends-0.6.16.4ubuntu2/examples/config/common0000755000000000000000000000027212147323454015737 0ustar #!/bin/sh ## Prints some info about that package and lets auto-apt work dpkg --status `basename $0` | \ grep -v ^Priority | \ grep -v ^Section | \ grep -v ^Installed-Size blends-0.6.16.4ubuntu2/examples/config/control0000644000000000000000000000043212147323466016125 0ustar Package: _BLEND_-config Architecture: all Depends: adduser, ${misc:Depends}, menu, blends-common (>= 0.6) Description: Debian _BLEND_ Project config package This package builds the basic infra structure of all metapackages for the Debian _BLEND_ Blend. blends-0.6.16.4ubuntu2/examples/tasks/0000755000000000000000000000000012147323735014402 5ustar blends-0.6.16.4ubuntu2/examples/tasks/README0000644000000000000000000000032012147323454015253 0ustar This directory is mandatory. Each file had to follow a certain syntax to build a valid control file entry for the metapackage to build. For an extensive and working example see Debian Med packages >= 1.0 . blends-0.6.16.4ubuntu2/examples/tasks/task10000644000000000000000000000100212147323454015337 0ustar Task: task1 Description: Debian-_BLEND_ task1 packages This metapackage will install Debian packages for use in task1 of Debian-_BLEND_. Depends: dep-pkg1, dep-pkg2, ... Suggests: sug-pkg1, ... Depends: dep-pkg42 Why: You might provide some reasons here ... Responsible: Somebody who cares NeedConfig: no / yes via debconf Depends: _BLEND_-common Why: Optional reason for dependency of the _BLEND_-common package Responsible: Optional _BLEND_Maintainer NeedConfig: Optional yes via debconf blends-0.6.16.4ubuntu2/examples/Makefile0000755000000000000000000000052612147323454014721 0ustar #!/usr/bin/make -f BLENDMAKEFILE=/usr/share/blends-dev/Makefile CheckBlendMakefile := $(shell if [ -e $(BLENDMAKEFILE) ] ; then echo 1 ; else echo 0 ; fi) ifeq ($(CheckBlendMakefile),1) include $(BLENDMAKEFILE) else err := $(shell echo "$(BLENDMAKEFILE) is missing. Please install blends-dev package!") endif dummy: @echo $(err) blends-0.6.16.4ubuntu2/examples/install/0000755000000000000000000000000012147323735014723 5ustar blends-0.6.16.4ubuntu2/examples/install/README0000644000000000000000000000073212147323454015603 0ustar If some extra files like scripts of manpages are needed in the metapackages they should be placed into apropriate subdirectories of this directory. While there is no certain procedure in the blends-dev tools to handle files in this directory it might be a good idea to settle down with some default place for those extra files. To move them right into place the files debian/.install, debian/.manpages etc. should be used. See for instance Debian Med packages. blends-0.6.16.4ubuntu2/examples/install/task1/0000755000000000000000000000000012147323735015746 5ustar blends-0.6.16.4ubuntu2/examples/install/task1/extra-script-which-is-needed-in-task10000755000000000000000000000006012147323454024673 0ustar #!/bin/sh echo "Do something useful for task1." blends-0.6.16.4ubuntu2/examples/install/task1/extra-script-which-is-needed-in-task1.10000644000000000000000000000063612147323454025040 0ustar .TH extra-script-which-is-needed-in-task1 1 "" "#BLEND#" .SH NAME .B extra-script-which-is-needed-in-task1 \- some useful script for task1 .SH SYNOPSIS .B extra-script-which-is-needed-in-task1 .SH DESCRIPTION The task makes no sense without this script - or at least this script provides extra functionality which is not in any of the single dependencies. .SH AUTHOR Metapackage Autor . blends-0.6.16.4ubuntu2/debian/0000755000000000000000000000000012240415552012652 5ustar blends-0.6.16.4ubuntu2/debian/copyright0000644000000000000000000000153712147323454014620 0ustar Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Files: * Copyright: © 2003-2012 Andreas Tille License: GPL-2+ Files: devtools/blend-gen-control Copyright: © 2003-2007 Petter Reinholdtsen © 2007-2012 Andreas Tille License: GPL-2+ Files: share/blends/* Copyright: © 2003 Cosimo Alfarano © 2003-2012 Andreas Tille License: GPL-2+ License: GPL-2+ This package is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. . On Debian systems, the complete text of the GNU GPL version 2 can be found in: `/usr/share/common-licenses/GPL-2' blends-0.6.16.4ubuntu2/debian/blends-common.README.Debian0000644000000000000000000000141512147323454017455 0ustar Debian Pure Blends common files ------------------------------- This package builds the basic infra structure of all metapackages. You can add or remove users to the group of users of a Debian Pure Blends. This is used for instance by Debian Med. It provides a med-common package which calls the scripts from blends-common. It can be used by dpkg-reconfigure med-common Users of this group are provided by a user menu which will be build from menu files which are provided by each single med-* metapackage in /etc/med/menu. If you do not want to install the suggested blends-doc package you might read the online version at http://blends.alioth.debian.org/blends/ which is frequently updated. -- Andreas Tille Sun, 19 Oct 2008 15:23:01 +0200 blends-0.6.16.4ubuntu2/debian/compat0000644000000000000000000000000212147323466014060 0ustar 9 blends-0.6.16.4ubuntu2/debian/blends-common.docs0000644000000000000000000000001612147323454016263 0ustar README.BLENDS blends-0.6.16.4ubuntu2/debian/blends-doc.install0000644000000000000000000000007012147323454016256 0ustar doc/debian-blends.html/* usr/share/doc/blends-doc/html blends-0.6.16.4ubuntu2/debian/blends-common.install0000644000000000000000000000033612147323454017006 0ustar blend-user usr/sbin blend-role usr/sbin blend-update-menus usr/sbin blend-update-usermenus usr/sbin share usr etc/* etc blend-task-lister usr/share/blends blends-0.6.16.4ubuntu2/debian/blends-dev.docs0000644000000000000000000000000512147323454015547 0ustar BUGS blends-0.6.16.4ubuntu2/debian/blends-doc.doc-base0000644000000000000000000000153512147323454016274 0ustar Document: blends-doc Title: Debian Pure Blends Author: Andreas Tille Abstract: This paper is intended to people who are interested in the philosophy of Debian Pure Blends and the technique which is used to manage those projects. . It is explained in detail why these are no forks from Debian but reside completely inside the Debian GNU/Linux distribution and which advantages can be gathered by this approach. The concept of meta-packages and user role based menus is explained. In short: This document describes why Debian Pure Blends are important to the vitality and quality of Debian. Section: Debian Format: HTML Index: /usr/share/doc/blends-doc/html/index.html Files: /usr/share/doc/blends-doc/html/*.html Format: text Files: /usr/share/doc/blends-doc/debian-blends.en.txt.gz Format: pdf Files: /usr/share/doc/blends-doc/debian-blends.en.pdf blends-0.6.16.4ubuntu2/debian/source/0000755000000000000000000000000012147323735014161 5ustar blends-0.6.16.4ubuntu2/debian/source/format0000644000000000000000000000001512147323466015371 0ustar 3.0 (native) blends-0.6.16.4ubuntu2/debian/blends-dev.install0000644000000000000000000000015512147323454016273 0ustar sources.list* etc/blends templates usr/share/blends devtools/* usr/share/blends-dev blends-0.6.16.4ubuntu2/debian/blends-common.lintian-overrides0000644000000000000000000000133112147323454020772 0ustar # The script /usr/lib/menu/blends-menu is not intended to be called by the # blends-common package but should be called by meta packages according to # the Debian Pure Blends philosphy which is explained in blends-doc. # That's why neither postinst nor prerm will call update-menus and # if they would it would just be a useless call because it just exits 0 # if called by root. blends-common: postinst-does-not-call-updatemenus usr/share/menu/blend-menu blends-common: prerm-does-not-call-updatemenus usr/share/menu/blend-menu # For obvious reasons the script has to be executable which is the # intended use for scripts which dynamically create menu entries. blends-common: executable-menu-file usr/share/menu/blend-menu 0755 blends-0.6.16.4ubuntu2/debian/rules0000755000000000000000000000271512147323466013747 0ustar #!/usr/bin/make -f # debian/rules for blends # This file is public domain software, originally written by Andreas Tille. # Uncomment this to turn on verbose mode. #export DH_VERBOSE=1 pkg := $(shell dpkg-parsechangelog | sed -n 's/^Source: //p') VERSION := $(shell dpkg-parsechangelog -ldebian/changelog | grep Version: | cut -f2 -d' ' | cut -f1 -d- ) DISTDIR := $(pkg)-$(VERSION) %: dh $@ override_dh_auto_build: cd doc; $(MAKE) html; $(MAKE) txt; $(MAKE) pdf dh_auto_build override_dh_installchangelogs: for pkgnews in $(pkg)-common $(pkg)-dev ; do \ cp -a debian/$$pkgnews.NEWS.Debian debian/$$pkgnews/usr/share/doc/$$pkgnews/NEWS.Debian ; \ done dh_installchangelogs override_dh_auto_clean: cd doc; $(MAKE) clean dh_auto_clean override_dh_compress : dh_compress -X.pdf dist: get-orig-source get-orig-source: if [ ! -f debian/changelog ] ; then \ echo "File debian/changelog is missing. Something is wrong!" ; \ exit -1 ; \ fi if [ "$(VERSION)" = "" ] ; then \ echo "Unable to obtain version number from debian/changelog. Something is wrong!" ; \ exit -1 ; \ fi ; rm -rf $(DISTDIR) mkdir $(DISTDIR) chmod 777 $(DISTDIR) rsync -a --exclude $(DISTDIR) --exclude CVS --exclude .svn --exclude svn-commit.tmp * $(DISTDIR) ln -sf sources.list.unstable $(DISTDIR)/sources.list # ln -s control.stub $(DISTDIR)/examples/debian/control rm -f `find . -name "*~"` GZIP=-9 tar -czf ../$(pkg)_$(VERSION).tar.gz $(DISTDIR) rm -rf $(DISTDIR) blends-0.6.16.4ubuntu2/debian/blends-dev.manpages0000644000000000000000000000000412147323454016411 0ustar *.1 blends-0.6.16.4ubuntu2/debian/blends-dev.examples0000644000000000000000000000001312147323454016434 0ustar examples/* blends-0.6.16.4ubuntu2/debian/blends-common.NEWS.Debian0000644000000000000000000000555412147323454017304 0ustar blends (0.6.9) unstable; urgency=low * Do not try to take over config files from /etc/cdd - it just leads to trouble and is not worth the effort because they are unchanged in most practical cases --> Please check the files in /etc/cdd if existant and take over the changes manually if needed to /etc/blends -- Andreas Tille Mon, 11 Jan 2010 19:23:04 +0100 blends (0.6.6) unstable; urgency=low * Previous versions of blends-common tried to convert config files from CDDs in /etc/cdd/ installed on the system to the new location /etc/blends/ to enable a smooth migration. Unfortunately this is a violation of policy 10.7.3, see http://www.debian.org/doc/debian-policy/ch-files.html#s10.7.3, because it conflicts with the default config files in the config package of a Blend so this has to be dropped. It concerns only three Blends and the change is very minimal (if needed ever - you are probably doing better with the new default configuration file). For the sake of completenes the new blend configuration directory has a copy of the old configuration file with the extension *.cdd to make sure that nothing is lost. You should inspect this file and can safely remove it afterwards. -- Andreas Tille Fri, 21 Aug 2009 14:24:50 +0200 blends (0.6.0) unstable; urgency=low * The great renaming: The confusing name Custom Debian Distribution was dropped after DebConf 8 and replaced by Debian Pure Blends - in short blends if the Debian internal use is evident. This reflects in a rename of the package and all the tools. * This change results in a rename of the cdd-dev binary package to blends-dev and cdd-commons binary package to blends-common. To provide a reasonable migration path dummy packages cdd-dev and cdd-common are provided as well which contain symlinks to the tools in the respective blends package to make sure all projects are able to migrate their meta packages smoothly. * The projects affected are: - Debian Edu - Debian Junior - Debian Med - Debian Science -- Andreas Tille Sun, 19 Oct 2008 15:23:01 +0200 cdd (0.3.1) unstable; urgency=low * In cdd 0.3 user menus where implemented by placing a symlink cdd-menu in the .menu directory of each user who belongs to any Custom Debian Distrinution role. Now a solution was found which does not touch users .menu directory. To avoid code for removal of these old cdd-menu links in the users home directories in the future postinst scripts it seems to be the best solution to ask the local administrator do remove these links manually. So please remove all symlinks named /.menu/cdd-menu -- Andreas Tille Thu, 17 May 2004 17:42:38 +0200 blends-0.6.16.4ubuntu2/debian/blends-dev.NEWS.Debian0000644000000000000000000000067712147323454016573 0ustar blends (0.6.10) unstable; urgency=low * Do not try to take over config files of package cdd-dev from /etc/cdd to /etc/blends it just leads to trouble and is not worth the effort because they are unchanged in most practical cases --> Please check the files in /etc/cdd if existant and take over the changes manually if needed to /etc/blends -- Andreas Tille Wed, 27 Jan 2010 13:05:07 +0100 blends-0.6.16.4ubuntu2/debian/blends-common.dirs0000644000000000000000000000003412147323454016274 0ustar usr/share/lintian/overrides blends-0.6.16.4ubuntu2/debian/blends-doc.docs0000644000000000000000000000006212147323454015541 0ustar doc/debian-blends.en.pdf doc/debian-blends.en.txt blends-0.6.16.4ubuntu2/debian/blends-common.manpages0000644000000000000000000000000412147323454017123 0ustar *.8 blends-0.6.16.4ubuntu2/debian/changelog0000644000000000000000000006553612240415546014546 0ustar blends (0.6.16.4ubuntu2) trusty; urgency=low * Add sources.list.trusty. -- James Page Tue, 12 Nov 2013 12:13:21 +0000 blends (0.6.16.4ubuntu1) saucy; urgency=low * Merge from Debian unstable. Remaining changes: - Add sources.list.{karmic,lucid,maverick,natty,oneiric,precise,quantal, raring} so blends can be built for Ubuntu. * Add sources.list.saucy. -- Logan Rosen Thu, 23 May 2013 01:22:16 -0400 blends (0.6.16.4) unstable; urgency=low * devtools/blend-gen-control: Apply patch from Felipe Sateler (thanks Felipe!) to separate package dependencies with a newline Closes: #709057 -- Andreas Tille Tue, 21 May 2013 23:39:39 +0200 blends (0.6.16.3) unstable; urgency=low * devtools/rules: Better way to obtain version string * do not create preinst and postrm scripts any more because preinst is unneeded since Lenny and postrm was only introduced for completeness but never used Closes: #708820, #708879 * templates/{preinst,postrm}: Removed because unneeded * debian/control - Standards-Version: 3.9.4 (no changes needed) - Debhelper 9 (also d/compat) - Removed duplicated Section: devel - normalised format - blends-dev also required debhelper version 9 * debian/rules: - use dpkg-parsechangelog to obtain pkg name and version - use short dh syntax * debian/source/format: 3.0 (native) * debian/examples: also require debhelper 9 + latest blends-dev -- Andreas Tille Mon, 20 May 2013 10:10:53 +0200 blends (0.6.16.2ubuntu1) raring; urgency=low * Merge from Debian unstable. Remaining changes: - Add sources.list.{karmic,lucid,maverick,natty,oneiric,precise,quantal,raring} so blends can be built for Ubuntu. -- Vibhav Pant Sat, 15 Dec 2012 16:39:55 +0530 blends (0.6.16.2) unstable; urgency=low * Install tasksel desc file to new location since version 3.00 of tasksel (thanks to Petter Reinholdtsen for the patch) Closes: #694896 -- Andreas Tille Tue, 04 Dec 2012 11:00:45 +0100 blends (0.6.16.1ubuntu1) raring; urgency=low * Merge from Debian unstable. Remaining changes: - Add sources.list.{karmic,lucid,maverick,natty,oneiric,precise,quantal} so blends can be built for Ubuntu. * Add sources.list.raring. -- Logan Rosen Sun, 02 Dec 2012 15:23:54 -0500 blends (0.6.16.1) unstable; urgency=low * Revert bumping of debhelper and Standards-Version to match the status of 0.6.15 and thus comply with freeze policy * The fix to the sources.list* files to add the missing debian/ dirs is now documented in BTS and this changelog entry Closes: #693864 -- Andreas Tille Wed, 21 Nov 2012 08:51:11 +0100 blends (0.6.16) unstable; urgency=low * Enhanced doc * sources.list/*: Add the missing debian/ dirs * debian/control: - Standards-Version: 3.9.3 - Vcs-Fields now point to Git * Debhelper 9 (control+compat) * Drop transitional cdd-* packages completely Closes: #692946 * DEP5 formated copyright while checking this in connection to bug #692946 -- Andreas Tille Fri, 16 Nov 2012 14:31:49 +0100 blends (0.6.15ubuntu3) quantal; urgency=low * Add sources.list.quantal -- Michael Terry Tue, 03 Jul 2012 00:01:04 -0400 blends (0.6.15ubuntu2) precise; urgency=low * Added sources.list.{oneiric,precise} so that blends can be built on all Ubuntu releases. -- James Page Mon, 05 Dec 2011 11:33:12 +0000 blends (0.6.15ubuntu1) natty; urgency=low * Merge from Debian unstable (LP: #674428). Remaining changes: - Add sources.list.{karmic,lucid,maverick} so blends ban be built for Ubuntu. * Add sources.list.natty so blends can be built for Ubuntu -- Angel Abad Sun, 14 Nov 2010 14:28:09 +0100 blends (0.6.15) unstable; urgency=low * Documentation changes: - doc/en: Update about existing Blends - examples/control.stub: + Updated debhelper version, Standards-Version + Removed two useless lines at the end * devtools/rules: ignore .git directories when creating orig.tar.gz * templates/{postinst,prerm}: use /bin/sh instead of /bin/bash to be sure that the requested shell is really available (there is no explicite bash dependency enforced * templates/postrm: Provide code for failed-upgrade to enable smooth upgrades from Lenny * templates/preinst: Provide this template for completeness * devtools/{rules,Makefile}: clean targets will remove also postrm and preinst if existant -- Andreas Tille Wed, 10 Nov 2010 20:32:31 +0100 blends (0.6.14ubuntu1) maverick; urgency=low * Merge from Debian unstable (LP: #613318). Remaining changes: - Add sources.list.{karmic,lucid,maverick} so blends ban be built for Ubuntu. -- Bhavani Shankar Wed, 04 Aug 2010 11:41:01 +0530 blends (0.6.14) unstable; urgency=low * doc/en: Updated documentation about webtools * devtools/rules: Disable dh_auto_build which tries to regenerate debian/control but should not * Standards-Version: 3.9.1 (no changes needed) -- Andreas Tille Tue, 03 Aug 2010 10:03:45 +0200 blends (0.6.13ubuntu1) maverick; urgency=low * Merge from Debian unstable. Remaining changes: - Add sources.list.karmic and sources.list.lucid so blends ban be built for Ubuntu 9.10 and 10.04. * Added sources.list.maverick -- Fabrice Coutadeur Tue, 18 May 2010 19:30:16 +0000 blends (0.6.13) unstable; urgency=low * Do not use explicite PATH to blend-update-menus to avoid lintian warning in metapackages. -- Andreas Tille Sat, 20 Mar 2010 22:38:55 +0100 blends (0.6.12) unstable; urgency=low * Use prerm instead of postrm and verify existance of blends-common in this file to deal with problems like #574237, #574203, #574208 -- Andreas Tille Wed, 17 Mar 2010 08:06:31 +0100 blends (0.6.11) unstable; urgency=low * Install NEWS.Debian files properly * Standards-Version: 3.8.4 (no changes needed) * Build-Depends: ghostscript (Thanks for the patch to Leo Iannacone ) Closes: #569802 -- Andreas Tille Mon, 15 Feb 2010 08:40:54 +0100 blends (0.6.10ubuntu1) lucid; urgency=low * Merge with Debian (LP: #521455). Remaining changes: - Add sources.list.karmic and sources.list.lucid so blends ban be built for Ubuntu 9.10 and 10.04. * debian/control: Add ghostscript as build dependency to fix "ERROR: thumbnail images could not be generated properly" error. -- Leo Iannacone Sat, 13 Feb 2010 19:22:03 +0100 blends (0.6.10) unstable; urgency=low * rm debian/blends-dev.preinst = do not try to take over config files from cdd-dev to blends-dev and warn in NEWS.Debian about this Closes: #562854 -- Andreas Tille Wed, 27 Jan 2010 13:05:07 +0100 blends (0.6.9) unstable; urgency=low * Do not try to take over config files from /etc/cdd - it just leads to trouble and is not worth the effort because they are unchanged in most practical cases -> Remove debian/blends-common.preinst * Updated debian/blends-common.README.Debian * debian/control: Added ${misc:Depends} to all package dependencies -- Andreas Tille Mon, 11 Jan 2010 19:23:04 +0100 blends (0.6.8ubuntu1) lucid; urgency=low * Merge from Debian Testing. Remaining changes: - Add sources.list.karmic and sources.list.lucid so blends ban be built for Ubuntu 9.10 and 10.04 -- Scott Kitterman Tue, 22 Dec 2009 00:30:56 -0500 blends (0.6.8) unstable; urgency=low * templates/config.postinst: Really fix the problem of missing config files which has leaded to #550140 and #553632 * debian/blends-common.preinst: Do config file moving only if it was not yet done -- Andreas Tille Mon, 09 Nov 2009 11:59:52 +0100 blends (0.6.7ubuntu1) lucid; urgency=low * Merge from debian testing. Remaining changes: - Add sources.list.karmic and sources.list.lucid so blends ban be built for Ubuntu 9.10 and 10.04 -- Scott Kitterman Sun, 29 Nov 2009 00:27:25 -0500 blends (0.6.7) unstable; urgency=low * Better documentation how to generate tasks pages * devtools/Makefile: Remove tasksel .desc and debian/control file in dist target to ensure that these will be created in any case Closes: #554261 * devtools/rules: Do not remove the autogenerated files automatically in get-orig-source target because there are people who explicitly like to commit these to SVN * templates/config.postinst: Return true even if config file is missing. In principle this should not happen, but there are two bug reports about this problem (#550140 and #553632) which will be fixed by this workaround. Most probably this is a side effect from renaming. -- Andreas Tille Wed, 04 Nov 2009 22:25:05 +0100 blends (0.6.6ubuntu1) karmic; urgency=low * Add sources.list.karmic so blends can be built for Ubuntu Karmic -- Scott Kitterman Sun, 30 Aug 2009 11:23:01 -0400 blends (0.6.6) unstable; urgency=low * Fixing some links in the documentation which is addressed by bug #542385 but this bug is not solved by package upload but rather by updating the doc on the website * blends-common.preinst: Do not create config files from Blends guessing from old CDD configuration file. The former behaviour to pre-build those config files leaded to #542656 and #542658. * Removed debian/changelog.med-common because there is no point in providing this now 5 year old file for ever. * Standards-Version: 3.8.3 (no changes needed) -- Andreas Tille Fri, 21 Aug 2009 14:24:50 +0200 blends (0.6.5) unstable; urgency=low * remove minor debugging code from debian/rules * debian/blends-dev.preinst: make sure there are really old sources.list files to copy before trying to do this Closes: #540603 -- Andreas Tille Sun, 09 Aug 2009 07:48:39 +0200 blends (0.6.4) unstable; urgency=low * devtools/blend-get-names: Enable Blends without prefix "debian-" (brdesktop, debichem) * Standards-Version: 3.8.2 (no changes needed) * Move to debhelper 7 short rules file when building Blends * Provide also sources.list.UNRELEASED to enable test builds * debian/rules: drop -k option from dh_clean * devtools/Makefile: Do not use distclean as target to remove automatically created control and tasksel file but rather the proper target. Rationale: dh_clean calls make distclean which would remove debian/control which has to be prevented for sure. -- Andreas Tille Wed, 29 Jul 2009 10:40:04 +0200 blends (0.6.3) unstable; urgency=low * Section for cdd-common misc instead of devel * Updated mailing list address of Debian Pure Blends team * devtools/blends-gen-control: - If a task lists not a single package which is available in the target distribution the metapackage will be suppressed if option '-S' is set; there is one exception which is needed by Debian Edu: If Test-always-lang is set also empty tasks might be created - Prevent Suggestion of non policy conform package names containing upper case letters * devtools/Makefile: - Use -S option of blends-gen-control to not create metapackages with not a single available package - Set LC_ALL=C to prevent blends-gen-control from loading description translation files according to users environment -- Andreas Tille Fri, 10 Apr 2009 21:26:00 +0200 blends (0.6.2) unstable; urgency=low * Bumped policy to 3.8.1 and make use of the new feature that debian/control allows comment lines starting with # with no preceding whitespace. [Policy paragraph 5.2] * Fixed Vcs tags (s/cdd/blends/) -- Andreas Tille Thu, 02 Apr 2009 09:16:07 +0200 blends (0.6.1) experimental; urgency=low * Add sources.list.experimental * debian/rules: variable for package name * Remove explicite path /usr/sbin/ from blend-update-menus in templates/post{inst,rm} because lintian warns about it in the Blend metapackages according to Debian Policy Manual section 6.1. * more elegant method to obtain package version from changelog -- Andreas Tille Fri, 30 Jan 2009 19:30:53 +0100 blends (0.6.0) experimental; urgency=low * The great renaming: The confusing name Custom Debian Distribution was dropped after DebConf 8 and replaced by Debian Pure Blends - in short blends if the iDebian internal use is evident. This reflects in a rename of the package and all the tools. * debian/copyright: new format -- Andreas Tille Sun, 04 Jan 2009 18:08:57 +0100 cdd (0.5.6) unstable; urgency=low * doc/Makefile: publish target now enables moving the docs to http://cdd.alioth.debian.org/cdd instead of people.debian.org/~tille/cdd * share/cdd/unixgroups/cdd-actions: Do not fail if there are NIS users on this machine. These will just be ignored. Closes: #491680 -- Andreas Tille Sun, 13 Jul 2008 13:45:32 +0200 cdd (0.5.5) unstable; urgency=low * New task header Metapackage to make it possible to disable the generation of a binary package with dependencies (and only get a tasksel task). -- Petter Reinholdtsen Fri, 11 Jul 2008 22:08:11 +0200 cdd (0.5.4) unstable; urgency=low * Added patch from Petter Reinholdtsen to enable Enhances feature for tasksel. Closes: #489811 * Better Debconf template for user menus which avoids lintian warnings in CDD metapackages. -- Andreas Tille Tue, 08 Jul 2008 10:40:42 +0200 cdd (0.5.3) unstable; urgency=low * Avoid rsync to build dist target Closes: #488262 * Standards-Version: 3.8.0 (no changes necessary) * Make use of dh_lintian to install overrides * Lintian prefers spelling "metapackage" over meta package on the other hand my dictionary claims metapackage wrong and votes for meta-package. I used the lintian clean spelling suggestion but we need some agreement about a consistent spelling ... -- Andreas Tille Mon, 30 Jun 2008 13:29:11 +0200 cdd (0.5.2) unstable; urgency=low [ Jonas Smedegaard ] * Changed the Maintainer to Custom Debian Distribution Team ( s/List/Team/ ) * Add myself as uploader. [ Andreas Tille ] * Debhelper (>= 6.0.7): Rationale: We are using dh_lintian which is only available from this version on. This is actually not needed to build the cdd-common or cdd-dev package, but it makes perfectly sense to build with the same debhelper version as cdd-dev will finally depend from * share/menu/cdd-menu: verify that /etc/cdd/cdd.conf exists before sourcing it because since menu 2.1.39 supports triggers on /usr/{lib,share}/menu update-menus is called on every touch of these directory and because we have no safe way to ensure that /etc/cdd/cdd.conf is unpackaged before cdd-menu we have to work around the not yet available config file. Even if I regard this as a bug in menu, we have to handle this here vor the moment. Closes: #484167 -- Andreas Tille Mon, 05 May 2008 12:56:37 +0200 cdd (0.5.1) unstable; urgency=low * Changed the Maintainer to Custom Debian Distribution List * Move debian/README.source into every meta package in case such a file exists Closes: #479249 * added dh_lintian Closes: #479248 -- Andreas Tille Sun, 04 May 2008 09:41:03 +0200 cdd (0.5.0) unstable; urgency=low * Removed VERSION file (which is hard to maintain) and teach debian/rules to obtain version from debian/changelog to build dist target * devtools/rules: - Added dist target to build source distribution tarball * debian/rules: several fixes to make use of make variables instead of shell variables * The source tarball of a CDD is now builded with prebuilded debian/control file and is not rebuilded per package build process. * Added "dist" target to devtools/Makefile which builds "get-orig-source" target of devtools/rules. If CDDs build their source tarball using these tools nothing has to be cleaned in build process Closes: #468346 -- Andreas Tille Fri, 07 Mar 2008 13:23:33 +0100 cdd (0.4.8) unstable; urgency=low * Small fix to allow more than one binary package in control.stub * Added myself to uploaders. -- José L. Redrejo Rodríguez Tue, 26 Feb 2008 14:07:45 +0100 cdd (0.4.7) unstable; urgency=low * devtools/rules: - Added '-a' / '-i' options to binary-{arch,indep} targets - Added a test whether we build for arch all or any around cdd-install-helper which is rather a quick hack than a real solution but works. More discussion about what is needed has to be done. * debian/control: Build-Depends -> Build-Depends-Indep * templates/post{inst,rm}: Check existence of CDD configuration files before executing user menu code. If no such config files exist there is no need to run this code -- Andreas Tille Tue, 19 Feb 2008 11:24:50 +0100 cdd (0.4.6) unstable; urgency=low * Fixed Vcs-Browser, Vcs-Svn (Thanks to Thijs Kinkhorst ) * Fix templates/post{inst,rm} to check for files from cdd-common before accessing them -- Andreas Tille Thu, 14 Feb 2008 18:08:57 +0100 cdd (0.4.5.1) unstable; urgency=low * devtools/rules: Also build binary-arch packages because Debian Edu needs this to have correct dependencies on all available architectures. -- Andreas Tille Fri, 25 Jan 2008 08:55:59 +0100 cdd (0.4.5) unstable; urgency=low * Add debconf templates for better menu handling * Regard CDD-config.postinst.stub if user provides such a file * share/cdd/unixgroups/cdd-actions: verify whether a group that should be added just exists * share/menu/cdd-menu: Prepend "!C menu-1" before each menu entry that does not contain a "!C" line to enable menu entries in menu-2 format * Added Vcs-Browser and Vcs-SVN tags * Standards-Version: 3.7.3 (no changes needed) * devtools/cdd-install-helper: removed bashism * devtools/rules: removed bashisms -- Andreas Tille Sat, 20 Oct 2007 12:22:55 +0200 cdd (0.4.4) unstable; urgency=low * Remove old useless comment in share/menu/cdd-menu * If there is no tasksel package wanted, just obtain the meta package prefix from the CDD short name * Make use of cdd-get-names also in cdd-gen-control script -- Andreas Tille Fri, 19 Oct 2007 16:12:51 +0200 cdd (0.4.3) unstable; urgency=low * Add a newline after adding config/control to debian/control * If a CDD provides an auto-apt helper name it CDD-config instead of CDD-common -- Andreas Tille Thu, 18 Oct 2007 20:14:16 +0200 cdd (0.4.2) unstable; urgency=low * Build-Depends: texlive-latex-base, texlive-latex-extra, texlive-fonts-recommended, texlive-latex-recommended Closes: #445777 * debian/cdd-dev.lintian.overrides: Renamed common to config -- Andreas Tille Mon, 08 Oct 2007 12:02:41 +0200 cdd (0.4.1) unstable; urgency=low * Moved documentation package cdd-doc into same source package * Reworked debian/copyright * devtools/cdd-install-helper: If "Task:" keyword is missing in a task control file just do not put it into tasksel area under /usr/share/cdd/tasks/CDD -- Andreas Tille Fri, 31 Aug 2007 19:01:52 +0200 cdd (0.4) unstable; urgency=low * New upstream version that cdd-gen-control in favour of a newly adopted gen-control from Debian-Edu 0.821. (Please see the upstream changelog for all changes) Closes: #436831 -- Andreas Tille Tue, 21 Aug 2007 20:56:39 +0200 cdd (0.3.11.1) unstable; urgency=low * Remove Bashism (source --> .) Closes: #394604 (of med-common, this bug did not really belong to med-common but was caused by the bashism in cdd-common) * Standards-Version: 3.7.2 (no changes necessary) * Build-Depends: debhelper (>= 5) -- Andreas Tille Mon, 23 Oct 2006 07:46:58 +0200 cdd (0.3.11) unstable; urgency=low * Fix problem with resulting *.dsc files that did not list the files that were actually created in the Binary line * No changes necessary Standards-Version: 3.6.2 * Removed: Conflicts: med-common (<= 0.4); which was never released in stable * Because there is no direct use of debconf in the cdd package but debconf is used in the package builded using cdd-dev the ${misc:Depends} variable does not really work. That's why we introduce an explicite Depends: debconf (>= 0.5) | debconf-2.0 * Increased dependant menu version from 2.1.12 to 2.1.25 * Adapted lintian.overrides to reflect the change in menu (files now in /usr/share/menu instead of /usr/lib/menu) -- Andreas Tille Sun, 25 Sep 2005 21:36:29 +0200 cdd (0.3.10) unstable; urgency=low * Andreas Tille - Fixed some man pages and examples - Fixed bugs which showed up in Debian-Junior packaging (work around missing final newlines in several places, fix problem with menu items which are not using '"' around the entries) * Guillem Jover - Added Catalan (ca) debconf translation. * Otavio Salvador - cdd-gen-control: o Add -D suport to cdd-gen-control to degrade dependencies to recommends; o Add support for architecture dependent packages; o Add fallback to architecture independent packages so allow backward compatibility; o Add suport to tasksel based tasks; - task-files: added. * Adopted to findutils 4.2.22: specify the -maxdepth option before non-option arguments -- Andreas Tille Sat, 21 Aug 2004 09:06:13 +0200 cdd (0.3.9) experimental; urgency=low * Otavio Salvador - Move the project to Subversion. * Andreas Tille - Exclude .svn dirs in dist target of debian/rules - Removed Provides/Replaces/Conflicts: med-common-dev because this package vanished completely from the archive now and never reached stable. - Moved cdd-menu from /usr/lib/menu to /usr/share/menu - User menus now are created from installed dependency menus if they are not explicitely overriden by the meta package maintainer -- Andreas Tille Thu, 15 Jul 2004 11:13:22 +0200 cdd (0.3.4) unstable; urgency=high * Fixed common.postinst template which finally fixed bug #259412. * Removed contrib non-free and non-US from the templates - we want to build packages for main by default, others should be added manually by local maintainers. * Urgency set to high because it *really* fixes a grave bug. -- Andreas Tille Thu, 15 Jul 2004 10:51:44 +0200 cdd (0.3.3) unstable; urgency=high * Remove broken code from templates/postinst to clean up ${HOME}/.menu directories. This code does more harm than it would help. Closes: #259412 * Urgency set to high because it fixes a grave bug. -- Andreas Tille Wed, 14 Jul 2004 21:34:55 +0200 cdd (0.3.2) unstable; urgency=low * Remove ${HOME}/.menu/cdd-menu in postinst only if ${MENU}/.menu exists * Added /etc/apt/apt.conf.d script to #cdd#-common templates to invoke cdd-update-usermenus after all meta packages of a CDD were installed if requested by a shared debconf variable * Use #CDDNAME# variable in debconf templates of cdd-dev. This variable can be set either in common/conf or it is builded by "Debian-Cdd". * cdd-install-helper handles CDD-common.{config,template} * Usage of get-group-users deprecated, use cdd-tools instead. Moved functionality of get-group-users to unixgroups/cdd-actions. * Enhanced example directory. * Otavio Salvador - Add support to Pre-Depends field in cdd-gen-control script. - Change the default task prefix from 'education-' to 'test-'. - Include code to stop if exist a task with name 'common'. * Andre Luis Lopes - Added Brazilian Portuguese (pt_BR) cdd-dev debconf template translation. -- Andreas Tille Wed, 9 Jun 2004 08:20:26 +0200 cdd (0.3.1) unstable; urgency=low * Do not change ${HOME}/.menu any more as it was done in 0.3 Thanks to Cosimo Alfarano * Provide man page for cdd.conf * Added newline at end of examples/common/control Closes: #251889 -- Andreas Tille Mon, 31 May 2004 22:45:56 +0200 cdd (0.3) unstable; urgency=low * Cosimo Alfarano did some major rewriting to make the scripts much more flexible (many thanks to Cosimo). * cdd-inst-helper now adds versioned med-common dependency if menu is created by this package. * templates/post{inst,rm} feature user menu creation if variable UPDATEUSERMENU is set to "yes" -- Andreas Tille Tue, 13 Apr 2004 21:51:01 +0200 cdd (0.2) unstable; urgency=low * Initial release of this package which contains code from several packages but should be of common use now. Closes: #240243 * Renamed med-common-dev to cdd-dev because it is intended to work for all Custom Debian Distributions now. * Renamed med-common to cdd-common. (old changelog is available in changelog.med-common. * Adopted gen-control from debian-edu-0.768 -- Andreas Tille Tue, 23 Mar 2004 18:41:20 +0100 med-common-dev (0.1-5) unstable; urgency=low * Standards-Version: 3.6.1.0 * Fixed typo in debian/control closes: #221212 While I think that also spelling bugs should be reported and fixed I really wonder why people set the priority of those bugs to "normal" instead of "wishlist". -- Andreas Tille Tue, 18 Nov 2003 08:58:14 +0100 med-common-dev (0.1-4) unstable; urgency=low * really installed the examples to /usr/share/doc/med-common-dev/examples -- Andreas Tille Mon, 9 Sep 2002 22:19:53 +0200 med-common-dev (0.1-3) unstable; urgency=low * fixes a really stupid bug in med_install_helper -- Andreas Tille Wed, 26 Jun 2002 21:06:11 +0200 med-common-dev (0.1-2) unstable; urgency=low * med_install_helper script now cares for an /etc/med/menu directory if it was not builded in debian/rules and prints out a warning if no menu is provided -- Andreas Tille Wed, 26 Jun 2002 15:59:26 +0200 med-common-dev (0.1-1) unstable; urgency=low * Initial release closes: #150938 -- Andreas Tille Mon, 24 Jun 2002 17:19:38 +0200 blends-0.6.16.4ubuntu2/debian/control0000644000000000000000000000512212147323466014265 0ustar Source: blends Priority: optional Section: devel Maintainer: Ubuntu Developers XSBC-Original-Maintainer: Debian Pure Blend Team Uploaders: Petter Reinholdtsen , Andreas Tille , Cosimo Alfarano , José L. Redrejo Rodríguez , Jonas Smedegaard Build-Depends: debhelper (>= 9) Build-Depends-Indep: debiandoc-sgml, texlive-latex-base, texlive-latex-extra, texlive-latex-recommended, texlive-fonts-recommended, ghostscript Standards-Version: 3.9.4 Vcs-Browser: http://git.debian.org/?p=blends/blends.git Vcs-Git: git://git.debian.org/git/blends/blends.git Package: blends-dev Architecture: all Depends: debconf (>= 0.5) | debconf-2.0, make | build-essential, apt, debhelper (>= 9), ${misc:Depends} Suggests: blends-doc Replaces: cdd-dev Description: Debian Pure Blends common files for developing metapackages This package makes life easier when packaging metapackages. Perhaps this will also encourage other people to build metapackages if there are easy to use templates where only the packages, the metapackage is depending from, to insert into the right place. Package: blends-common Architecture: all Section: misc Depends: adduser, menu (>= 2.1.25), debconf (>= 0.5) | debconf-2.0, ${misc:Depends} Suggests: blends-doc Description: Debian Pure Blends common package This package builds the basic infra structure for metapackages. . This package provides some files which are common to metapackages of Common Debian Distributions. It introduces a method to handle system users in a group named according to the name of the Debian Pure Blend. Package: blends-doc Architecture: all Section: doc Depends: ${misc:Depends} Suggests: www-browser, postscript-viewer Replaces: cdd-doc Description: Debian Pure Blends documentation This paper is intended to people who are interested in the philosophy of Debian Pure Blends and the technique which is used to manage those projects. . It is explained in detail why these are no forks from Debian but reside completely inside the Debian GNU/Linux distribution and which advantages can be gathered by this approach. The concept of metapackages and user role based menus is explained. In short: This document describes why Debian Pure Blends are important to the vitality and quality of Debian. blends-0.6.16.4ubuntu2/sources.list.quantal0000644000000000000000000000007412147323454015462 0ustar deb http://archive.ubuntu.com/ubuntu/ quantal main universe blends-0.6.16.4ubuntu2/etc/0000755000000000000000000000000012147323735012212 5ustar blends-0.6.16.4ubuntu2/etc/blends/0000755000000000000000000000000012147323735013461 5ustar blends-0.6.16.4ubuntu2/etc/blends/blends.conf0000644000000000000000000000066112147323454015600 0ustar # unset it if no DBBACKEND is wanted (no use of Roles) DBBACKEND=unixgroups SHAREDIR=${SHAREDIR:-/usr/share/blends} # unset (NOT set it to false!) for disable dryrun #DRYRUN=true # This would print debugging information #DRYRUN="echo DRYRUN: " #DEBUG=1 # Utility functions, backend indep . ${SHAREDIR}/blend-utils . ${SHAREDIR}/blend-actions # actual action performed by choosen backend . ${SHAREDIR}/${DBBACKEND}/blend-actions blends-0.6.16.4ubuntu2/sources.list.maverick0000644000000000000000000000007512147323454015617 0ustar deb http://archive.ubuntu.com/ubuntu/ maverick main universe blends-0.6.16.4ubuntu2/devtools/0000755000000000000000000000000012147323735013276 5ustar blends-0.6.16.4ubuntu2/devtools/blend-gen-control0000755000000000000000000005420512147323466016544 0ustar #!/usr/bin/perl # # Authors: # Petter Reinholdtsen # Andreas Tille # Date: 2001-08-23 # # Generate the control file used by the Blend task package. use warnings; use strict; use Getopt::Std; use File::Path; use vars qw(%opts %available %excluded %included @wanted %missing @tasks $debug $suppressempty); my @arch = qw(alpha arm i386 ia64 m68k mips mipsel powerpc s390 sparc hppa); my $debug = 0; my $nodepends = 0; my $ignoreapterrors = 0; my $suppressempty = 0; my %taskinfo = (); my $tasksdir = "tasks" ; my $taskcontrolfile = "tasks.ctl" ; my $aptsourcesdefaultlocation = "/etc/blends"; my $aptsources = $aptsourcesdefaultlocation . "/sources.list"; my $blend_dev_dir = "/usr/share/blends-dev"; my %commondepends ; $commondepends{"adduser"} = "0" ; $commondepends{"debconf"} = "1.2" ; $commondepends{"menu"} = "2.1.14" ; my $CommonPackage = "" ; my $prefix = "test-" ; my $blendname = "" ; my $blendshortname = "" ; my $tasksname = "" ; my $hasconfig = 0 ; sub usage() { print STDERR << "EOF"; blend-gen-control help screen usage: $0 [options] -a : print wanted packages -A : ignore APT errors -c : create new debian/control file -d : print debug information -D : lower all Depends: to Recommends: -e : print excluded packages -h : print this help screen and exit -i : -m : print missing packages -s : specify which sources.list file to use -S : suppress tasks without any recommended package -t : print task descriptions and package list for task example: $0 -s sources.list.etch -D -c -m -i EOF } getopts("cdaemis:StDhA", \%opts); usage() and exit if $opts{'h'}; my $aptsourcesinput = $opts{'s'} if ($opts{'s'}); $aptsources = $aptsourcesinput ; if ( $aptsources !~ m%^/% && $aptsources !~ /^sources\.list\./ ) { my $cwd ; chomp($cwd = `pwd`) ; $aptsources = $cwd . "/sources.list." . $aptsources ; } if ( ! -e $aptsources ) { $aptsources = $aptsourcesdefaultlocation . "/sources.list." . $aptsourcesinput; if ( ! -e $aptsources ) { die "Apt sources.list $aptsources not found.\n" ; } } $debug = 1 if ($opts{'d'}); $nodepends = 1 if ($opts{'D'}); $ignoreapterrors = 1 if ($opts{'A'}); $suppressempty = 1 if ($opts{'S'}); blend_init(); # print "$prefix ; $blendshortname ; $blendname ; $tasksname \n"; load_available_packages(); load_tasks(); # An ordered list of Blend tasks, in priority order of which are # most needed on the CD. Only leaf tasks need be listed. my @priorityorder = get_priorities("priority-high", 1); my @medpriorder = get_priorities("priority-med", 0); # print "high: @priorityorder\nmed: @medpriorder\n" ; if ($opts{'c'}) { gen_control(); } elsif ($opts{'e'}) { print_excluded_packages(); } elsif ($opts{'a'}) { print_all_packages(); } elsif ($opts{'t'}) { print_task_desc(); } else { print_available_packages(); } print_missing_packages() if ($opts{'m'}); sub apt { my $op = shift; my $aptdir = "../tmp/apt"; my @aptopts = ("Dir::Etc::sourcelist=$aptsources", "Dir::State=$aptdir/state", "Dir::Cache=$aptdir/cache", "Dir::State::Status=/dev/null", "Debug::NoLocking=true", "APT::Get::AllowUnauthenticated=true"); # Stupid apt-get and apt-cache do not understand the same arguments! # I have to map them to different formats to get both working. if ("update" eq $op) { mkpath "$aptdir/state/lists/partial"; mkpath "$aptdir/cache/archives/partial"; my $aptget = "apt-get --assume-yes -o " . join(" -o ", @aptopts); print STDERR "aptget: $aptget\n" if $debug; if (system("$aptget update 1>&2")) { print STDERR "error: updating apt package lists failed\n"; exit 1 unless $ignoreapterrors; } } elsif ("apt-cache" eq "$op") { my $aptcache = "apt-cache -o=" . join(" -o=", @aptopts); print STDERR "aptcache: $aptcache\n" if $debug; return $aptcache; } } sub sort_uniq { my $seen = shift; my @list; for my $entry (sort @_) { push @list,$entry unless $seen->{$entry}; $seen->{$entry} = 1; } return @list; } sub uniq { my $seen = shift; my @list; for my $entry (@_) { push @list,$entry unless $seen->{$entry}; $seen->{$entry} = 1; } return @list; } sub gen_control { my $task; for $task (sort keys %taskinfo) { next if (exists $taskinfo{$task}{'Metapackage'} && $taskinfo{$task}{'Metapackage'} eq 'false'); print STDERR "$task: $taskinfo{$task}{'haspackages'}\n" if $debug; # if no package was found in the target distribution suppress this task at all if ( $suppressempty && $taskinfo{$task}{'haspackages'} == 0 ) { print STDERR "The metapackage $task will not be created because $taskinfo{$task}{'haspackages'} dependant are in the pool and suppressempty was set ($suppressempty)\n" if $debug; next ; } print "Package: $task\n"; my $header; for $header (qw(Section Architecture Priority)) { print "$header: $taskinfo{$task}{$header}\n" if (defined $taskinfo{$task}{$header}); } my %seenlist; if ($nodepends) { # degrade dependencies to recommends if ( $tasksname ) { print "Depends: $tasksname"; if ( $tasksname =~ /-tasks$/ ) { print ' (= ${binary:Version})'; } if ( $hasconfig ) { print ', ' . $prefix . 'config (= ${binary:Version})'; } print "\n" ; } # Use common %seenlist, as it is no use listing # packages both in recommends and suggest my @list; for $header (qw(Depends Recommends)) { push (@list, @{$taskinfo{$task}{$header}}) if defined $taskinfo{$task}{$header}; } my ($pkglist, $missinglist) = process_pkglist(join(",",@list)); my (@recommends, @suggests); push @recommends, @{$pkglist}; push @suggests, @{$missinglist}; # push(@recommends, ) # if defined $taskinfo{$task}{Depends}; # push(@recommends, ) # if defined $taskinfo{$task}{Recommends}; push(@suggests, @{$taskinfo{$task}{Suggests}}) if defined $taskinfo{$task}{Suggests}; print("Recommends: ", join(",\n ", sort_uniq(\%seenlist, @recommends)),"\n") if defined $taskinfo{$task}{Depends}; print("Suggests: ", join(",\n ", sort_uniq(\%seenlist, @suggests)),"\n") if @suggests; } else { for $header (qw(Depends Recommends Suggests)) { print "$header: ", join(",\n ", sort_uniq(\%seenlist, @{$taskinfo{$task}{$header}})),"\n" if defined $taskinfo{$task}{$header}; } } # Description Description-long print "Description: $taskinfo{$task}{Description}\n"; print "$taskinfo{$task}{'Description-long'}"; # Already contain newline print "\n"; } } # List all depends, recommends and suggests packages as task packages. # Optionally, list depends as key packages, and the rest as task # packages. # Enable to list all dependencies as key packages my $task_depends_are_keys = 0; sub print_task_desc { foreach my $task (sort keys %taskinfo) { next if (exists $taskinfo{$task}{'Leaf'} && $taskinfo{$task}{'Leaf'} eq 'false'); my $header; if ( $suppressempty && $taskinfo{$task}{'haspackages'} == 0 ) { # Check for Test-always-lang header. If this field exists the # task should be created even if there are no explicite dependencies # This is a request of Debian Edu (see the thread at # http://lists.debian.org/debian-blends/2009/04/msg00008.html my $foundflag = 0; for $header (keys %{$taskinfo{$task}}) { if ($header =~ m/Test-always-lang/) { print STDERR "Print empty task $task because Test-always-lang is set\n" if $debug; $foundflag = 1; last; } } if ( $foundflag == 0 ) { print STDERR "The metapackage $task will not be created because $taskinfo{$task}{'haspackages'} dependant are in the pool and suppressempty was set ($suppressempty)\n" if $debug; next ; } } print "Task: $task\n"; print "Section: $blendname\n"; print "Description: $taskinfo{$task}{Description}\n"; print "$taskinfo{$task}{'Description-long'}"; # Already contain newline print "Relevance: 10\n"; print "Enhances: $taskinfo{$task}{Enhances}\n" if exists $taskinfo{$task}{Enhances}; for $header (keys %{$taskinfo{$task}}) { if ($header =~ m/test-.+/i) { print "$header: $taskinfo{$task}{$header}\n"; } } unless (exists $taskinfo{$task}{'Metapackage'} && $taskinfo{$task}{'Metapackage'} eq 'false') { # No use listing a metapackage as a key package, if no metapackage exist. print "Key: \n"; print " $task\n"; } my %seen; $seen{$task} = 1; if ($task_depends_are_keys) { foreach my $package (task_packages($task, "Depends")) { print " $package\n" unless $seen{$package}; $seen{$package} = 1; } } print "Packages: list\n"; for my $header (qw(Depends Recommends)) { foreach my $package (task_packages($task, $header, 1)) { print " $package\n" unless $seen{$package}; $seen{$package} = 1; } } print "\n"; } } sub select_alternative { my $pkglist = shift; return $pkglist; } sub task_packages { my ($task, $header, $includealldeps) = @_; my @packages = $task; foreach my $package (@{$taskinfo{$task}{$header}}) { if ($package=~/\|/) { # Tasksel doesn't allow boolean or-ing of # dependencies. Just take the first one that is # available. my $ok=0; foreach my $alternative (split(' | ', $package)) { if (! exists $taskinfo{$alternative} && ! exists $available{$alternative}) { if (! exists $missing{$alternative}) { $missing{$alternative} = 1; } } else { print STDERR "task_packages: choosing $alternative from $package\n" if $debug; $package=$alternative; $ok=1; last; } } if (! $ok) { next; } } if (exists $taskinfo{$package}) { # Add packages from task recursively, since # tasksel does not support dependent tasks of # the type used by Blend if (defined $includealldeps && $includealldeps) { for my $h (qw(Depends Recommends)) { push(@packages, $package, task_packages($package, $h, 1)); } } else { push(@packages, $package, task_packages($package, $header)); } } else { push @packages, $package; } } return @packages; } # # Check the APT cache, and find the packages currently available. # sub load_available_packages { apt("update"); my $aptcache = apt("apt-cache"); open(APT, "$aptcache dump |") || die "Unable to start apt-cache"; my $pkg; while () { chomp; if (/^Package: (.+)$/) { $pkg = $1; print STDERR "Found pkg '$pkg'\n" if $debug; } if (/^\s+Version:\s+(.+)/) { print STDERR " pkg $pkg = ver $1\n" if $debug; # print "C: $pkg $available{$pkg} lt $1\n" if ( exists $available{$pkg}); $available{$pkg} = $1 if ( ! exists $available{$pkg} || $available{$pkg} lt $1 ); } } } # # Load all tasks # sub load_tasks { my $taskfile; # First document their existence, so they can depend on each other. for $taskfile () { next if (($taskfile eq "tasks/CVS") || ($taskfile eq "tasks/.svn")); next if ($taskfile =~ m/~$/); my $curpkg = $taskfile; $curpkg =~ s%tasks/%$prefix%; $available{$curpkg} = "n/a"; push(@tasks, "$taskfile:$curpkg"); } # Next, load their content. my $foo; for $foo (@tasks) { my ($taskfile, $curpkg) = $foo =~ m/^(.+):(.+)$/; next if ("tasks/CVS" eq $taskfile); load_task($taskfile, $curpkg); } } sub process_pkglist { my $pkgstring = shift; my @pkglist = (); my @missinglist = (); my $packages; for $packages (split(/\s*,\s*/, $pkgstring)) { print "E: double comma?: $_\n" if ($packages =~ /^\s*$/ && $debug); my $package; my @alternates=split(/\s*\|\s*/, $packages); my $alternatecount=0; for $package (@alternates) { print STDERR "Loading pkg '$package'\n" if $debug; if ($package =~ /[A-Z]/) { print STDERR "Packages may not contain upper case letters (policy 5.6.7) $package. Name will be turned into "; $package = lc($package); print STDERR "$package\n"; } if ($package =~ /^-(.+)$/) { $excluded{$1} = 1; } elsif ( !exists $available{$package} ) { if ( !exists $missing{$package}) { $missing{$package} = 1; } push(@missinglist, $package); } else { if ($alternatecount == 0) { #push(@pkglist, $package) if (! exists $pkglist[$package]); push(@pkglist, $package); } else { $pkglist[-1].=" | $package"; } $alternatecount++; if ( ! $included{$package} ) { push(@wanted, $package); $included{$package} = 1; } } } } return (\@pkglist, \@missinglist); } sub load_task { my ($taskfile, $curpkg) = @_; open(TASKFILE, "<$taskfile") || die "Unable to open $taskfile"; my $line; $taskinfo{$curpkg} = (); print STDERR "Loading task $curpkg\n" if $debug; my $haspackages = 0; while () { chomp; next if (m/^\#/); # Skip comments $line = $_; # Append multi-line while ($line =~ /\\$/) { $line =~ s/\s*\\//; $_ = ; chomp; $line .= $_; } # Remove trailing space $line =~ s/\s+$//; $_ = $line; for my $header (qw(Section Architecture Priority Leaf Enhances Metapackage)) { $taskinfo{$curpkg}{$header} = $1 if (m/^$header:\s+(.+)$/); } $taskinfo{$curpkg}{$1} = $2 if (m/^(test-.+):\s+(.+)$/i); if (m/^Description:\s+(.+)$/) { $taskinfo{$curpkg}{'Description'} = $1; $taskinfo{$curpkg}{'Description-long'} = ""; while () { # End of description, pass next line to pattern matching last if (m/^\S+/ || m/^\s*$/); $taskinfo{$curpkg}{'Description-long'} .= $_; } } next unless defined $_; my $header; for $header (qw(Depends Recommends Suggests)) { if (m/^$header:\s+(.+)$/ && $1 !~ /^\s*$/) { $taskinfo{$curpkg}{$header} = () if (! exists $taskinfo{$curpkg}{$header}); my ($pkglist, $missinglist) = process_pkglist($1); push(@{$taskinfo{$curpkg}{$header}}, @{$pkglist}); $haspackages += $#{$taskinfo{$curpkg}{$header}} + 1; print STDERR "$curpkg $header:", @{$taskinfo{$curpkg}{$header}}, "($haspackages)\n" if $debug; # Avoid missing packages in Depends lists, allow them # in the two others. Insert missing depends in # suggests list. if (@{$missinglist}) { print STDERR "$curpkg: missing = ", @{$missinglist}, "\n" if $debug; if ("Depends" eq $header) { push(@{$taskinfo{$curpkg}{'Suggests'}}, @{$missinglist}); } else { push(@{$taskinfo{$curpkg}{$header}}, @{$missinglist}); } } } } if (/^Avoid:\s+(.+)$/) { my @pkgs = split(/\s*,\s*/, $1); my $packages; for $packages (@pkgs) { my $package; for $package (split(/\s*\|\s*/, $packages)) { $excluded{$package} = 1; } } } if (/^Ignore:\s+(.+)$/) { my @pkgs = split(/\s*,\s*/, $1); my $packages; for $packages (@pkgs) { my $package; for $package (split(/\s*\|\s*/, $packages)) { # Remove explanations, ie the paranteses at the end. $package =~ s/\s*\([^\)]*\)\s*$//; $missing{$package} = 1; } } } } close(TASKFILE); unless ( $taskinfo{$curpkg}{'Architecture'} ) { $taskinfo{$curpkg}{'Architecture'} = "all" ; } $taskinfo{$curpkg}{'haspackages'} = $haspackages; print STDERR "$curpkg: haspackages = ", $taskinfo{$curpkg}{'haspackages'}, "\n" if $debug; } sub print_excluded_packages { print join("\n", sort keys %excluded),"\n"; } sub print_available_packages { print join("\n", @wanted),"\n"; } sub print_all_pkgs_tasks { my ($seenref, $headerlistref, @tasks) = @_; my @headers; if ( $headerlistref ) { @headers = @{$headerlistref}; } else { @headers = qw(Depends Recommends Suggests) } for my $header (@headers) { print STDERR " Processing $header\n" if $debug; my %seentask; for my $task (@tasks) { next if $seentask{$task}; $seentask{$task} = 1; print "# printing $header in $task\n"; print STDERR " Printing $task\n" if $debug; # Pick the first available if there are alternatives my @pkgs = uniq($seenref, task_packages($task, $header), $task); print join("\n", @pkgs), "\n" if @pkgs; } } } sub print_all_packages { print STDERR "Printing all packages\n" if $debug; # print join("\n", @wanted, keys %missing),"\n"; print "# First process the high priority tasks\n"; my %seenlist; print_all_pkgs_tasks(\%seenlist, [qw(Depends Recommends)], @priorityorder ); print "# Next, medium priority tasks tasks\n"; print_all_pkgs_tasks(\%seenlist, [qw(Depends Recommends)], @medpriorder ); print "# Next process all the others, in alphabetic order\n"; print_all_pkgs_tasks(\%seenlist, undef, sort keys %taskinfo); print "# And last, the alternatives we dropped above\n"; print join("\n", uniq(\%seenlist, @wanted, sort keys %missing)),"\n"; } sub print_missing_packages { if (%missing) { print STDERR "Missing or avoided packages:\n"; my $package; for $package (sort keys %missing) { if (exists $available{$package}) { print STDERR " $package (v$available{$package} available)\n"; } else { print STDERR " $package\n"; } } exit 1 unless $opts{'i'}; } } ## Additions by Andreas Tille sub get_priorities { my ($prio, $default) = @_; my @list = () ; # if there is no taskcontrolfile every task has the same priority if ( ! stat($taskcontrolfile) ) { if ( ! $default ) { return (); } print STDERR "No task control file found - setting all tasks priority high.\n" if $debug; opendir(DIR, $tasksdir) || die("No tasks directory found."); @list = grep { !/^\./ } readdir(DIR); closedir DIR; return @list; } # read taskcontrolfile and find priorities print STDERR "Reading task control file.\n" if $debug; open(PRIO,$taskcontrolfile) || die("Unable to read task control file."); while () { chomp ; if ( $_=~/^$prio\s*:\s*([-\w]+)/) { push @list,$1; } } close PRIO; return @list; } sub blend_init { # initialise blend name and other basic stuff unless ( -d "debian" ) { mkdir("debian") || die "mkdir debian: $!"; } unless ( -e "debian/control.stub" ) { print STDERR "No template debian/control.stub. Use test prefix.\n" ; } else { chomp($prefix = `$blend_dev_dir/blend-get-names metapackageprefix`) ; $prefix = $prefix . "-" ; $tasksname = $prefix . "tasks"; chomp($blendshortname = `$blend_dev_dir/blend-get-names blendshortname`); chomp($blendname = `$blend_dev_dir/blend-get-names blendname`); } if ( -d "config" && -e "config/control" ) { $hasconfig = 1; } } blends-0.6.16.4ubuntu2/devtools/blend-get-names0000755000000000000000000000216712147323454016172 0ustar #!/bin/sh # Read Blend specific names from debian/control.stub # # Copyright (C) Andreas Tille # License: GPL # Return codes according to # http://epydoc.sourceforge.net/stdlib/posix-module.html CONTROLFILE=debian/control.stub GetShortName () { grep '^Source:' $CONTROLFILE | \ sed -e 's/^Source:[[:space:]]*//' -e 's/^debian-//' } if [ ! -e "$CONTROLFILE" ] ; then echo "Missing control file $CONTROLFILE" exit 72 # EX_OSFILE fi if [ "$#" -ne 1 ] ; then echo "Missing argument" echo "Usage: $0 blendname|blendshortname|metapackageprefix" exit 64 # EX_USAGE fi case "$1" in blendname) grep '^Source:[[:space:]]*' "$CONTROLFILE" | \ sed 's/^Source:[[:space:]]*//' exit 0 ;; blendshortname) GetShortName exit 0 ;; metapackageprefix) mprefix=`grep '^Package:[[:space:]]*' "$CONTROLFILE" |head -1| \ sed 's/^Package:[[:space:]]*\([[:alnum:]]\+\)-*.*/\1/'` if [ -z $mprefix ] ; then GetShortName else echo $mprefix fi exit 0 ;; *) echo "Unknown argument $1" echo "Usage: $0 blendname|blendshortname|metapackageprefix" exit 64 # EX_USAGE ;; esac blends-0.6.16.4ubuntu2/devtools/blend-install-helper0000755000000000000000000001454512147323466017243 0ustar #!/bin/sh blend=`/usr/share/blends-dev/blend-get-names metapackageprefix` menudir=usr/share/blends/"$blend"/menu SubstBlendName () { sed -e "s/#BLEND#/${blend}/g" \ -e "s?\([/ ]\)\(config.templates:*\)?\1${blend}-\2?" \ -e "s/#BLENDNAME#/${BLENDNAME}/g" /usr/share/blends/templates/$1 >> \ debian/$2 } # Make dependency from menu containing packages to the right #BLEND#-config version # version="(>= `dpkg-parsechangelog | grep "^Version:" | sed -e "s/^Version:[[:space:]]\+\([\.0-9]*\)[[:space:]]*/\1/"`)" version="(>= `dpkg-parsechangelog | awk '/^Version/ { print $2 }'`)" # First make sure that we really have to prepare a metapackage for all # tasks. It might be that there are tasks without any existing Dependency # inside Debian. These tasks are not mentioned in debian/control - so check # this file first and assemble list of metapackages to create in $TASKLIST TASKLIST="" for pkg in `ls tasks | grep -v "^[a-z]*:$*" | grep -v "^$" | sort | uniq` ; do if grep -q "^Package: ${blend}-${pkg}" debian/control ; then TASKLIST="$TASKLIST $pkg" fi done # General Task registry, menu registration and post{inst,rm} preparation for pkg in $TASKLIST ; do # registration if ! grep -q -w "^Task:" tasks/$pkg ; then echo "Control file template tasks/$pkg does not contain 'Task:' field." # I'm sure there are more clever ways to make the first letter upper case ... # task=`echo $pkg | sed 's/^\(.\).*/\1/' | tr "^[a-z]" "^[A-Z]"``echo $pkg | sed 's/^.//'` # For the moment disable tasksel if there is no "Task:" tag given else task=`grep -w "^Task:" tasks/"$pkg" | sed "s/^Task:[[:space:]]*\([^[:space:]]*\)/\1/"` mkdir -p debian/"$blend"-"$pkg"/usr/share/blends/tasks/"$blend"/ echo "$task" > debian/"$blend"-"$pkg"/usr/share/blends/tasks/"$blend"/"$pkg" fi # if we provide an extra menu which overrides some menus provided by # the maintainers of the dependand packages move them now to the right # directory [ -d menu ] && [ -d menu/"$pkg" ] && \ if [ `find menu/"$pkg" -maxdepth 1 -name \*.menu | wc -l` -gt 0 ] ; then mkdir -p debian/"$blend"-"$pkg"/"$menudir" for dep in `find menu/"$pkg" -maxdepth 1 -name \*.menu` ; do cp -a "$dep" debian/"$blend"-"$pkg"/"$menudir"/`basename "$dep" .menu` done fi # Provide a README.Debian in any case mkdir -p debian/"$blend"-"$pkg"/usr/share/doc/"$blend"-"$pkg" [ ! -s docs/"$pkg"/README.Debian ] && cp -a /usr/share/blends/templates/README.Debian debian/"$blend"-"$pkg"/usr/share/doc/"$blend"-"$pkg" # Check for documentation of packages (*.txt or *.html) which should be viewed in # case of missing GUI [ -d menu ] && [ -d menu/"$pkg" ] && \ if [ `find menu/"$pkg" -maxdepth 1 -name \*.txt -o -name \*.html | wc -l` -gt 0 ] ; then for dep in `find menu/"$pkg" -maxdepth 1 -name \*.txt -o -name \*.html` ; do # Formerly here was checked, whether this package is really listed in the # dependencies, with more clever menu handling it is enough to verify # whether it is mentioned at all in the package relations and the menu # system cares about whether a sugested package is installed or not depmenu=`basename ${dep} .txt` if [ "$depmenu" = `basename ${dep}` ] ; then depmenu=`basename ${dep} .html` ; fi if ! grep -A 5 "Package: $blend-$pkg" debian/control | grep -q -w "$depmenu" ; then ## echo "Package ${depmenu} seems not to be in dependencies" continue fi cp -a "$dep" debian/"$blend"-"$pkg"/usr/share/doc/"$blend"-"$pkg" done fi # if README.Source exits move it into every package [ -s debian/README.source ] && cp -a debian/README.source debian/"$blend"-"$pkg"/usr/share/doc/"$blend"-"$pkg" # post{inst/rm} template are appended if some extra scripts are provided or just created # an extra postinst has to be saved (*.stub) and restored by the clean target in # debian/rules for prepost in postinst prerm ; do [ -s debian/"$blend"-"$pkg".${prepost}.stub ] && cp debian/"$blend"-"$pkg".${prepost}.stub debian/"$blend"-"$pkg".${prepost} if [ -s /usr/share/blends/templates/${prepost} ] ; then sed -e "s/#BLEND#/${blend}/g" \ -e "s/#PKG#/${blend}-${pkg}/g" \ /usr/share/blends/templates/${prepost} >> debian/"$blend"-"$pkg".${prepost} fi done done # if config/config exists use this as general helper script if [ -s config/config ] ; then mkdir -p debian/"$blend"-config/usr/bin mkdir -p debian/"$blend"-config/usr/share/man/man1 cp -a config/config debian/"$blend"-config/usr/bin/"$blend"-config cp -a config/config.1 debian/"$blend"-config/usr/share/man/man1/"$blend"-config.1 # install link to package helper script for pkg in $TASKLIST ; do mkdir -p debian/"$blend"-"$pkg"/usr/bin mkdir -p debian/"$blend"-"$pkg"/usr/share/man/man1 ln -s "$blend"-config debian/"$blend"-"$pkg"/usr/bin/"$blend"-"$pkg" ln -s "$blend"-config.1.gz debian/"$blend"-"$pkg"/usr/share/man/man1/"$blend"-"$pkg".1.gz done fi # config/conf should really exist for the Blend registry in /etc/blends # currently there is no error message issued if it is missing but # this might be reasonable if [ -s config/conf ] ; then # Get name of Debian Pure Blend . config/conf # Config file should set BLENDNAME, but if not try to build a useful one if [ _"$BLENDNAME" = _"" ] ; then BLENDNAME=Debian-`echo ${blend} | perl -ne 'print "\u\L$_";'` fi # Move templates for user configuration script # In case there is a config {preinst/postinst} template, preserve this [ -s config/preinst ] && cp config/preinst debian/"$blend"-config.preinst [ -s config/postinst ] && cp config/postinst debian/"$blend"-config.postinst for comm in `ls /usr/share/blends/templates/config.* /usr/share/blends/templates/apt.conf` ; do commname=`basename $comm` SubstBlendName ${commname} ${blend}-${commname} done # rename apt.conf.d file [ -s debian/${blend}-apt.conf ] && mv debian/${blend}-apt.conf debian/90${blend}-config if [ -d debian/po.stub ] ; then cp -a debian/po.stub debian/po else mkdir -p debian/po fi for po in `ls /usr/share/blends/templates/po/*` ; do poname=`basename $po` SubstBlendName po/${poname} po/${poname} done [ -d debian/po ] && debconf-updatepo # Add common config file for ${blend} mkdir -p debian/"$blend"-config/etc/blends/"$blend" cp -a config/conf debian/"$blend"-config/etc/blends/"$blend"/"$blend".conf fi blends-0.6.16.4ubuntu2/devtools/rules0000755000000000000000000000552212147323466014363 0ustar #!/usr/bin/make -f # This is a debian/rules file which builds meta packages # for a Debian Pure Blend. # # Copyright (C) Andreas Tille # License: GPL BLENDNAME := $(shell /usr/share/blends-dev/blend-get-names blendname) PREFIX := $(shell /usr/share/blends-dev/blend-get-names metapackageprefix) BLENDMKFILE := /usr/share/blends-dev/Makefile BLEND_INSTALL_HELPER := /usr/share/blends-dev/blend-install-helper TARGET_DIST := $(shell head -1 debian/changelog |awk '{print $$3}'|tr -d ';') BLEND := $(shell /usr/share/blends-dev/blend-get-names blendname) GENCONTROL := /usr/share/blends-dev/blend-gen-control VERSION := $(shell dpkg-parsechangelog -ldebian/changelog | grep Version: | cut -f2 -d' ' | cut -f1 -d- ) DISTDIR := $(BLENDNAME)-$(VERSION) all: echo $(PREFIX), $(BLENDNAME) INSTALLREADME := $(shell if test -e README ; then echo "-A README"; fi) debian/control: $(MAKE) -f $(BLENDMKFILE) debian/control $(BLEND)-tasks.desc: $(MAKE) -f $(BLENDMKFILE) $(BLEND)-tasks.desc %: dh $@ override_dh_install: $(BLEND_INSTALL_HELPER) dh_install $(BLENDNAME)-tasks.desc usr/share/tasksel/descs override_dh_installdocs: dh_installdocs $(INSTALLREADME) override_dh_auto_clean: # call make clean instead of distclean make clean override_dh_auto_build: # do nothing, we just called the make install target in advance # and want to build the packages without network access override_dh_clean: # hmmm, that would kill debian/control - so don't do this! # $(MAKE) -f $(BLENDMKFILE) clean # Clear apt-get cache rm -rf tmp # Remove backup files from source tarball rm -f tasks/*~ # Remove auto generated post{inst,rm} scripts rm -f debian/$(PREFIX)-*.postinst debian/$(PREFIX)-*.prerm debian/$(PREFIX)-*.postrm debian/$(PREFIX)-*.preinst # remove auto generated files for config package rm -f debian/$(PREFIX)-config.templates debian/$(PREFIX)-config.config \ debian/$(PREFIX)-config.install debian/$(PREFIX)-config.links \ debian/90$(PREFIX)-config # remove auto generated debconf template translations rm -rf debian/po # remove possibly remaining debhelper files rm -f debian/$(PREFIX)-*.debhelper.log dh_clean get-orig-source: $(BLEND)-tasks.desc debian/control if [ ! -f debian/changelog ] ; then \ echo "File debian/changelog is missing. Something is wrong!" ; \ exit -1 ; \ fi if [ "$(VERSION)" = "" ] ; then \ echo "Unable to obtain version number from debian/changelog. Something is wrong!" ; \ exit -1 ; \ fi ; rm -rf $(DISTDIR) mkdir $(DISTDIR) chmod 777 $(DISTDIR) # copy with exception of VCS stuff tar -cf - --exclude $(DISTDIR) \ --exclude CVS --exclude .svn --exclude svn-commit.tmp --exclude .git . | \ (cd $(DISTDIR); tar xfBp -) rm -f `find $(DISTDIR) -name "*~"` GZIP=-9 tar -czf ../$(BLENDNAME)_$(VERSION).tar.gz $(DISTDIR) rm -rf $(DISTDIR) blends-0.6.16.4ubuntu2/devtools/Makefile0000755000000000000000000000421012147323454014734 0ustar #!/usr/bin/make -f # This Makefile is used to build a debian/control file # for a Debian Pure Blend. # # Copyright (C) Andreas Tille # License: GPL # TARGET_DIST is one of stable, sarge, etch, unstable, or any other available # sources.list file available TARGET_DIST := $(shell head -1 debian/changelog |awk '{print $$3}'|tr -d ';') BLEND := $(shell /usr/share/blends-dev/blend-get-names blendname) GENCONTROL := /usr/share/blends-dev/blend-gen-control # Verify whether config/control exists, if yes, add it to the depends of debian/control CONFIGCONTROL := $(shell if [ -d config -a -e config/control ] ; then echo config/control; fi) all: $(BLEND)-tasks.desc debian/control debian/control: debian/control.stub debian/changelog tasks/* $(CONFIGCONTROL) (export LC_ALL=C;\ echo "# This file is autogenerated via "make -f debian/rules dist". Do not edit!"; \ cat debian/control.stub; \ test -f config/control && ( cat config/control; echo ) ; \ $(GENCONTROL) -s $(TARGET_DIST) -S -D -c -m -i -A) > $@.new && mv $@.new $@ tasksel: $(BLEND)-tasks.desc $(BLEND)-tasks.desc: tasks/* debian/changelog LC_ALL=C $(GENCONTROL) -s $(TARGET_DIST) -S -t -A > $(BLEND)-tasks.desc.new && mv $(BLEND)-tasks.desc.new $(BLEND)-tasks.desc packages.txt: tasks/* $(GENCONTROL) -s $(TARGET_DIST) -a > packages.txt.$$$$ && mv packages.txt.$$$$ packages.txt avoidpackages.txt: tasks/* sources.list.$(TARGET_DIST) $(GENCONTROL) -s $(TARGET_DIST) -e > avoidpackages.txt.$$$$ && mv avoidpackages.txt.$$$$ avoidpackages.txt by_vote: rm -f by_vote wget http://developer.skolelinux.no/popcon/by_vote packages-sorted.txt: packages.txt by_vote for pkg in `cat packages.txt` ; do \ grep " $$pkg " by_vote ; \ done | LANG=C sort -r -n -k 4 -k 3 > packages-sorted.txt usage: packages-sorted.txt clean: rm -rf tmp rm -f tasks/*~ rm -rf tasksel rm -f packages.txt by_vote packages-sorted.txt rm -f debian/*-config.postinst debian/*-config.preinst debian/*-config.postrm debian/*-config.prerm distclean: clean proper: distclean rm -f debian/control rm -f $(BLEND)-tasks.desc dist: rm -f $(BLEND)-tasks.desc debian/control make -f debian/rules get-orig-source blends-0.6.16.4ubuntu2/sources.list.local0000644000000000000000000000005412147323454015105 0ustar deb file:/home/ftp/pub/debian/ testing main blends-0.6.16.4ubuntu2/blend-user.80000644000000000000000000000122112147323454013562 0ustar .TH blend-user 8 "2008/11/05" "" "Debian Pure Blends" .SH NAME .B blend-user \- add/remove user to Role of a registered Debian Pure Blend .SH SYNOPSIS .B blend-user .B add|del < .B Blend > < .B user > [< .B Role >] .SH DESCRIPTION Add user to a .B Role of the specified .B Blend If .B Role is not specified, it's assumed to be named like .B Blend .SH OPTIONS .TP .B Blend - a registered Debian Pure Blend in /etc/blends, for example one of .I edu , .I gis , .I junior , .I med or .I science .TP .B user - user to add .B Role - the role in the Blend that user will assume .SH AUTHOR Andreas Tille Cosimo Alfarano blends-0.6.16.4ubuntu2/share/0000755000000000000000000000000012147323735012541 5ustar blends-0.6.16.4ubuntu2/share/menu/0000755000000000000000000000000012147323735013505 5ustar blends-0.6.16.4ubuntu2/share/menu/blend-menu0000755000000000000000000001644312147323454015467 0ustar #!/bin/bash # Script to handle menu profiles for Debian Pure Blends subsystem, installed # by your system administrator via blends-common package. # # It prints on STDOUT Debian menu entries for user CONFBASE=${CONFBASE:-/etc/blends} # read generic Blends conf ... in case it exists # Since menu 2.1.39 triggers are used to run update-menus for every change # in /usr/{lib,share}/menu - which fails finding ${CONFBASE}/blends.conf in # case you are installing blends-common the first time. I do not regard this # as a reasonable behaviour because it is a real performance loss and # obviousely error prone (for instance in case of blends-common (see #484167) # but we have to deal with this somehow if [ -s "${CONFBASE}/blends.conf" ] ; then . ${CONFBASE}/blends.conf else exit 0 fi BLENDUSER=`whoami` tasksdir=/usr/share/blends/tasks # it has to be run only by unprivileged users via update-menus test "${BLENDUSER}" == "root" && exit 0 # Upper case the first letter of a string to have a nicer menu NameToUpper() { if [ $# -ne 1 ] ; then RET=64 # EX_USAGE return ${RET} fi echo $1 | perl -ne 'print "\u\L$_";' return 0 } # Obtain title from HTML page for menu hints GetHTMLTitle () { if [ $# -ne 1 ] ; then RET=64 # EX_USAGE return ${RET} fi perl -ne 'while (<>) {chomp; $all.="$_ ";} ($title) = ($all =~ /.*\(.*)\<\/title\>.*/i); $title =~ s/\s+/ /g ; print $title ; exit 0;' $1 return 0 } # Obtain title (= first line) from text file for menu hints GetTxtTitle () { if [ $# -ne 1 ] ; then RET=64 # EX_USAGE return ${RET} fi head -1 $1 | sed -e "s/[[:space:]]\+/ /g" -e "s/^[[:space:]]*\(.*\)[[:space:]]*$/\1/" return 0 } # Strip Blend name from metapackage name # FIXME: the Blend name does not necessarily match the metapackage # prefix. Example: education-* packages of Debian Edu # Proposed fix: Read Blend name from config file GetTaskNameFromPackage () { if [ $# -ne 2 ] ; then RET=64 # EX_USAGE return ${RET} fi BLEND=$1 # Blend name PKG=$2 # metapackage name echo $PKG | sed "s/^${BLEND}-//" return 0 } # Obtain task title which has to be defined in the metapackage control templates GetTaskTitle () { if [ $# -ne 1 ] ; then RET=64 # EX_USAGE return ${RET} fi PKG=$1 # metapackage name cat "$tasksdir"/"$BLEND"/`GetTaskNameFromPackage "$BLEND" "$PKG"` return 0 } getMenuEntriesFromDependencies() { RET="" if [ $# -ne 1 ] ; then RET=64 # EX_USAGE return ${RET} fi PKG="$BLEND"-$1 TASK=`GetTaskTitle $PKG` SECTION=`NameToUpper "$BLEND"`/`NameToUpper "$TASK"` # find the list of Depends / Recommends / Suggests DepPkgs=`dpkg --status "$PKG" | \ sed -e '/^Description/,$d' -e '/^Conffiles/,$d' | \ grep -v ^[A-CE-QT-Z] | \ grep -v ^S[eot] | \ sed -e "s/([^)]*)//" \ -e "s/,* *${BLEND}-config//" \ -e "s/^[^:]*: *//" \ -e "s/, */\\n/g" | \ sort | uniq` # check whether Blend maintainer provided menu override different from # package maintainers menu file # FIXME: This is outdated! The concept of menu files named like the # metapackage is stopped in favour of single menu files named like # the dependant package. The rationale is that you can get more # fine grained replacements. blendmenufile="" if [ -s "$HOME"/.menu/"$PKG" ] ; then blendmenufile="$HOME"/.menu/"$PKG" elif [ -s /etc/blends/"$BLEND"/menu/"$PKG" ] ; then blendmenufile=/etc/blends/"$BLEND"/menu/"$PKG" elif [ -s /usr/lib/blends/"$BLEND"/menu/"$PKG" ] ; then blendmenufile=/usr/lib/blends/"$BLEND"/menu/"$PKG" elif [ -s /usr/share/blends/"$BLEND"/menu/"$PKG" ] ; then blendmenufile=/usr/share/blends/"$BLEND"/menu/"$PKG" fi for pkg in $DepPkgs ; do # if Blend maintainer provided override just continue [ ! -z "$blendmenufile" ] && grep -q -i "?package($pkg)" "$blendmenufile" && continue # check for documentation text of Blend maintainer which should # be prefered over package maintainers menu docfile="" if [ -s /usr/share/doc/"$PKG"/"$pkg".html ] ; then docfile=/usr/share/doc/"$PKG"/"$pkg".html elif [ -s /usr/share/doc/"$PKG"/"$pkg".txt ] ; then docfile=/usr/share/doc/"$PKG"/"$pkg".txt elif [ -s /usr/share/doc/"$PKG"/"$pkg" ] ; then docfile=/usr/share/doc/"$PKG"/"$pkg" fi # if Blend maintainer provides documentation view this as menu entry ... if [ ! -z "$docfile" -a -s "$docfile" ] ; then hint="" if file "$docfile" | grep -q HTML ; then senspager=sensible-browser hint=`GetHTMLTitle "$docfile"` else senspager=sensible-pager hint=`GetTxtTitle "$docfile"` fi if [ ! -z "$hint" ] ; then hint="hints=\""$hint"\"" fi # Force menu-1 entry in case before this was menu-2 used cat < /dev/stderr return 0 } # log on stderr for debug outputs blendDebug() { test -n "${DEBUG}" && echo "debug: $@" > /dev/stderr return 0 } # log error and return a fail code $1 blendFail() { RET=$1 shift echo "err ${RET}: $@" > /dev/stderr exit ${RET} } blends-0.6.16.4ubuntu2/share/blends/unixgroups/0000755000000000000000000000000012147323735016233 5ustar blends-0.6.16.4ubuntu2/share/blends/unixgroups/blend-actions0000644000000000000000000001362012147323454020700 0ustar # $Id$ # # Backend dependant functions for blends package # # For error codes check in /usr/include/sysexits.h # CHECK Functions #checkBlend() is backend indep, and is defined in ${SHAREDIR}/blend-actions # Read adduser config to find out from which ID normal users start # Default = 1000 FIRST_UID=1000 [ -s /etc/adduser.conf ] && . /etc/adduser.conf # checks if User $1 exists as a system user checkUser() { RET=0 BLENDUSER=$1 if [ $# -ne 1 ]; then RET=64 # EX_USAGE elif ! getent passwd "${BLENDUSER}" > /dev/null; then RET=67 # EX_NOUSER fi return ${RET} } # checks if Role $1 is registered into system # actually a mere check if Unix group, named like the Blend, exists checkRole() { RET=0 ROLE=$1 if [ "$#" -ne 1 ]; then RET=64 # EX_USAGE elif ! getent group "${ROLE}" > /dev/null; then RET=67 # EX_NOUSER fi return ${RET} } # check if Blend ($1) has registered Role ($2) # (or, in other words, if Role has been registerd as Debian Pure Blend) checkRoleInBlend() { RET=0 BLEND=$1 ROLE=$2 if [ "$#" -ne 2 ]; then RET=64 # EX_USAGE # currently there is no way to extract a Role from a Blend if # they're named differently, using unixgroups backend elif [ "${BLEND}" != "${ROLE}" ]; then RET=69 # EX_UNAVAILABLE fi return ${RET} } # checks if user $2 is registered in Blend $1 checkUserInBlend() { RET=0 BLEND=$1 BLENDUSER=$2 if [ "$#" -ne 2 ]; then RET=64 # EX_USAGE # currently the only way to check if user is registered in a Blend # is check he covers any role the Blend, using unixgroups backend elif [ -z "`getUserRoles ${BLEND} ${BLENDUSER}`" ]; then RET=1 # user has no role, so is not registered in Blend fi return ${RET} } # GET Functions # getBlendList() is backend indep and is defined in ${SHAREDIR}/blend-actions # echos the roles registered by Blend # for Unix groups backend, it's actually the identity function getBlendRoleList() { RET=0 BLEND=$1 if [ "$#" -ne 1 ]; then RET=64 # EX_USAGE else checkRole ${BLEND} && echo ${BLEND} fi return ${RET} } # echoes list of users having role $2 in Blend $1 # if $4 exists use ',' as separator between user names getUsersInRole() { RET=0 BLEND=$1 ROLE=$2 SIMPLE=$3 USERS="" if [ "$#" -ne 3 -a "$#" -ne 4 ]; then return RET=64 # EX_USAGE fi for user in `getent group ${ROLE} | sed -ne "s/.*:\(.*\)$/\1/p" | tr "," " "` ; do REALNAME=" " if [ $SIMPLE -ne 1 ] ; then REALNAME=" (`grep \"^$user:\" /etc/passwd | sed \"s/^$user:[^:]\+:[0-9]\+:[0-9]\+:\([^:]\+\):.*/\1/\" | sed \"s/,.*//\"`)" fi if [ "$#" -eq 4 ]; then if [ "$USERS" != "" ] ; then USERS="${USERS}," fi fi if [ "$USERS" != "" ] ; then USERS="${USERS} " fi USERS="${USERS}${user}${REALNAME}" done echo $USERS return ${RET} } # echoes list of all users of the system # $1 = 1 - simply login names, $1 = 0 (or anything else) - login names and real name # if $2 exists use ',' as separator between user names getAllUsers() { RET=0 if [ "$#" -ne 1 -a "$#" -ne 2 ]; then RET=64 # EX_USAGE else SIMPLE=$1 TMPFILE=`tempfile` (IFS=":" while read user pass uid gid name rest ; do if [ "$uid" != "" ] ; then # in case NIS is used on the machine $uid remains # empty and breaks the following condition. if [ $uid -ge $FIRST_UID -a "$user" != "nobody" ] ; then name=`echo $name | sed "s/,.*//"` if [ $SIMPLE -eq 1 ] ; then echo "$user" >> ${TMPFILE} else echo "$user ($name)" >> ${TMPFILE} fi fi fi done < /etc/passwd ) # Append ',' if second argument is given if [ "$#" -eq 2 ]; then sort -u "${TMPFILE}" | tr '\n' ',' | sed 's/,/&\ /g' | sed 's/, *$//g' else sort -u "${TMPFILE}" fi rm -f "${TMPFILE}" fi return ${RET} } # echo all Role covered by user $2 in Blend $1 getUserRoles() { RET=0 BLEND=$1 BLENDUSER=$2 if [ "$#" -ne 2 ]; then RET=64 # EX_USAGE else BLENDROLES=`getBlendRoleList ${BLEND}` ROLES="" for ROLE in ${BLENDROLES}; do for USER in `getUsersInRole ${BLEND} ${ROLE} 1`; do test "${USER}" == "${BLENDUSER}" && \ ROLES="${ROLES} ${ROLE}" done done blendDebug "getUserRoles(): roles covered by user ${BLENDUSER} in Debian Pure Blend ${BLEND}: ${ROLES}" echo ${ROLES} fi return ${RET} } # echos the home directory of the system user getUserHome() { RET=0 BLENDUSER=$1 if [ "$#" -ne 1 ]; then RET=64 # EX_USAGE else if checkUser ${BLENDUSER}; then getent passwd ${BLENDUSER} | sed "s/.*:\([^:]*\):[^:]*$/\1/" RET=$? else RET=67 # EX_NOUSER fi fi return ${RET} } # ADD/SET functions # adds role $2 to current unix groups for the specified Blend $1, as a system # dynamic allocated group addRole() { RET=0 BLEND=$1 ROLE=$2 if [ "$#" -ne 2 ]; then RET=64 # EX_USAGE else # Check whether group yet exists TESTGROUP="`getent group ${ROLE}`" || true if [ -z "${TESTGROUP}" ] ; then ${DRYRUN} addgroup --system "${ROLE}" || true fi RET=$? fi return ${RET} } # set user $2 to have role $3, for the specified Blend $1 setUserRole() { RET=0 BLEND=$1 USER=$2 ROLE=$3 if [ "$#" -ne 3 ]; then RET=64 # EX_USAGE else ${DRYRUN} adduser ${USER} ${ROLE} RET=$? fi return ${RET} } # DEL/USET Functions # remove role $2 for the specified Blend $1 from current unix groups, as a # system dynamic allocated group delRole() { RET=0 BLEND=$1 ROLE=$2 if [ "$#" -ne 2 ]; then RET=64 # EX_USAGE else if checkRole "${ROLE}"; then ${DRYRUN} delgroup "${ROLE}" RET=$? else RET=67 # EX_NOUSER fi fi return ${RET} } # unset user $2 from having role $3, for the specified Blend $1 unsetUserRole() { RET=0 BLEND=$1 BLENDUSER=$2 ROLE=$3 # Make sure BLENDUSER and ROLE are BOTH defined, # to avoid disasters using deluser if [ "$#" -ne 3 ]; then RET=64 # EX_USAGE else if checkUser "${BLENDUSER}"; then ${DRYRUN} deluser "${BLENDUSER}" "${ROLE}" RET=$? else RET=67 # EX_NOUSER fi fi return ${RET} } blends-0.6.16.4ubuntu2/share/blends/blend-actions0000644000000000000000000000253512147323454016460 0ustar # $Id$ # # Backend independant functions for blends package # # For error codes check in /usr/include/sysexits.h # CHECK Functions # checks if Blend $1 exists as a Blend checkBlend() { RET=0 BLEND=$1 if [ $# -ne 1 ]; then RET=64 # EX_USAGE elif ! [ -d ${CONFBASE}/`toLower ${BLEND}` ]; then RET=67 # EX_NOUSER fi return ${RET} } # GET Functions # echos a space separated list of Blends registered into Blend subsystem getBlendList() { # print out dir in CONFBASE and stript last space added by printf find ${CONFBASE} -mindepth 1 -maxdepth 1 -not -name CVS -type d -printf "%f " | sed s/.$/\\n/g } # echoes a list of DBBACKEND for Blend present in the current system getBackendList() { find ${SHAREDIR} -mindepth 1 -maxdepth 1 \ -not -name CVS -and -not -name menu \ -type d -printf "%f " | sed s/.$/\\n/g } # is user registered in at least one Blend? # it's a kludgy way :(, run a subshell and iterate on every registered Blend # checking if a user covers a Role in that Blend. isUserRegistered() { RET=1 # return false BLENDUSER=$1 for BLEND in `getBlendList`; do # Run a subshell as a environment sandbox ( test -f ${CONFBASE}/${BLEND}/${BLEND}.conf && . ${CONFBASE}/${BLEND}/${BLEND}.conf . ${SHAREDIR}/${DBBACKEND}/blend-actions checkUserInBlend ${BLEND} ${BLENDUSER} && exit 0 ) && RET=0 && break done return ${RET} } blends-0.6.16.4ubuntu2/share/blends/blend-update-menus0000644000000000000000000000074212147323454017425 0ustar # $Id$ # check if I am a specific user amI() { RET=0 test `whoami` != "$1" && RET=1 return ${RET} } # The following scripts have historical reasons and are currently not # used any more. The complete text might be found in version 0.3 of # the scripts. # updates user's menu for user $1, indipendently from any Blend updateUser() { RET=0 SYSUSER=$1 return ${RET} } # updates menu scripts for any user registered in Blend updateBlend() { RET=0 BLEND=$1 return ${RET} } blends-0.6.16.4ubuntu2/blend-role0000755000000000000000000000401012147323454013401 0ustar #!/bin/bash # # $Id$ usage () { echo "Usage: `basename $0` []" echo "action: add|del" echo "Blend: `getBlendList|tr ' ' '|'`" echo "role: `getBlendList|tr ' ' '|'` (default: Blend name)" } # the base dir for Blend conffiles, where script expects to find dirs named like # each registered Blend CONFBASE=${CONFBASE:-/etc/blends} . ${CONFBASE}/blends.conf # Check consistency of passed arguments if [ $# -eq 0 ]; then usage exit 67 # EX_USAGE fi if [ "`toLower $1`" != "add" -a "`toLower $1`" != "del" ] ; then echo "Missing or wrong action name." echo usage exit 67 # EX_USAGE fi if [ -z "$2" ] ; then echo "Missing Blend name." echo usage exit 67 # EX_USAGE fi ACTION=`toLower $1` BLEND=$2 ROLE=${3:-${BLEND}} # Now that we know the selected Blend, we can check if there is a local # configuration for it (ie differnt backend from the default one) test -n "${BLEND}" -a -f ${CONFBASE}/${BLEND}/${BLEND}.conf && . ${CONFBASE}/${BLEND}/${BLEND}.conf if [ -n "${DBBACKEND}" ]; then set -e checkBlend ${BLEND} || blendFail $? "Debian Pure Blend ${BLEND} does not exist" if [ "${ACTION}" = "add" ]; then checkBlend ${BLEND} || blendFail $? "Blend ${BLEND} does not exist" checkRole ${ROLE} && blendFail $? "Role ${ROLE} currently exist" checkRoleInBlend ${BLEND} ${ROLE} || \ blendFail $? "Blend (${BLEND}) and Role (${ROLE}) are not correct or incompatible with the selected backend" addRole ${BLEND} ${ROLE} || \ blendFail $? "Failed to add role ${ROLE}" elif [ "${ACTION}" = "del" ]; then checkBlend ${BLEND} || blendFail $? "Blend ${BLEND} doesn't exist" checkRole ${ROLE} || blendFail $? "Role ${ROLE} doesn't exist" checkRoleInBlend ${BLEND} ${ROLE} || \ blendFail $? "Blend (${BLEND} and Role (${ROLE}) are not correct" delRole ${BLEND} ${ROLE} || \ blendFail $? "Failed to remove role ${ROLE}" blendLog Role ${ROLE} successfully registered in Blend ${BLEND} fi set +e else # EX_USAGE blendFail 67 "You chose to not use Roles" fi blends-0.6.16.4ubuntu2/Changelog0000644000000000000000000000523512147323454013254 0ustar blends 0.6 ---------- - Renaming to blends as shortcut for the new name of the concept "Debian Pure Blends" cdd 0.5 ------- - Create fixed control files. These will not change for a source tarball of a CDD cdd 0.4 ------- 2007-08-23 Andreas Tille - cdd-gen-control is nearly identical to debian-ed/gen-control (which was patched to replace edu/education by variables) - devtools/ rules: General rules file to build meta packages Makefile: make debian/control for a CDD cdd-get-names: Read releavant CDD names from debian/control.stub - now build CDD-config package which was formerly named CDD-common; several renamings in the templates, examples and code from common to config were necessary - moved cdd-gen-control to /usr/share/cdd-dev because there is no reason to call it directly any more but rather via make - moved cdd-install-helper to /usr/share/cdd-dev because its only use is to be called from rules file and there is no sense to bloat /usr/bin with this stuff - dropped cdd-clean-helper - the code was moved to the rules file - do not install the man pages for cdd-gen-control, cdd-install-helper (and obviousely not for the removed cdd-clean-helper any more because - /usr/share/cdd-dev/cdd-get-names obtains certain CDD specific names cdd 0.3.11 and earlier ---------------------- Changes to gen-control - Use /etc/cdd/sources.list as default sources.list If "-s " is specified /etc/cdd/sources.list. is used. Otherwise the argument to option -s is used as sources.list. - /tmp/cdd-apt is used as $aptdir The rationale behind this is to keep the cache stored on building machine even after cleaning up build directory. - The file debian/control.stub is searched for an entry "^Package: ". If this is found it is used as prefix for the packages, so the builded packages are named as -{task1,task2,task3,...}. The default cdd remains "education-". - If there is a common directory a -common package is builded as well. In this case a file common/control must be provided. Changes to debian/rules - After cleaning the target debian/control is just a symlink to debian/control.stub. That's why debian/control.stub needs a Package: entry just to let build tools work. This entry is parsed by cdd-gen-control to obtain the CDD name and debian/control is builded in every build process from scratch. Changes to REAMDE - Moved to README.Debian template which will be installed if the source package contains a docs directory and contains no special README.Debian file. blends-0.6.16.4ubuntu2/sources.list.experimental0000644000000000000000000000022412147323454016507 0ustar # If a Blend should be uploaded to experimental it needs a sources.list # file matching this target. deb http://ftp.debian.org/debian unstable main blends-0.6.16.4ubuntu2/sources.list.stable0000644000000000000000000000005512147323454015266 0ustar deb http://ftp.debian.org/debian stable main blends-0.6.16.4ubuntu2/sources.list.karmic0000644000000000000000000000007312147323454015262 0ustar deb http://archive.ubuntu.com/ubuntu/ karmic main universe blends-0.6.16.4ubuntu2/sources.list.trusty0000644000000000000000000000007312240414671015362 0ustar deb http://archive.ubuntu.com/ubuntu/ trusty main universe blends-0.6.16.4ubuntu2/blend-task-lister0000755000000000000000000000211112147323454014702 0ustar #!/bin/sh # This script respects its own file name to find out the Blend it belongs to # Names should be builded like -task-files # The intended use is to create according symlinks to this file NAME=`basename $0` if [ _"$NAME" = _"blend-task-lister" ] ; then exit fi # the base dir for Blend conffiles, where script expects to find dirs named like # each registered blend CONFBASE=${CONFBASE:-/etc/blends} # a local per Blend conf is sourced later, after argument parsing . ${CONFBASE}/blends.conf BLEND=`echo $NAME | sed 's/-task-files//'` # Now that we know the selected Blend, we can check if there is a local # configuration for it (ie different backend from the default one) test -n "${BLEND}" -a -f ${CONFBASE}/${BLEND}/${BLEND}.conf && . ${CONFBASE}/${BLEND}/${BLEND}.conf if [ -n "${DBBACKEND}" ]; then set -e checkBlend ${BLEND} || blendFail $? "Debian Pure Blend ${BLEND} does not exist" fi # Check consistency of passed argouments if [ $# -ne 1 ] ; then # printing usage makes no sense here exit 67 # EX_USAGE fi cat /usr/share/blends/tasksel/${BLEND}/$1 blends-0.6.16.4ubuntu2/README.BLENDS0000644000000000000000000000233312147323454013264 0ustar This README file explains how to use blend-* scripts. File system: - /etc/blends/ Each Blend should create this directory, containing all the infos needed by blends-* scripts and by the Blend itself. In this way it's clear for users to realize that Blend is using Debian Pure Blends framework - /etc/blends/blends.conf Main configuration file of blend-* scripts. Blends should be aware of it, but not modify it. - /etc/blends//.conf A configuration file, in /bin/sh syntax, in which each Blend can override /etc/blends/blends.conf Blends with particular needing, for example a particular backend, should set variables here. In this way a default set of parameters is provided by blends.conf and a specific set for each Blend instance in /.conf - /usr/share/blends/ Where common functions for the scripts are stored. There will be a directory for each backend and a common set of function that should be mandatory for each registred backend. - /etc/blends//menu// Users' menus for each registered role. If directory is not present, all files in /etc/blends//menu/ are considered to be valid Debian menu entries for any ROLE in Blend. blends-0.6.16.4ubuntu2/blend-role.80000644000000000000000000000107712147323454013556 0ustar .TH blend-role 8 "2008/11/02" "" "Debian Pure Blends" .SH NAME .B blend-role \- add/remove roles in registered Debian Pure Blend .SH SYNOPSIS .B blend-role .B add|del < .B Blend > [< .B Role >] .SH DESCRIPTION Add/remove (register/unregister) .B Role for the specified .B Blend If .B Role is not specified, it's assumed to be named like .B Blend .SH OPTIONS .TP .B Blend - a registered Debian Pure Blend in /etc/blends, of example one of .I edu , .I gis , .I junior , .I med or .I science .SH AUTHOR Andreas Tille Cosimo Alfarano blends-0.6.16.4ubuntu2/blends.conf.50000644000000000000000000000326712147323454013726 0ustar .TH BLENDS.CONF 5 2008-11-05 "Debian Pure Blends Configuration" "" .SH NAME blends.conf \- configuration for Debian Pure Blends registry .SH DESCRIPTION This file is sourced from shell scripts inside the Debian Pure Blends package .B blends-common and thus it has to follow shell syntax. The variables which are set inside this configuration file can be overriden by special Blends configration files .I /etc/blends//.conf for each single Blend. .SH SYNTAX The following variables can be set: .TP .I DBBACKEND Set the backend for the user role management system. Currently the only implemented role management system is .I unixgroups but others might be implemented later. Unsetting this variable leads to use no roles at all. .TP .I UPDATEUSERMENU If this is set to .I yes the user menus of meta packages can be created automatically at install time of the package if the postinst script of the package allows this. It is suggested to use this option in the specific configuration files of a special Debian Pure Blend which overrides the settings of the general configuration file. .TP .I SHAREDIR Set the base directory for the user role management system. While this is more or less a feature for debugging this might be also used otherwise. .TP .I DRYRUN This variable can be set for debugging. Normally it should be left unset (NOT set to false or anything else!). If set to .I true a dry run of the tools is performed or .I echo DRYRUN: would print debugging information. .TP .I DEBUG If set to .I 1 debugging mode is switched on. .SH "SEE ALSO" .BR blend-role (8) .BR blend-update-menus (8) .BR blend-user (8) .SH AUTHOR Andreas Tille Cosimo Alfarano blends-0.6.16.4ubuntu2/BUGS0000644000000000000000000000017712147323454012125 0ustar List of known bugs: ------------------- blend-gen-control does not regard virtual package syntax ('|') and versioned depends. blends-0.6.16.4ubuntu2/blend-user0000755000000000000000000000413112147323454013422 0ustar #!/bin/bash # # $Id$ usage () { echo "Usage: `basename $0` []" echo "action: add|del" echo "Blend: `getBlendList|tr ' ' '|'`" echo "user: user of the system who should be added to the Blend" echo "Role: a registered Role for specified Blend" echo " (default: the one named like Blend)" } # the base dir for Blend conffiles, where script expects to find dirs named like # each registered Blend CONFBASE=${CONFBASE:-/etc/blends} # a local per Blend conf is sourced later, after argoument parsing . ${CONFBASE}/blends.conf # Check consistency of passed argouments if [ $# -eq 0 ] ; then usage exit 67 # EX_USAGE fi if [ "`toLower $1`" != "add" -a "`toLower $1`" != "del" ] ; then echo "Missing or wrong action name." echo usage exit 67 # EX_USAGE fi if [ -z "$2" ] ; then echo "Missing blend name." echo usage exit 67 # EX_USAGE fi if [ -z "$3" ] ; then echo "Missing user name." echo usage exit 67 # EX_USAGE fi ACTION=$1 BLEND=$2 BLENDUSER=$3 ROLE=${4:-${BLEND}} # Now that we know the selected Blend, we can check if there is a local # configuration for it (ie differnt backend from the default one) test -n "${BLEND}" -a -f ${CONFBASE}/${BLEND}/${BLEND}.conf && . ${CONFBASE}/${BLEND}/${BLEND}.conf if [ -n "${DBBACKEND}" ]; then set -e checkBlend ${BLEND} || blendFail $? "Debian Pure Blend ${BLEND} does not exist" checkUser ${BLENDUSER} || blendFail $? "User ${BLENDUSER} does not exist" checkRole ${ROLE} || blendFail $? "Role ${ROLE} does not exist" checkRoleInBlend ${BLEND} ${ROLE} || \ blendFail $? "Blend (${BLEND}) and Role (${ROLE}) are not correct or incompatible with the selected backend" if [ "`toLower ${ACTION}`" = "add" ]; then setUserRole ${BLEND} ${BLENDUSER} ${ROLE} || \ blendFail $? "Failed to set user ${BLENDUSER} to role ${ROLE}" elif [ "`toLower ${ACTION}`" = "del" ]; then unsetUserRole ${BLEND} ${BLENDUSER} ${ROLE} || \ blendFail $? "Failed to unset user ${BLENDUSER} to role ${ROLE}" fi set +e else # EX_USAGE blendFail 67 "You choose to not use Roles" fi blends-0.6.16.4ubuntu2/doc/0000755000000000000000000000000012147323735012204 5ustar blends-0.6.16.4ubuntu2/doc/debian-blends.en.sgml0000644000000000000000000000306112147323454016156 0ustar ] > &titletoc; &ch-introduction; &ch-about; &ch-general-ideas; &ch-existing-blends; &ch-inside; &ch-technology; &ch-starting; &ch-websentinel; &ch-todo; &ap-devel; &ap-quickintro; &ap-bts; blends-0.6.16.4ubuntu2/doc/Makefile0000644000000000000000000000461212147323454013645 0ustar ## ---------------------------------------------------------------------- ## Makefile : makefile for debiandoc-sgml-doc ## ---------------------------------------------------------------------- ## ---------------------------------------------------------------------- ## Document definitions doc_lang := en doc_name := debian-blends doc_sgml := $(doc_name).$(doc_lang).sgml doc_pdf := $(doc_name).$(doc_lang).pdf doc_ps := $(doc_name).$(doc_lang).ps doc_dvi := $(doc_name).$(doc_lang).dvi doc_txt := $(doc_name).$(doc_lang).txt doc_info := $(doc_name).$(doc_lang).info doc_html := $(doc_name).html pkg := blends-doc ## ---------------------------------------------------------------------- ## Package definitions pkg_lang := en ## ---------------------------------------------------------------------- ## General definitions LN := /bin/ln -sf RMR := /bin/rm -fr LOCALE := unset LC_ALL; unset LANG; unset LANGUAGE; ## ---------------------------------------------------------------------- # this can and will be overriden by a higher level makefile PUBLISHDIR := alioth.debian.org:/srv/home/groups/blends/htdocs/blends # There is no difference between letter and a4, but a2 for instance works PAPERSIZE := letter ## ---------------------------------------------------------------------- ## Targets all: html validate: $(doc_sgml) # nsgmls -ges -wall $(doc_sgml) nsgmls -wall -E20 -gues $^ html $(doc_html): $(doc_sgml) $(LOCALE) debiandoc2html -l $(doc_lang) -b $(doc_name) -c $^ $(LN) index.$(pkg_lang).html $(doc_html)/index.html txt $(doc_txt): $(doc_sgml) debiandoc2text -l $(doc_lang) $^ ps $(doc_ps): $(doc_sgml) debiandoc2latexps -l $(doc_lang) -p$(PAPERSIZE) $^ pdf $(doc_pdf): $(doc_sgml) $(LOCALE) debiandoc2latexpdf -l $(doc_lang) -p$(PAPERSIZE) $^ $(RMR) $(doc_name).$(doc_lang).tpt dvi $(doc_dvi): $(doc_sgml) debiandoc2latexdvi -l $(doc_lang) -p$(PAPERSIZE) $^ $(RMR) $(doc_name).$(doc_lang).out info $(doc_info): $(doc_sgml) debiandoc2info -l $(doc_lang) $^ publish: html pdf rsync -azult --delete $(doc_html)/* $(PUBLISHDIR) [ -s debian-blends.en.pdf ] && rsync -azult $(doc_pdf) $(PUBLISHDIR) clean: $(RMR) $(doc_html) $(doc_pdf) $(doc_txt) $(doc_ps) $(doc_dvi) $(doc_info) $(RMR) $(doc_name).$(doc_lang).tpt $(doc_name).$(doc_lang).out find . -name "*~" -exec $(RMR) \{\} \; distclean: make clean .PHONY: all publish clean distclean validate blends-0.6.16.4ubuntu2/doc/en/0000755000000000000000000000000012147323735012606 5ustar blends-0.6.16.4ubuntu2/doc/en/B_quickintro.sgml0000644000000000000000000002130512147323454016122 0ustar Quick intro into building metapackages

There are several descriptions available how to build Debian packages in general. The main resource might be the repository of (especially ). There are several external packaging HOWTOs for example the one from .

Defining dependencies for metapackages

This howto describes the building of metapackages by using the blends-dev package. It is perfectly possible to build a metapackage as any other normal Debian package but this HOWTO has the only purpose to describe the profit you might gain by using these tools. ~> cp -a /usr/share/doc/blends-dev/examples/tasks . ~> cat tasks/README ~> edit tasks/task1 Description: short description long description as in any debian/control file Depends: dependency1, dependency2, ... For each metapackage this skeleton of a debian/control entry is needed. All necessary information is available in the directory /usr/share/doc/blends-dev/examples/tasks.

The packaging directory

To build any Debian package you always need a directory named debian, which contains a certain set of files. The package blends-dev provides a complete set of example files that only have to be copied and after editing some place holders are ready to use. ~> cp -a /usr/share/doc/blends-dev/examples/debian . ~> cat debian/README ~> edit debian/control.stub Now the variables in the file control.stub change the variables named _BLEND_, _MAINTAINER_ etc. to match the names of the Debian Pure Blend to be built. Please note that the file debian/control is and has to be a symbolic link to control.stub to let the blends-dev tools work. ~> edit debian/rules Also in the debian/rules the name of the Blend has to be inserted where the template contains _BLEND_. Depending from the way the sources.list should be scanned the options for the gen-control call can be adjusted.

You have to build the tarball using the command ~> make -f debian/rules get-orig-source For your comfort you might like to create a file Makefile containing #!/usr/bin/make -f include /usr/share/blends-dev/Makefile which enables you to simply use ~> make dist to build the source tarball. This tarball has to be moved to a location where the metapackages will be built. Unpack the tarball there and start the build process using for instance ~> debuild

That's all for the very simple case when the metapackages should not contain user menus. Even if user menus are suggested they are not necessary. The following paragraphs describe how to use the blends-dev tools to support these menus.

The common metapackage

The creation of a common package is optional, but suggested, because it adds some special features like menus, user groups, and probably more in the future. It is automatically built by blend-install-helper, which is called in debian/rules, if the common directory exists. The easiest way to create this is as follows: ~> cp -a /usr/share/doc/blends-dev/examples/common . ~> cat common/README ~> edit common/conf common/control common/common.1 The variables (_BLEND_) in these three files have to be adjusted to the name of the Debian Pure Blend in question. This blend-config cares for the initialisation of the role based menu system and might contain adjustments of the general configuration inside the blends-common.

If the metapackage blend-config will be created according to these rules all other metapackages will depend automatically from this common package. For the friends of auto-apt, a helper /usr/bin/<metapackage-name> will be installed as well, which just prints some information about the meta package. All in all, the usage of the common package is strongly suggested to have a common registry for stuff like user roles and possibly other things that will be implementd in the future.

The metapackage menus

As explained in the metapackages can contain user menus. This optional feature can be implemented easily by using the template from the blends-dev in the following way: ~> cp -a /usr/share/doc/blends-dev/examples/menu . ~> cat menu/README ~> edit menu/task1 Edit the example to legal menu entries of the dependencies of this metapackage ~> cp menu/task1 menu/<metapackage name> A menu file for each task should be created containing valid menu entries for each dependant package. The easiest way to obtain those menu entries is to simply copy the original menu entry files that are contained in the packages on which the metapackage will depend. The only thing that has to be changed in these menu entries is the package field, which has to be changed from <dependent package> to blend-task. All other entries might remain unchanged. This is a good point to check whether the menu entries of the packages you depend from are formated nicely and print the necessary information (for instance make use of "hints"). Here the metapackage maintainer has a good chance for quality assurance work, which is also part of the Debian Pure Blends issue.

In principle these menu items could be created automatically either at metapackage build time or even better in the postinst script of the metapackage because it is granted that the needed menu files are installed on the system, which is not really necessary on the metapackage build machine. This might be implemented in later versions of blends-dev. Currently the policy is that we like to have a little bit of control about the menu entries for the quality assurance issue mentioned above. Last, but not least, there are packages that do not provide a menu entry. If this is the case because the package maintainer just forgot it a bug report should be filed. On the other hand, there are packages with programs that provide a command line interface that does not allow a reasonable menu entry. A solution for this case is provided in the next paragraph.

Menu for any dependency

The idea of the metapackage menu is to provide the user with easily viewable traces of any installed package that helps solving everyday tasks. So if there are packages that do not contain a menu, a screen with relevant documentation should be provided in a viewer by the creator of the metapackage. Such documentation can be created using the following templates: ~> cp -a /usr/share/doc/blends-dev/examples/docs . ~> cat docs/README ~> edit docs/task1/dep1 Provide information about a package <dep1> that is a dependency of the metapackage <task1>, but does not contain a useful menu entry. ~> cp docs/task1/dep1 docs/task1/<dependent pkg> ~> cp -a docs/task1 docs/<metapackage name> This ensures that our users become aware of all interesting packages on their system. The documentation files should contain hints to man pages to read, URLs that should be visited to learn more about the package or some short introduction how to get started.

blends-0.6.16.4ubuntu2/doc/en/02_about.sgml0000644000000000000000000003106612147323454015111 0ustar What are Debian Pure Blends? What is Debian?

The core of an operating system is a piece of software that interacts with the hardware of the computer, and provides basic functionality for several applications. On Linux based systems, the so-called kernel provides this functionality, and the term Linux just means this core without those applications that provide the functionality for users. Other examples are the Hurd, or the flavours of the BSD kernel.

Many applications around UNIX-like kernels are provided by the system. That is why Linux based operating systems are described as GNU/Linux systems. The GNU tools around the Linux kernel build a complete operating system.

Users do not need only an operating system. They also need certain applications like web servers, or office suites. A distribution is a collection of software packages around the GNU/Linux operating system that satisfies the needs of the target user group. There are general distributions, which try to support all users, and there are several specialised distributions, which each target a special group of users.

Distributors are those companies that are building these collections of software around the GNU/Linux operating system. Because it is Free Software, the user who buys a distribution pays for the service that the distributor is providing. These services might be: Preparing a useful collection of software around GNU/Linux. Caring for smooth installation that the target user is able to manage. Providing software updates and security fixes. Writing documentation and translations to enable the user to use the distribution with maximum effect. Selling Boxes with ready to install CDs and printed documentation. Offering training and qualification.

Most distributors ship their distribution in binary packages. Two package formats are widely used: RPM (RedHat Package Manager) which is supported by RedHat, SuSE, Mandriva and others. DEB (Debian Package) used by Debian and derived distributions. All GNU/Linux distributions have a certain amount of common ground, and the (LSB) is attempting to develop and promote a set of standards that will increase compatibility among Linux distributions, and enable software applications to run on any compliant system.

The very essence of any distribution, (whether delivered as RPMs, DEBs, Source tarballs or ports) is the choice of policy statements made (or not made, as the case may be) by the creators of the distribution.

Policy statements in this sense are things like "configuration files live in /etc/$package/$package.conf, logfiles go to /var/log/$package/$package.log and the documentation files can be found in /usr/share/doc/$package."

The policy statements are followed by the tool-chains and libraries used to build the software, and the lists of dependencies, which dictate the prerequisites and order in which the software has to be built and installed. (It's easier to ride a bicycle if you put the wheels on first. ;-) )

It is this adherence to policy that causes a distribution to remain consistent within its own bounds. At the same time, this is the reason why packages can not always be safely installed across distribution boundaries. A SuSE package.rpm might not play well with a RedHat package.rpm, although the packages work perfectly well within their own distributions. A similar compatability problem could also apply to packages from the same distributor, but from a different version or generation of the distribution.

AT: The context is somehow missing here. As you will see later in more detail, Debian Pure Blends are just a modified ruleset for producing a modified (specialised) version of Debian GNU/Linux.

A package management system is a very strong tool to manage software packages on your computer. A large amount of the work of a distributor is building these software packages.

Distributors you might know are , , (now owned by ) and others.

is just one of them.

Well, at least this is what people who do not know Debian well might think about it. But, in fact, Debian is a different kind of distribution ...

What is Debian? (next try)

The Debian Project is an association of individuals who have made common cause to create a free operating system. This operating system that we have created is called Debian GNU/Linux, or simply Debian for short.

Moreover, work is in progress to provide Debian of kernels other than Linux, primarily for the Hurd. Other possible kernels are the flavours of BSD, and there are even people who think about ports to MS Windows.

All members of the Debian project are connected in a , which is woven by signing GPG keys. One requirement to become a member of the Debian project is to have a GPG key signed by a Debian developer. Every time one Debian developer meets another developer for the first time, they sign each other's keys. In this way, the web of trust is woven.

Differences from other distributions

Debian is not a company, but an organisation. It does not sell anything. Debian members are volunteers. Maintainers are working on the common goal: to build the best operating system they can achieve. Debian maintains the largest collection of ready-to-install Free Software on the Internet. There are two ways to obtain Debian GNU/Linux: Buy it from some other distributor on CD. Perhaps the correct term would be redistributor. Because Debian is free, anybody can build his own distribution based on it, sell CDs, and even add new features, such as printed documentation, more software, support for different installers and more. Download Debian from the web for free. The latter is the common way, and there are really great tools to do it this way. Certainly it is always possible to copy Debian from a friend.

Debian Pure Blends

Debian contains nearly 22.000 binary packages, and this number is constantly increasing. There is no single user who needs all these packages (even if conflicting packages are not considered).

The normal user is interested in a subset of these packages. But how does the user find out which packages are really interesting?

One solution is provided by the tasksel package. It provides a reasonable selection of quite general tasks that can be accomplished using a set of packages installed on a Debian GNU/Linux system. But this is not really fine grained, and does not address all of the needs of user groups with special interests.

Debian Pure Blends - in short Blends if used clearly in the Debian internal context which makes "Pure" and "Debian" obvious - which were formerly known as Custom Debian Distributions (this name was confusing because it left to much room for speculation that this might be something else than Debian) try to provide a solution for special groups of target users with different skills and interests. Not only do they provide handy collections of specific program packages, but they also ease installation and configuration for the intended purpose.

Debian Pure Blends are not forks from Debian. As the new name says clearly they are pure Debian and just provide a specific flavour. So if you obtain the complete Debian GNU/Linux distribution, you have all available Debian Pure Blends included.

The concept of what is called Blend in Debian is also known in other distributions. For instance nn Fedora there are even if some SIGs in Fedora are what in Debian is known as interntal project because it is focussed on technical implementetions and not on user oriented applications.

Difference between a Blend and a remastered system

Not necessarily all currently existing Blends are actually providing installation media (live media or installer). The reason for this is that such installation media are not always necessary / wanted. You can just install plain Debian and install some metapackages on top of it. However, the metapackage approach makes the creation of installation media quite simple by using . Here are some reasons for this approach compared to a remastering strategy.

Technical

The process for creation of a blend involves starting with a Debian or derivative repository and creating an image directly from that (live, install or otherwise) that contains a selection of material from that repository delivered in such a way that it is usable by a particular target user for a particular purpose with a minimum of effort.

By contrast, the process of remastering generally involves first downloading an image produced by the parent distro (live, install or otherwise,) then tearing it apart and reassembling it with your customizations applied.

Philosophical

The blends philosophy is to work as closely with the parent distro as possible. If possible, the project should be done entirely within the distro as a subproject, containing only material supplied by the parent distro. We call this a "Pure Blend".

The remastering philosophy (if it can be called that) seems to be "whatever works" and involves little or no interaction with the parent distro. It's a lazy approach used by people who have newly discovered that they can hack images to make them into custom images to make something uniquely theirs. Probably fine for quick-and-dirty results, but hard to support in the long run.

The users of a blend are served better than the users of a remaster because of the following advantages:

Technical advantage

A new version of a well-crafted blend ought to be able to be produced at any time directly from the repository simply by building it; the user has some assurance that the resulting system remains 'untainted' by hacking it up with scripts that 'damage' the original system by removing files from packages, changing files in packages, etc. something that hurts maintainability / support for such a system.

Community advantage

A blend project aims to leverage support resources from the existing community to serve some sub-community within it. They accomplish this by not violating Debian packaging policy, producing something that is either pure Debian (a "pure blend") or Debian + additional packages, rather than some frankendistro artlessly stitched together from someone else's distro with scripts that change things everywhere with no regard to policy. Thus, normal support channels can be used with a pure blend since what you end up with is not a derivative at all, but just Debian, set up and ready to go for whatever you wanted to use it for.

blends-0.6.16.4ubuntu2/doc/en/00_titletoc.sgml0000644000000000000000000000554512147323454015627 0ustar Debian Pure Blends Andreas Tille tille@debian.org This paper is intended for people who are interested in the philosophy of Debian Pure Blends (in short "Blends" if it is used clearly in internal Debian context), and the technique that is used to manage those projects. For those who are familiar with the concept of Custom Debian Distributions: We just found a new name for this concept because the old name just not expressed what actually is done. It is explained in detail why Blends are not forks from Debian, but reside completely inside the Debian GNU/Linux distribution, and which advantages can be enjoyed by taking this approach. The concept of metapackages and user role based menus is explained. In short: This document describes why Debian Pure Blends are important to the vitality and quality of Debian. Copyright © 2004 - 2011 Andreas Tille, Ben Armstrong

This manual is Free Software; you may redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2.0, or (at your option) any later version.

This is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. See the GNU General Public License for more details.

A copy of the GNU General Public License is available on the World Wide Web at . You can also obtain it by writing to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110, USA.

You can find the source of this article . It is also available as Debian package blends-doc.

A will be built from time to time.

blends-0.6.16.4ubuntu2/doc/en/07_starting.sgml0000644000000000000000000004311012147323454015630 0ustar How to start a Debian Pure Blend

This chapter is based on the Debian Subproject HOWTO, which was written by Ben Armstrong synrg@debian.org.

Planning to form a Debian Pure Blend

In this section, issues to think about before starting a Debian Pure Blend will be discussed. It is important to have a clear idea where to head and how to get there before launching into this adventure.

Leadership

The existing Debian Pure Blends have clearly shown that they depend on a person who keeps things running. If anybody wants to start a project at first, he has to answer the question: "Am I the right person for the job?" Surely this is a question that may be faced with some amount of uncertainty. The way Debian Pure Blends started in the past was for the person with the idea for the project to just start doing the work. After some time using this approach, it became clear that if the project lacked a person to take leadership, the project would become stale. So the initiator has to answer the question clearly, whether or not he is able to continue in the job of leader, considering the amount of time he will have to spend, and the technical and social skills which are needed.

Defining the scope of the Blend

It is as important to decide what your group is not going to do as it is what it is going to do. A clear borderline is essential for the development of the project. Without it, outsiders might either expect more from the project than it can accomplish, or may ignore the project, finding it not helpful because they are not able to find out the purpose.

By maintaining a good relationship with other Free Software projects, some common tasks can be done very effectively. When efforts can be shared, the amount of work for each project can be reduced.

Checking for cooperation with other Debian Pure Blends is always a good idea. In technical terms, this is obvious, but sometimes there are possibilities to share efforts when the goals of two projects have parts in common.

The one who decides to start a Debian Pure Blend takes on a responsibility for this project. It has to be for the good of Debian as a whole, and should bring an extra reputation to our common goal to build the best operating system.

Initial discussion

By the time you have begun to think about forming the subproject, have made the commitment to lead it, and have sketched out a bit of where you want to go and how you'll get there, you have likely already done some informal discussion with your peers. It is time, if you haven't already, to take these ideas to the broader Debian developer community, opening discussion on the creation of your group.

Calling all developers

At this stage, you will want to reach as broad an audience as possible. You have carefully thought out what you're going to do, and are able to articulate it to Debian as a whole. Let everyone know through the debian-devel-announce@lists.debian.org mailing list, setting the Reply-to: debian-devel@lists.debian.org and listen to what everyone has to say about your idea. You may learn some valuable things about pitfalls that may lie ahead for your group. Maybe even show-stoppers at that. You may also find a number of like-minded individuals who are willing to join your group and help get it established.

Steering the discussion

It's all too easy to get lost in ever-branching-out sub-threads at this point. Many people will be firing off ideas left, right and centre about what your group should do. Don't worry too much about containing the discussion and keeping it on track with your main idea. You would rather not squelch enthusiasm at this point. But do try to steer the discussion a bit, focusing on the ideas that are central to your subproject and not getting lost in the details.

At some point, you'll decide you've heard enough, and you're ready to get down to the business of starting your group.

Setting up Mailing list

It is fairly important to enable some means for communication for the project. The most natural way to do this is with a mailing list.

Creating a new mailing list starts with a wishlist bug against lists.debian.org. The format of this bug has to follow .

Before your list can be created, the listmasters will want assurance that creation of the list is, in fact, necessary. So for this reason, don't wait for your list to be created. Start discussing your new project on debian-devel@lists.debian.org immediately. To help distinguish your project's posts from the large amount of traffic on this list, tag them in the Subject field with an agreed-upon tag. An example bug report to create the relevant list is bug .

When sufficient discussion on the developer's list has taken place and it is time to move it to a subproject list, add to your wishlist bug report some URLs pointing to these discussions in the archives as justification for creation of your list.

Web space

A simple possibility, and one which is fairly attractive because it facilitates collaborative web site creation and maintenance, is to put a page on the . There is a special .

A good place to put static web pages or even PHP code is the common place on Alioth for all Blends: . There is a subdirectory for each Blend and it is very easy to create a simple index page there which points to the automatically generated web pages which are mentioned in . Following this strategy is quite cheap and has a big effect when using the tools provided by the Debian Pure Blends effort.

Sooner or later a Debian Pure Blend will establish an own project at , since this enables many features for group maintaining packages, create mailing lists for different purposes, maintain a version control system like SVN or Git etc. The Alioth project enables to provide web sites as well and the Debian Med project is using this since a long time.

Finally, the best way is to have a page under . While not as straightforward as any of the other options, this approach has its advantages. First, the site is mirrored everywhere. Second, the Debian web site translators translate pages into many different languages, reaching new potential audiences for your Debian Pure Blend, and improving communication with other members of your project and interested parties for whom English is not their most comfortable language. Third, a number of templates are available to make your site more integrated with the main web site, and to assist with incorporating some dynamic content into your site. Before you join the Debian Web team you should .

Once this is done, the Debian web pages team should be contacted via the mailing list debian-www@lists.debian.org to add the project to the .

Repository

On a -site is running to host all Debian related project work. Creating a project on Alioth is a good idea to start teamwork on the code a Debian Pure Blend is releasing.

Formal announcement

Once there is a list, or at least enough preliminary discussion on debian-devel to get started, and there is some information about the newly planned Debian Pure Blend available on the web, it is time to send a formal announcement to debian-devel-announce@lists.debian.org. The announcement should include references to past discussions, any web pages and code which might already exist, and summarise in a well thought out manner what the project is setting out to achieve. Enlisting the help of fellow developers on irc or in private email to look over the draft and work out the final wording before it is sent out is always a good idea.

Emails to debian-devel-announce@lists.debian.org have to be signed by the GPG key of an official Debian developer. However, it should not be a very hard task if somebody wants to support Debian while not yet being a developer to find a developer who volunteers to sign an announcement of a reasonable project. It might be reasonable to send this announcement also to other relevant non-Debian lists. If your announcement is well done, it will draw a number of responses from many outsiders, and will attract people to Debian.

Explaining the project

Now the real work starts. People who are involved in the project should be aware that they have to answer questions about the project whenever they show up at conferences or at an exhibition booth. So being prepared with some flyers or posters is always a good idea.

Project structure Sub-setting Debian

While there are a variety of different kinds of work to be done in Debian, and not all of them follow this pattern, this document describes one particular kind of project. Our discussion about Debian Pure Blends concerns sub-setting Debian. A sub-setting project aims to identify, expand, integrate, enhance, and maintain a collection of packages suitable for a particular purpose by a particular kind of user.

Now, strictly speaking, a subset of packages could be more general than described above. A subset could be a broad category like "audio applications" or "network applications". Or it could be more specific, such as "web browsers" or "text editors". But what a sub-setting project such as Debian Jr. aims to do is not focus on the kind of package, but rather the kind of user. In the case of Debian Jr. it is a young child.

The sort of user the project looks after, and which of the needs the project hopes to address are defined by the project's goals. BA: I had a bit of trouble deciding how to punctuate the following passage. I considered and rejected the advice given here in response to Kirsten's question about punctuating a list of questions: http://www.udel.edu/eli/g20.html, instead following the advice found elsewhere on the Web that double punctuation should be avoided. Thus, Debian Jr. first had to decide which children the project would reach: "What age?" "English speaking children only, or other languages as well?" Then the project had to determine how and where they would be using Debian: "At home?" "In school?" "Playing games?" "On their own systems?" "On their parents' systems?"

The answers to all of these questions are not straightforward. It is very much up to the project to choose some arbitrary limits for the scope of their work. Choose too broad a focus, or one which duplicates work already done elsewhere, and the energy of the project dissipates, making the project ineffective. Choose too narrow a focus and the project ends up being marginal, lacking the critical mass necessary to sustain itself.

A good example was the request to split the microbiology related packages out of Debian Med into a Debian Bio project. This is reasonable in principle, and should really be done. In fact, the initiator of Debian Med would support this idea. So he gave the answer: "Just start the Debian Bio project to take over all related material. Until this happens, Debian Med will cover medical material that deals with sequence analysis and so forth." Unfortunately, there was silence from the Debian Bio proponents after this answer.

Of course, it sometimes turns out that you start working on a project thinking you know what it is about, only to find out later that you really had no idea what it would become until the user base has grown beyond the small community of developers that started it. So, none of the decisions you make about your project's scope at the beginning should be taken as set in stone. On the other hand, it is your project, and if you see it veering off in directions that are contrary to your vision for it, by all means steer it back on course.

Using tasksel and metapackages

According to the plan of the project, the first metapackages () should be developed. It is not always easy to decide what should be included, and which metapackages should be built. The best way to decide on this point is to discuss on the mailing list some well thought out proposals.

Section mentions tasksel as a tool to select a Debian Pure Blend, and explains why it is currently not possible to get a Blend included into the task selection list.

First release Release announcement

Beyond the release announcement for Debian itself, it is necessary to put some thought and work into a release announcement for the first release of a Debian Pure Blend. This will not only be directed at the Debian developer community, but also at the users. This will include potential new Debian users abroad, who may not be on a Debian mailing list. Here, the same principle applies as for the first announcement of the project: it is important to consider sending the information to other relevant forums.

Users of a Debian Pure Blend

By this time, people have newly installed Debian along with the material in the Blend, or have installed the metapackages on their existing Debian systems. Now comes the fun part, building relationships with the user community.

Devoting resources to the users

Users are a mixed blessing. In the first development phase there are some developers who are users, and some intrepid "early adopters." But once it is released, the first version is "out there," and the project will certainly attract all kinds of users who are not necessarily as technically savvy as your small development user community. Be prepared to spend some time with them. Be patient with them. And be listening carefully for the underlying questions beneath the surface questions. As draining as it can be to deal with users, they are a very key component to keeping your development effort vital.

Developer vs. user mailing list

Should a user list be created? It's not as cut-and-dried as it might at first appear. When user help requests start coming in, you might at first see them as a distraction from the development effort. However, you don't necessarily want to "ghettoize" the user community into a separate list early. That's a recipe for developers to get out of touch very quickly with the users. Tolerate the new user questions on the developer list for a while. Once a user list is finally set up, courteously redirect user questions to the user list. Treat your users as the valuable resource about how your project is working "in the field" that they are.

User support beyond Debian

Fortunately, we're not in the business of supporting users alone. Look beyond Debian for your allies in user support: Linux user groups (LUGs) and the users themselves. Develop an awareness of who has stakes in seeing your project succeed, and enlist their help in getting a strong network of support established for your work.

blends-0.6.16.4ubuntu2/doc/en/06_technology.sgml0000644000000000000000000010356512147323454016162 0ustar Technology Metapackages Metapackage definition

A metapackage, as used by Blends, is a Debian package that contains: Dependencies on other Debian packages (essential) Depends

Use "Depends" for packages that are definitely needed for all basic stuff of the Blend in question.

Recommends The packages that are listed as "Recommends" in the tasks file should be installed on the machine where the metapackage is installed and which are needed to work on a specific task. Suggests Use "Suggests" for others of lesser importance that might be possibly useful, or non-free packages. When a package is not available for the target distribution at metapackage build time the "Recommends" is turned into a "Suggests" to enable a flawless installation of the metapackage. Menu entries (recommended) Place these in /etc/blends/<blend>/menu/<pkg-name> Maintain these via role based tools Configuration stuff (optional) debconf questions or pre-seeding cfengine scripts (or similar see ) Special metapackages: <blend>-tasks: Contains information for tasksel <blend>-config: Special configurations, basic stuff for user menus

Metapackages are small packages with nearly no contents. The main feature of this type of package is its dependencies on other packages. The naming of metapackages follows the pattern <blend>-<task> where <blend> stands for the short name of a Debian Pure Blend, e.g. junior for Debian Jr. or med for Debian Med, and <task> means the certain task inside the Blend, e.g. puzzle or bio.

Examples: junior-puzzle Debian Jr. Puzzles education-tasks Tasksel files for SkoleLinux systems med-bio Debian Med micro-biology packages

Collection of specific software

When using metapackages, no research for available software inside Debian is necessary. It would not be acceptable for normal users to have to browse the descriptions of the whole list of the 20000 packages in Debian to find everything they need. So, metapackages are an easy method to help users to find the packages that are interesting for their work quickly.

If the author of a metapackage includes several packages with similar functionality, an easy comparison between software covering the same task is possible.

By defining conflicts with some other packages inside the metapackage, it is possible to ensure that a package that might conflict for some reasons for the intended task can not be installed at the same time as the metapackage is installed.

All in all, metapackages enable an easy installation from scratch, and keep the effort required for administration low.

Packages showing up in more than one metapackage

This seems to be an FAQ: If a package A is in the list of dependencies of metapackage m is it allowed or reasonable to add it to the list of dependencies of metapackage n?

The answer is: Why not?

The "overlap" is no problem because we do not want to build an exclusive categorisation which might be hard to understand for our users. Metapackages are like "normal" packages: Nobody would assume that because package x depends from package libc no other package is allowed to add libc to its depends. So why not adding a dependency to more than one metapackage if it is just useful for a certain task?

The important thing is to support our users. A specific user wants to solve a certain task (and thus installs a certain metapackage). The question whether some Dependencies are also mentioned in a different metapackage is completely useless for this task. So in fact we do not build a categorisation tree but build pools of useful software for certain tasks which can definitely have overlaps.

To give a certain example which was asked by a member of Debian Multimedia team: A user who is seeking for his optimal sound player is not served best if we "hide" an application from his view by including it into sound recorders exclusively. While chances might be good that a sound recorder is not as lightweight as a pure player the user will find out this quickly if he is looking for only a lightweight player - but perhaps he becomes happy later about the "added value" of his favourite player if it also is able to record sound.

Adapted configuration inside metapackages

Besides the simplification of installing relevant packages by dependencies inside metapackages, these packages might contain special configuration for the intended task. This might either be accomplished by pre-seeding debconf questions, or by modifying configuration files in a postinst script. It has to be ensured that no changes that have been done manually by the administrator will be changed by this procedure. So to speak, the postinst script takes over the role of a local administrator.

Documentation packages

A "traditional" weakness of Free Software projects is missing documentation. To fix this, Debian Pure Blends try to provide relevant documentation to help users to solve their problems. This can be done by building *-doc packages of existing documentation, and by writing extra documentation, like manpages, etc. By supplying documentation, Debian Pure Blends fulfil their role in addressing the needs of specialised users, who have a great need for good documentation in their native language.

Thus, translation is a very important thing to make programs more useful for the target user group. Debian has established a , which has the goal to translate package descriptions. There is a good chance this system could also be used for other types of documentation, which might be a great help for Debian Pure Blends.

Handling of metapackages

In short, there are no special tools available to handle metapackages nicely. But there are some tricks that might help, for the moment.

Command line tools

apt-cache The program apt-cache is useful to search for relevant keywords in package descriptions. With it, you could search for a certain keyword connected to your topic (for instance "med") and combine it reasonably with grep: ~> apt-cache search med | grep '^med-' med-bio - Debian Med micro-biology packages med-bio-dev - Debian Med micro-biology development packages med-doc - Debian Med documentation packages med-imaging - Debian Med imaging packages med-imaging-dev - Debian Med packages for medical image develop... med-tools - Debian Med several tools med-common - Debian Med Project common package med-cms - Debian Med content management systems This is not really straightforward, and absolutely unacceptable for end users. grep-dctrl The program grep-dctrl is a grep for Debian package information, which is helpful for extracting specific package details matching certain patterns: ~> grep-dctrl ': med-' /var/lib/dpkg/available | \ grep -v '^[SIMAVF]' | \ grep -v '^Pri' Package: med-imaging Depends: paul, ctsim, ctn, minc-tools, medcon, xmedcon, med-common Description: Debian Med imaging packages Package: med-bio Depends: bioperl, blast2, bugsx, fastdnaml, fastlink, garlic... Description: Debian Med micro-biology packages Package: med-common Depends: adduser, debconf (>= 0.5), menu Description: Debian Med Project common package Package: med-tools Depends: mencal, med-common Description: Debian Med several tools Package: med-doc Depends: doc-linux-html | doc-linux-text, resmed-doc, med-co... Description: Debian Med documentation packages Package: med-cms Depends: zope-zms Description: Debian Med content management systems Package: med-imaging-dev Depends: libgtkimreg-dev, ctn-dev, libminc0-dev, libmdc2-dev... Description: Debian Med packages for medical image development Package: med-bio-contrib Depends: clustalw | clustalw-mpi, clustalx, molphy, phylip, ... Description: Debian Med micro-biology packages (contrib and ... This is, like the apt-cache example, also a bit cryptic, and again is not acceptable for end users. auto-apt The program auto-apt is really cool if you are running a computer that was installed from scratch in a hurry, and are sitting at a tradeshow booth preparing to do a demo. If you had no time to figure out which packages you needed for the demo were missing so you could install all of them in advance, you could use auto-apt in the following manner to guarantee that you have all of the files or programs you need: ~> sudo auto-apt update put: 880730 files, 1074158 entries put: 903018 files, 1101981 entries ~> auto-apt -x -y run Entering auto-apt mode: /bin/bash Exit the command to leave auto-apt mode. bash-2.05b$ less /usr/share/doc/med-bio/copyright Reading Package Lists... Done Building Dependency Tree... Done The following extra packages will be installed: bugsx fastlink readseq The following NEW packages will be installed: bugsx fastlink med-bio readseq 0 packages upgraded, 4 newly installed, 0 to remove and 183 ... Need to get 0B/1263kB of archives. After unpacking 2008kB wi... Reading changelogs... Done Selecting previously deselected package bugsx. (Reading database ... 133094 files and directories currently... Unpacking bugsx (from .../b/bugsx/bugsx_1.08-6_i386.deb) ... Selecting previously deselected package fastlink. Unpacking fastlink (from .../fastlink_4.1P-fix81-2_i386.deb) ... Selecting previously deselected package med-bio. Unpacking med-bio (from .../med-bio_0.4-1_all.deb) ... Setting up bugsx (1.08-6) ... Setting up fastlink (4.1P-fix81-2) ... Setting up med-bio (0.4-1) ... localepurge: checking for new locale files ... localepurge: processing locale files ... localepurge: processing man pages ... This package is Copyright 2002 by Andreas Tille <tille@debian.org> This software is licensed under the GPL. On Debian systems, the GPL can be found at /usr/share/common-... /usr/share/doc/med-bio/copyright Just do your normal business - in the above example, less /usr/share/doc/med-bio/copyright - and if the necessary package is not yet installed, auto-apt will care for the installation and proceed with your command. While this is really cool, this is not really intended for a production machine. The short conclusion here is: There are no sophisticated tools that might be helpful to handle metapackages as they are used in Debian Pure Blends - just some hacks using the powerful tools inside Debian.

Text user interfaces

tasksel

The Debian task installer Tasksel is the first interface for package selection that is presented to the user when installing a new computer. The End-user section should contain an entry for each Debian Pure Blend. Unfortunately, there are some issues that prevent Blends from being included in the tasksel list, because the dependencies of this task can affect what appears on the first installation CD. This problem would be even greater if all Blends were added, and so a different solution has to be found here. (See .) In principle, tasksel is a good tool for easy installation of Blends.

As a workaround for this problem the blends-dev framework creates a package BLEND-tasks which contains a tasksel control file. If you install this package all tasks of the Blend will be added to the default list of tasks inside tasksel. So a solution for Blend specific installation media might be to just remove the default tasksel list and provide the Blends own tasks exclusively.

aptitude This is a better replacement for dselect, and has some useful support for searching for and grouping of packages. While this is not bad, it was not intended for the purpose of handling Debian Pure Blends, and thus there could be some better support to handle metapackages more cleverly. Short conclusion: There is a good chance metapackages could be handled nicely by the text based Debian package administration tools, but this is not yet implemented.

Graphical user interfaces

Debian Woody does not contain a really nice graphical user interface for the Debian package management system. But the efforts to support users with an easy to use tool have increased, and so there there will be some usable options in Sarge. gnome-apt This is the native GNOME flavour of graphical user interfaces to apt. It has a nice Search feature that can be found in the Package menu section. If for instance the packages of the Debian Jr. project come into the focus of interest a search for "junior-*" will show up all related packages including their descriptions. This will give a reasonable overview about metapackages of the project. synaptic Even more sophisticated and perhaps the best choice for users of Debian Pure Blends. Synaptic has a nice filter feature, which makes it a great tool here. Moreover synaptic is currently the only user interface that supports Debian Package Tags (see ). kpackage This is the user interface of choice for KDE lovers. Regarding its features (with exception of Debian Package Tags) it is similar to both above. Short conclusion: As well as the text based user interfaces these tools are quite usable but need enhancements to be regarded as powerful tools for Debian Pure Blends.

Web interfaces

Tasks pages

The tasks pages probably provide the best overview about the actual work which is done in a Debian Pure Blend. These pages are automatically generated by reading the tasks files (see ) and verifying the existence of the packages that are mentioned as dependencies. On the resulting web page the packages are listed with some meta information and the description of the package. As user oriented pages they are translated into more than 10 languages while translated means, the navigation text of the page generating code is using gettext which enables translation (the work is not yet completely done for all languages) but even more importantly the descriptions of the packages are translated as well by using the information from .

These tasks pages are available via http://blends.alioth.debian.org/BLEND/tasks where BLEND has to be replaced by the name of the Blend. Currently these pages are available for the Blends: accessibility, edu, gis, junior, lex, science, debichem The tasks pages are available for Debian Med as well but for historical reasons the URL for these pages is http://debian-med.alioth.debian.org/tasks In short: If you want to know more about a specific Blend go to its task page and have a look what is listed there.

Bugs pages

The more developer oriented bugs pages try to match the scope of the tasks pages mentioned above but there is no description of the packages given but rather the bugs that are reported in the Debian Bug Tracking System (BTS) are listed there. This is a quite valuable source of information if somebody is interested in increasing the quality of a Blend: Fixing bugs is always welcome and listing all relevant bugs at a single place is a nice way to detect problems quickly.

These bugs pages are available via http://blends.alioth.debian.org/BLEND/bugs where BLEND has to be replaced by the name of the Blend. Currently these pages are available for the Blends: accessibility, edu, gis, junior, lex, science, debichem The bugs pages are available for Debian Med as well but for historical reasons the URL for these pages is http://debian-med.alioth.debian.org/bugs In short: If you want to help enhancing the quality of a specific Blend go to its bug page and start working on the bugs listed there.

Debian has a web interface that can be used to search for certain substrings in package names. For instance if you are searching the meta packages of Debian Med you could point your favourite Browser to

FIXME: & is sometimes broken!!! ^^^^^

As a result you will get a list of all Debian Med packages.

The Package Tracking System is a really great tool that provides essential information about packages. Most Debian Pure Blends are using a mailing list address as Maintainer of their key packages which includes the metapackages. This so called team maintenance of packages is on one hand very handy from a developers point of view on the other hand it enables using the Package Tracking System to get a quick overview: Debian Jr: Debian Med: Debian Edu: Debian Science: Hint: If you append the option &ordering=3 you might get some sectioning of this page according to the metapackage categories. This result is approached by a tool which subscribes all dependent packages to the group maintenance address and adds a section according to a metapackage name.

The other way to use the Package Tracking System is to search for packages starting with a certain letter: Debian Jr: Debian Med: But the list that is obtained by this method is much larger than it would be useful for a good overview.

list-junior.sh The package junior-doc contains a script /usr/share/doc/junior-doc/examples/scripts/list-junior.sh that checks for the installed packages of a Blend and builds a simple web page describing these packages. (The BTS contains a patch to let this script work also for other Blends.) Short conclusion: The Debian Pure Blends provide some nice web tools for a whole set of packages for a certain working field that provide a better overview than the usual Debian tools that are basically dealing with single packages..

Future handling of metapackages

Obviously there are no nifty tools as you might know them from Debian available yet. The user interfaces for apt-get have to be enhanced drastically to make them easy enough to make them useful in the hands of an end user. This might implicitly mean that we need some additional control fields in dpkg to implement reasonable functionality. The following items are target of future development: Searching for existing metapackages Overview about dependencies of these metapackages Enhancing tools like aptitude, synaptic, etc. Special tasksel section Web tools that keep metapackage information up to date

Furthermore it is necessary to find a set of keywords for each Debian Pure Blend and write a tool to search these keywords comfortable. The best way to accomplish this might be to make use of Debian Package Tags, which is a quite promising technique.

Tools that grep the apt cache directly for metapackages have to be written or rather the available tools for this should be patched for this actual functionality.

User roles

As stated above specialists have only interest in a subset of the available software on the system they are using. In an ideal world, this would be the only software that is presented in the menu. This would allow the user to concentrate on his real world tasks instead of browsing large menu trees with entries he does not understand.

To accomplish this, a technique has to be implemented that allows to define a set of users who get a task-specific menu while getting rid of the part of software they are not interested in. Moreover this has to be implemented for certain groups of users of one Blend, which are called "roles". There are several techniques available to manage user roles. Currently in the field of Debian Pure Blends a UNIX group based role system is implemented. This means, that a user who belongs to a certain group of a Blend is mentioned in the /etc/group file in the appropriate group and gets a special user menu that is provided for exactly this group.

Strictly speaking it is not the best solution to conflate a configuration mechanism, which users see with menus, with access control, i.e. unix groups. It might be confusing, and wastes the limited number of groups to which a user can belong. On the other hand this is a solution that works for the moment, and has no real negative impact on the general use of the system. The benefit of using unix groups is that there is a defined set of tools provided to handle user groups. This makes life much easier; there is no practical limit to the number of groups to which a user may belong for the existing Debian Pure Blends at this time.

In the long run, this role system might even be enhanced to certain "levels" a user can have and here the UNIX groups approach will definitely fail and has to be replaced by other mechanisms. This will include the possibility to enable the user adjust his own level ("novice", "intermediate", "expert") while only the administrator is able to access the UNIX groups. On the other hand such kind of user level maintenance is not only a topic for Debian Pure Blends but might be interesting for Debian in general.

Another point that speaks against using UNIX groups for role administration is the fact that local administrators are not in all cases competent enough to understand the UNIX role concept as a security feature and thus a real role concept including tools to maintain roles are needed in the future.

The handling of the user menus according to the groups is implemented in a flexible plugin system and other ways of handling groups (i.e. LDAP) should be easy to implement.

User menu tools Using the Debian menu system

The Debian menu system cares for menu updates after each package installation. To enable compliance with the role based menu approach it is necessary to rebuild the user menu after each package installation or after adding new users to the intended role. This can be done by using the (see ) script from blends-common. It has to be said that using blend-update-menus is not enough to change the menu of a user. To accomplish this a call of the general update-menu script for every single user of a Blend is necessary if this is not done by the postinst script of a metapackage. This can easily been done if the configuration file of a Debian Pure Blend /etc/blends/<blend>/<blend>.conf contains the line UPDATEUSERMENU=yes

It is strongly suggested to use the package blends-dev to build metapackages of a Debian Pure Blend that will move all necessary files right into place if there exists a menu directory with the menu entries. Note, that the users ${HOME}/.menu directory remains untouched.

Managing Debian Pure Blend users with debconf

Using blends-dev it is very easy to build a blend-config package that contains debconf scripts to configure system users who should belong to the group of users of the Debian Pure Blend blend. For example see the med-common package. ~> dpkg-reconfigure med-common Configuring med-common ---------------------- Here is a list of all normal users of the system. Now you can select those users who should get a Debian Med user menu. 1. auser (normal user A) 6. fmeduser (med user F) 2. bmeduser (med user B) 7. glexuser (lex user G) 3. cjruser (jr user C) 8. hmeduser (med user H) 4. djruser (jr user D) 9. iadmin (administrator I) 5. eadmin (administrator E) 10. juser (normal user J) (Enter the items you want to select, separated by spaces.) :-! Please specify the Debian Med users! 2 8 This example shows the situation when you dpkg-reconfigure med-common if med user B and med user H were defined as users of Debian Med previously and med user F should be added to the group of medical staff. (For sure it is more convenient to use the more comfortable interfaces to debconf but the used SGML DTD .)

Development tools

Building a metapackage is more or less equal for each meta package. This was the reason to build a common source package blend that builds into two binary packages blends-dev

Helpful tools to build metapackages from a set of template files. These tools are interesting for people who want to build metapackages in the style Debian Edu and Debian Med are currently doing this. The purpose of this package is to make maintenance of metapackages as easy as possible.

This package is described in detail in appendix .

blends-common

This package provides some files that are common to meta packages of Debian Pure Blends especially those that were built using the tools of the package blends-dev. It introduces a method to handle system users in a group named according to the name of the Blend. The user menu approach is explained in detail in .

This package is described in detail in appendix .

 The usage of the tools that are contained in these packages are described now in detail.

Other interesting tools Simple-CDD

The tool simple-cdd is a limited though relatively easy tool to create a customized debian-installer CD.

It includes simple mechanisms to create "profiles" that define common system configurations, which can be selected during system installation. Simple-cdd also makes it easy to build CDs with language and country settings pre-configured, or to use a 2.6 kernel by default.

This can be used to create a crude "Debian Pure Blend" using packages from Debian, with pre-configuration of packages that use debconf. Custom configuration scripts can be specified to handle packages that don't support debconf pre-configuration.

Testing CD images with qemu is also made simple with a provided script.

It has only been tested with debian-cd from Etch (other than debpartial-mirror), so if using a new debian-cd or debian-installer, it may require some tweaks.

blends-0.6.16.4ubuntu2/doc/en/A_devel.sgml0000644000000000000000000005202612147323454015034 0ustar Description of development tools Package blends-dev

If metapackages are builded using the tools inside the blends-dev package it can be ensured that the resulting metapackages will work nicely with the same version of blends-common package. The goal is to keep necessary changes for the source of the metapackages of a Debian Pure Blend as low as possible when the version of the blends source package changes. Thus it is strongly recommended to use the tools described below.

The usage of the tools in the blends-dev package might introduce a versioned dependency in the <blend>-config package from which all other metapackages of the Blend in question will depend. This <blend>-config package instantiates the Blend in the common registry for all Blends in /etc/blends.

The best idea to use the tools provided by the blends-dev is to put a Makefile into the build directory containig one single line include /usr/share/blends-dev/Makefile (see /usr/share/doc/blends-dev/examples/Makefile). Using this Makefile all tools that were contained in blends-dev package versions before 0.4. These tools are moved to /usr/share/blends-dev/ because there is no need to call them directly. Here is a list of the make targets.

Blend-tasks.desk

This target is the description file that is used in tasksel to enable selecting the tasks belonging to the Blend. The file will be moved to the blend-tasks. All information is obtained from the single task files in the tasks directory of the Blend source.

debian/control

The debian/control file of a Blend metapackage source archive is auto generated out of dependencies that are specified in so called tasks files. The rationale behind this is to enhance flexibility about changes inside the Debian package pool where new packages might appear and others might be renamed. The tasks just define which dependencies the Blend maintainer group wants to be fulfilled and the script blend-gen-control verifies whether these dependencies exist in the specified package pool and create the debian/control file according to the available packages. This does not only work for the Debian package pool containing the distributions stable, testing and unstable. You can even build your metapackages against a different package pool of a Debian based distribution. This is for instance used to create the SkoleLinux metapackages.

The syntax of the tasks files which serve as the central database for the information in the debian/control file is defined by RFC822. Some of the tags were mentioned formerly in to explain how the tasks files can be used to create the web sentinel pages. Now the tags that influence the creation of the debian/control file are given.

Depends Will be turned to "Recommends" in the resulting debian/control file. The rationale behind this is to enable installing the metapackage even if a package belonging to this task is missing for whatever reason. It also allows finally to remove the metapackage. This makes even more sense since apt-get considers "Recommends" as default installation targets. Recommends The packages that are listed as "Recommends" in the tasks file should be installed on the machine where the metapackage is installed and which are needed to work on a specific task. Suggests

Use "Suggests" for packages of lesser importance that might be possibly useful, or non-free packages.

If a package is not available in the package pool of the target distribution when creating the debian/control file inside the meta package source archive any "Depends" or "Recommends" are turned into "Suggests" to enable a flawless installation of the metapackage. Packages that are specified with "Suggests" will not be taken over to the tasksel control file (Blend-tasks.desk, see ) but only to the list of suggested packages of the according metapackage. Ignore The "Ignore" key can be used as kind of "Soft-Suggests" to put a package on the radar of the Blend. Packages that are tagged with Ignore will not be taken over into the list of dependencies inside the debian/control file of the resulting metapackage neither to the Blend-tasks.desk control file for tasksel but will be taken over onto the installation medium of a Blend in case there is some space left. This key becomes especially important for specifying not yet packaged software that might be packaged in the future (prospective packages). This is explained in detail in the paragraph about the web sentinel (see ). Avoids The "Avoids" key specifies existing packages that will be listed in the the debian/control file as "Recommends" or "Suggests" but, should not go to a installation medium (CD, DVD, etc.) that might be produced by the Blend. A reason to avoid a package might be that it belongs to the non-free section.

Apt sources.list files in /etc/blends/

These files are used by to build valid debian/control files that contain only available packages in their dependencies. This enables building meta packages for stable, testing, unstable or even a completely different distribution that has valid sources.list entries. The file /etc/blends/control.list is used as default for and usually is a symbolic link (see ) to sources.list.distribution. It might be changed using the -s dist option of .

TODO: Either parse the available /etc/apt/sources.list or use a sane debconf question to use the "nearest" mirror.

Templates in /usr/share/blends/templates

The directory /usr/share/blends/templates contains templates that can be used to build a <blend>-config, which uses the tools that are contained in the blends-common package, and are useful to manage <blend> user groups (see ).

Package blends-common

This package creates a common registry for all Blends in /etc/blends. Each Blend should put the files that are used into a subdirectory named like the Blend of /etc/blends. The blends-common package installs a common configuration file /etc/blends/blends.conf, which can be used to influence the behaviour of the tools described below.

blend-role(8)

NAME blend-role - add/remove roles in registered Debian Pure Blend SYNOPSIS blend-role add|del Blend [Role] DESCRIPTION Add/remove (register/unregister) Role for the specified Blend. If Role is not specified, it's assumed to be named like Blend. OPTIONS Blend A registered Blend in /etc/blends, for example one of med, junior, edu or science AUTHOR Andreas Tille tille@debian.org, Cosimo Alfarano kalfa@debian.org.

blend-update-menus(8)

NAME blend-update-menus - add menu of metapackage to all Blend users SYNOPSIS blend-update-menus [--blend Blend | --user user] DESCRIPTION

blend-update-menus behaves differently depending on who run the command:

If it is called by a user, it adds, and keeps updated, menu entries for the user who runs it.

If it is called by root, it adds and keeps updated user's menu entries (see menu package for users' menus) for all users who belong to the group of the specified Blend, or only for a specified user, depending on which parameter is passed to the script.

OPTIONS Blend one of the installed Blends, listed in /etc/blends/, for example (if installed: med, junior, edu or science. user system user AUTHOR Andreas Tille tille@debian.org, Cosimo Alfarano kalfa@debian.org.

blend-user(8)

NAME blend-user - add/remove user to Role of a registered Blend SYNOPSIS blend-user add|del Blend user [Role] DESCRIPTION Add/remove user to a Role of the specified Blend. If Role is not specified, it's assumed to be named like Blend OPTIONS Blend A registered Blend in /etc/blends, for example one of med, junior, edu or science. user user to add Role the role in the Blend that user will assume AUTHOR Andreas Tille tille@debian.org, Cosimo Alfarano kalfa@debian.org.

blends.conf(5)

NAME blends.conf - configuration for Debian Pure Blends registry DESCRIPTION This file is sourced from shell scripts inside the Debian Pure Blends package blends-common and thus it has to follow shell syntax. The variables that are set inside this configuration file can be overriden by special Blend configration files /etc/blends/<>Blend>/<>Blend>.conf for each single Blend. SYNTAX The following variables can be set: DBBACKEND Set the backend for the user role management system. Currently the only implemented role management system is unixgroups but others might be implemented later. Unsetting this variable leads to use no roles at all. UPDATEUSERMENU If this is set to yes, the user menus of meta packages can be created automatically at install time of the package if the postinst script of the package allows this. It is suggested to use this option in the specific configuration files of a special Debian Pure Blend that override the settings of the general configuration file. SHAREDIR Set the base directory for the user role management system. While this is more or less a feature for debugging this might be also used otherwise. DRYRUN This variable can be set for debugging. Normally it should be left unset (NOT set to false or anything else!). If set to true a dry run of the tools is performed or echo DRYRUN: would print debugging information. DEBUG If set to 1 debugging mode is switched on. SEE ALSO blend-role (8), blend-update-menus (8), blend-user (8) AUTHOR Andreas Tille tille@debian.org, Cosimo Alfarano kalfa@debian.org.

Working with the source repository (svn in process of moving to git)

Sometimes it might be interesting for developers to check out the latest code of the Blend tools or a special Blend code for the meta packages. In the directory layout of the svn-directory was described. How to derive the Debian packages from this layout? Checkout For the Blend tools and this documentation git clone git+ssh://username@git.debian.org/git/blends/blends.git or for the Debian Pure Blend BLEND-name svn checkout svn+ssh://username@svn.debian.org/svn/blends/projects/BLEND-name/trunk Note: This will be moved to Git (at least) soon after Wheezy release. Build source package Change into the created directory and type make -f debian/rules get-orig-source This creates a tar.gz source archive of the packages you want to build. For your personal comfort you can create a file Makefile in your package source directory containing #!/usr/bin/make -f include /usr/share/blends-dev/Makefile Which enables you to simply say make dist to create the source tarball. Build Debian packages Unpack the created source tarball and proceed like you build Debian packages normally.

The current Debian Med packages provide a working example how to use the tools described below.

How to create tasks and bugs pages of web sentinel

In the creation of so called tasks pages and bugs pages was described. These pages are automatically build by a cron job on Alioth from the current state of the tasks files in the SVN repository. If you have commited changes to the tasks pages and want to see the effect immediately the steps to do are as follows:

Login to alioth.debian.org cd /var/lib/gforge/chroot/home/groups/blends/webtools/ ./tasks.py <blend-name>

To know what a valid <blend-name> might be have a look into /var/lib/gforge/chroot/home/groups/blends/webtools/webconf. Each Blend has an according config file there. Leave out the .conf extension and you have a valid <blend-name>.

In case you are planing some more experimental changes there is another host which was kindly sponsored by Frédéric Hébert for Debian Med called blends.debian.net which is running a copy of UDD and also hosts the latest development snapshot of the Blends web tools. Just ask Andreas Tille tille@debian.org in case you like a login on this host.

The code which builds web and tasks pages is available in Git at git://git.debian.org/git/blends/website.git. It is using the which enables influencing the layout of the pages by editing the templates in the templates directory. You can also influence some parameters of the web pages in the configuration files in the webconf directory. Last but not least you can provide translations for the web pages in the po directory.

Once something on the web pages was changed you can activate the changes as follows:

Login to alioth.debian.org or blends.debian.net cd /var/lib/gforge/chroot/home/groups/blends/webtools/ ./deploy-dynamic-pages

Please note that the css and js files which are influencing the layout of the automatically created pages are in the same area as the static web pages (see below ).

Editing static web pages of Blends on Alioth

A very simple entry page is created for each Blend which is linked from the . Most probably the maintainers of a Blend want to enhance this page a bit. It is actually intended that this simple template will be enhanced as it is done for instance for the which has a quite complex PHP driven web with a lot of other features than just linking to the tasks and bugs pages. Maintainers of a Blend should care for this index page which currently is just featuring links to the automatically updated pages as well as an image which shows the activity of the . Maintaining these static pages is not a "service" which is done for you. The maintainers of a Blend should care for this!

The static pages are maintained in Git at git://git.debian.org/git/blends/website.git in the websites directory. Once you have changed the content of the pages you can activate the changes by doing:

Login to alioth.debian.org or blends.debian.net cd /var/lib/gforge/chroot/home/groups/blends/webtools/ git pull

blends-0.6.16.4ubuntu2/doc/en/05_inside.sgml0000644000000000000000000002567412147323454015265 0ustar Distributions inside Debian To fork or not to fork

There are many distributions that decided to fork from a certain state of Debian. This is perfectly all right because Debian is completely free and everybody is allowed to do this. People who built those derived distributions had certain reasons to proceed this way.

Commercial forks

If Debian should be used as the base for a commercial distribution like (formerly Lindows), or , there is no other choice than forking because these companies normally add some stuff that is non-free. While Debian Pure Blends might be interesting in technical terms for those commercial distributions by making it easier to build a separate distribution, these non-free additions are not allowed to be integrated into Debian, and thus integration into Debian is impossible.

Non-commercial forks

As a completely free distribution Debian GNU/Linux is quite often a welcome starting point for derived distributions with a certain purpose that are as free as Debian but had certain reasons to fork. One main reason for a fork was that Debian was not flexible enough for certain purposes and some needed features had to be added. One reason for the Debian Pure Blends effort is to increase flexibility and to make the reason mentioned above void (if it is not yet void because of the general develoment of Debian). Some examples of forks from Debian that are probably now able to integrate back into Debian as a Debian Pure Blend are: Mentioning SkoleLinux in the category of forks is more or less history. The merge back into Debian started with the SkoleLinux people really doing a great job to enhance Debian for their own purposes in the form of their work on debian-installer, and culminated with the formal merging of the Blend Debian Edu and SkoleLinux, so that they are now virtually equivalent. This is the recommended way for derived distributions, and the reasons for this recommendation are given below. DeMuDi The project, which is founded by the European Community, (and in fact is the first Free Software project that was founded by the EU at all,) forked for the following reasons: Technical They had some special requirements for the kernel and configuration. This is more or less solved in the upcoming Debian release. License When DeMuDi started, not enough free programs in this field existed. This situation is better now. Organisational Because of the founded status of the project, an extra distribution had to be developed. To accomplish this requirement, Debian Pure Blends plan to build common tools to facilitate building separate CDs with the contents of only a single distribution. This shows that there is no longer a real need for a fork, and in fact, the organiser of the DeMuDi project was in contact to start bringing DeMuDi back into Debian. That is why DeMuDi is mentioned in the list of Debian Pure Blends above. Unfortunately the effort to merge back has stalled but it might be an interesting project to apply Blends techniques to support multimedia experts who want to use Debian. LinEx LinEx is the very successful distribution for schools in the Region Extremadura in Spain. The work of the LinEx people perhaps made Debian more popular than any other distribution. The project was founded by the local government of Extremadura, and each school in this region is running this distribution. While this is a great success, the further development of LinEx has to face the problems that will be explained below. Because the creators of LinEx are aware of this fact they started joining the educational part of LinEx with Debian Edu which in turn leaded to an even stronger position of this Blend.

If developers of a non-commercial fork consider integrating back into Debian in the form of a Debian Pure Blend, it might happen that their field is covered already by an existing Blend. For instance, this would be the case for LinEx, which has the same group of target users as Debian Edu as explained above. On the other hand, some special adaptations might be necessary to fit the requirements of the local educational system. The specific changes that might be necessary would be called flavours of a Blend.

Disadvantages of separate distribution

In general, a separate distribution costs extra effort. Because it is hardly possible to hire enough developers who can double the great work of many volunteer Debian developers, this would be a bad idea for economical reasons. These people would have to deal with continuous changes to keep the base system, installer, etc. up to date with the current Debian development. It would be more sane to send patches that address their special requirements to Debian instead of maintaining a complete Debian tree containing these patches.

Debian is well known for its strong focus on security. Security is mainly based on manpower and knowledge. So the best way to deal with security issues would be to base it on the Debian infrastructure, instead of inventing something new.

New projects with special intentions often have trouble to become popular to the user group they want to address. This is a matter of attaining the critical mass that was explained in .

Larger Free Software projects need certain infrastructure like web servers, ftp servers, (both with mirrors,) a bug tracking system, etc. It takes a fair amount of extra effort to build an entire infrastructure that is already available for free in Debian.

Forking would be a bad idea.

Advantages of integration into Debian

Debian has a huge user base all over the world. Any project that is integrated within Debian has a good chance to become popular on the back of Debian if the target users of the project just notice that it enables them to solve their problems. So there is no need for extra research on the side of the users, and no need for advertising for a special distribution. This fact has been observed in the Debian Med project, which is well known for many people in medical care. It would not have gained this popularity if it had been separated from Debian.

You get a secure and stable system without extra effort for free.

Debian offers a sophisticated Bug Tracking System for free, which is a really important resource for development.

There is a solid infrastructure of web servers, ftp servers with mirrors, mail servers, and an LDAP directory of developers with a strongly woven web of trust (through gpg key signing) for free.

Enhancing Debian

By making changes to some packages to make them fit the needs of a target user group, the overall quality of Debian can be enhanced. In this way, enhancing Debian by making it more user friendly is a good way for the community to give back something to Debian. It would be a shame if somebody would refuse all the advantages to keeping a project inside Debian, and instead would decide to try to cope with the disadvantages because he just does not know how to do it the right way, and that it is normally easy to propogate changes into Debian. For instance, see . This section explains how you can ask for a certain piece of software to be included in Debian. The next section describes the reason why Debian is flexible enough to be adapted to any purpose.

Adaptation to any purpose

Debian is developed by about 1000 volunteers. Within this large group, the developers are encouraged to care for their own interests in packages they have chosen to look after. Thus, Debian is not bound to commercial interests.

Those who might fear this amount of freedom given to every single developer should realize that there are very strict rules, as laid out in , which glue everything together. To keep their packages in each new release, every developer must ensure that their packages abide by that policy.

One common interest each individual developer shares is to make the best operating system for himself. This way, people with similar interests and tasks profit from the work of single developers. If users, in turn, work together with the developers by sending patches or bug reports for further enhancement, Debian can be improved also for special tasks.

For instance, developers may have children, or may work in some special fields of work, and so they try to make the best system for their own needs. For children, they contribute to Debian Jr. or Debian Edu. For their field of work, they contribute to the appropriate Blend: Debian Med, Debian Science, and so forth.

In contrast to employees of companies, every single Debian developer has the freedom and ability to realize his vision. He is not bound to decisions of the management of his company. Commercial distributors have to aim their distributions at gaining a big market share. The commercial possibilities in targeting children's PCs at home are slight, so distributions comparable to Debian Junior are not attractive for commercial distributors to make.

Thus, single developers have influence on development - they just have to do it, which is a very different position compared with employees of a commercial distributor. This is the reason for the flexibility of Debian that makes it adaptable for any purpose. In the Debian world, this kind of community is called "Doocracy" - the one who does, rules.

blends-0.6.16.4ubuntu2/doc/en/09_todo.sgml0000644000000000000000000004547412147323454014763 0ustar To do Establishing and using communication platforms

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 .

Moreover the project on Alioth exists to organise the cooperation of developers. The 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 with subversion changes and a for tracking changes in the Debian Pure Blends projects in real-time.

Enhancing visibility

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 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? Change 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. Debian Pure Blends information screen. 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. Provide separate install CDs 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. Change overall distribution philosophy of Debian. 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 . 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.

Debian Pure Blends web pages

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 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 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.

Enhancing basic technologies regarding Debian Pure Blends

In section 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 from freedesktop.org but it is not even yet packaged for Debian.

Building Live CDs of each Debian Pure Blend

The first step to convince a user to switch to Debian is to show him how it works while leaving his running system untouched. - 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 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.

New way to distribute Debian

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 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: Promotion rules 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 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. Reasonable subsets 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. BTS support The Bug Tracking System has to deal with different package versions or even version ranges to work nicely together with the sub-setting approach. Security 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.

blends-0.6.16.4ubuntu2/doc/en/04_existing_blends.sgml0000644000000000000000000005053712147323454017166 0ustar Existing Debian Pure Blends Debian Junior: Debian for children from 1 to 99

Start beginning of 2000 URL Tasks Mailing list Initiator Ben Armstrong synrg@debian.org Activity Release Debian 3.0 (Woody) Goals To make Debian an OS that children of all ages will want to use, preferring it over the alternatives. To care for those applications in Debian suitable for children, and ensure their quality, to the best of our abilities. To make Debian a playground for children's enjoyment and exploration. The main target is young children. By the time children are teenaged, they should be comfortable with using Debian without any special modifications.

Debian Jr. was the first Blend. In fact, at the time this project was created, the idea behind of Debian Pure Blends was born, although then, we used the term "Debian Internal Project". Over time, this name was changed to "Custom Debian Distributions" first because it was too broad, as it was equally descriptive of a number of quite different projects, such as IPv6 and QA. The next change of names became necessary when it was realised that the term "Custom Debian Distribution" was considered as "something else than Debian" by any newcomer. This was so misleading that it effectively blocked a wide propagation of the principle.

Debian Jr. not only provides games, but is also concerned about their quality from a child's perspective. Thus, games that are regarded as not well suited to young children are omitted. Moreover, choices are made about which packages are best suited for children to use for various other activities and tasks that interest them. This includes, for example, simple text processing, web browsing and drawing.

Debian Med: Debian in Health Care

Start URL Tasks Mailing list Initiator Andreas Tille tille@debian.org Activity

Release Sarge Goals To build an integrated software environment for all medical tasks. To care especially for the quality of program packages in the field of medicine that are already integrated within Debian. To build and include in Debian packages of medical software that are missing in Debian. To care for a general infrastructure for medical users. To make efforts to increase the quality of third party Free Software in the field of medicine. Debian Edu: Debian for Education

Start Summer of 2002, since 2003 merged with SkoleLinux, which is now synonymous with Debian Edu URL Tasks Mailing list Activity Responsible Petter Reinholdtsen pere@hungry.com Release Sarge Goals To make Debian the best distribution available for educational use. Provide a ready to run classroom installation with free educational software. An automatically installed server provides net-boot services for disk-less thin clients and all necessary applications for educational use. To federate many initiatives around education, which are partly based on forks of Debian. To continue the internationalisation efforts of SkoleLinux. To focus on easy installation in schools. To cooperate with other education-related projects (like , , ). This project started with the intention to bring back into Debian a fork from Debian that was started by some people in France. Because they had some time constraints, the people who initially started this effort handed over responsibility to the Norwegian , which is currently more or less identical to Debian Edu.

The Debian Edu project gathered special interest in Spain because there are derived Debian distributions from this country that are intended to be used in schools. For instance there are:

A Debian derivative distribution used in all schools in Extremadura.

Currently they are joining Debian Edu and by doing so becoming fully integrated into Debian. This is a really important move because it brings a lot of good software and experience back into Debian.

Debian Multimedia

Start

In 2004 there was and effort by DeMuDi to become a Blend but this effort seems to have stalled. DeMuDi was part of the project (founded by European Community) and the work somehow was taken over by the 64 studio project.

At DebConf 10 in the a decision was made to use the Blends stuff for rendering web sentinel pages. It was furtherly mentioned that the people driving DeMuDi joined the Debian Multimedia packaging team so there is now an unique effort to tackle multimedia relevant packages.

URL Tasks Activity

Responsible Reinhard Tartlersiretart@tauware.de Goals Oriented toward audio and video To make GNU/Linux a platform of choice for the musician and the multimedia artist. Join multimedia forces inside Debian

Debian GIS: Geographical Information Systems

Start URL Tasks Mailing list Activity Initiator Francesco P. Lovergine frankie@debian.org Goals Geographical Information Systems and GPS devices

DebiChem: Debian for Chemistry

Start October 2004 URL Tasks Mailing list Activity

Initiator Michael Banck mbanck@debian.org Goals Chemical applications in Debian

Debian Science: Debian for science

Start URL Tasks Mailing list Activity

Responsible Sylvestre Ledru sylvestre@debian.org

While there are Debian Pure Blends that care for certain sciences (Debian Med deals in a main part with Biology, DebiChem for Chemistry and Debian GIS for geography) not all sciences are covered by a specific Blend. The main reason is that at the moment not enough people support such an effort for every science. The temporary solution was to build a general Debian Science Blend that makes use of the work of other Blends in case it exists.

Debian Accessibility Project

Debian for blind and visually impaired people Start February 2003 Mailing list URL Tasks Activity Initiator Mario Lang mlang@debian.org Goals To make Debian accessible to people with disabilities. To take special care for: Screen readers; Screen magnification programs; Software speech synthesisers; Speech recognition software; Scanner drivers and OCR software; Specialised software like edbrowse (web-browse in the spirit of line-editors) To make text-mode interfaces available. To provide screen reader functionality during installation.

Blends that were announced but development is stalled Debian Desktop: Debian GNU/Linux for everybody

Motto: "Software that Just Works". Start October 2002 URL Mailing list Initiator Colin Walters walters@debian.org Goals To try to build the best possible operating system for home and corporate workstation use. To ensure desktops like GNOME and KDE coexist well in Debian and work optimally. To balance ease of use for beginners with flexibility for experts. To make the system easy to install and configure (e.g. via hardware-detection). This Blend has many common issues with other Blends. The latest move of Debian Desktop was to care about more up to date software that can be used as common base for all Debian Pure Blends. The common interest is described in detail in . Unfortunately since about 2004 the project is really silent and it might be considered dead now.

Debian Lex: Debian GNU/Linux for Lawyers

Start April 2003 URL Tasks Mailing list Activity Initiator Jeremy Malcolm Jeremy@Malcolm.id.au Goals To build a complete system for all tasks in legal practice. To add value by providing customised templates for lawyers to existing packages like OpenOffice.org and SQL-Ledger, and sample database schemas for PostgreSQL. The word lex is the Latin word for law.

Debian Enterprise

Debian GNU/Linux for Enterprise Computing Start End of 2003 URL Debian Enterprise Initiator Zenaan Harkness zen@iptaustralia.net Goals To apply the UserLinux Manifesto. To establish the benchmark in world class Enterprise operating systems engineered within an industry driven shared-cost development model. To vigorously defend its distinctive trademarks and branding. To develop extensive and professional quality documentation. To provide engineer certification through partner organisations. To certify the Debian Enterprise GNU/Linux operating system to specific industry standards. To pre-configure server tasks

Other possible Debian Pure Blends

There are fields that could be served nicely by not yet existing Blends: Debian eGov Could address government issues, administration, offices of authorities, accounting. Office Could cover all office issues. Accounting Could integrate accounting systems into Debian. Biology Could perhaps take over some stuff from Debian Med. Physics Might look after simulation software. Mathematics There is even already a live CD - see Quantian in ??? There are a lot more potential Blends.

blends-0.6.16.4ubuntu2/doc/en/03_general_ideas.sgml0000644000000000000000000003301612147323454016557 0ustar General ideas Looking beyond

Commercial Linux distributors sell certain products that try to address special user needs. Enterprise solutions Corporate Server - Mandriva Advanced Server - RedHat Enterprise Server - SuSE Small Office and Home Office (SOHO) There are a couple of workstation or home editions, as well as office desktops built by several GNU/Linux distributors. Special task products Mail server SuSE Linux Openexchange Server Firewall Multi Network Firewall - Mandriva, SuSE Firewall on CD, ... Cluster Mandriva Clustering Content Management System RedHat Portal Server RedHat This is only a small set of examples of commercial GNU/Linux distributors addressing specific user interests with certain products.

Debian solves this problem with Debian Pure Blends.

Motivation Profile of target users

The target user of a Blend may be a specialist of a certain profession, (e.g. a doctor or lawyer,) a person who has not (yet) gathered a certain amount of computer knowledge, (e.g. a child,) or a person with disabilities (e.g. a visually or hearing impaired person.) Moreover, the customisation might deal with peculiarities of certain regions where users have needs that differ from Debian as a whole.

It is not unusual for these target users to be less technically competent than the stereotypical Linux user. These people are often not interested in the computer for its own sake, but just want it to work for them. Imagine the frustration of a doctor who has to move the focus of interest from the patient to his stupid computer that does not work as expected.

Because of limited knowledge or time, the target user is usually unable to install upstream programs. This means that in the first place, they must find out which software packages in their distribution might serve for a certain problem. The next step would be to download and install the packages they choose, perhaps requiring a certain amount of configuration effort. This problem is nearly impossible for a user with limited technical competence and perhaps poor English language comprehension, which prevents the user from understanding the installation manual.

The language barrier in this field is an important issue, because we are targeting everyday users who are not compelled to learn English, like Free Software developers are, for everyday communication. So the installation process has to involve the least possible user interaction, and any such interaction has to be internationalised.

Furthermore, most target users have no or little interest in administration of their computer. In short, the optimal situation would be that he would not even notice the existence of the computer, but just focus on using the application to accomplish the task at hand.

Common to all groups of target users is their interest in a defined subset of available Free Software. None of them would like to spend much time searching for the package that fits his interest. Instead, the target user would prefer to immediately and effortlessly locate and access all material relevant to solving his own problems.

There is an absolute need for easy usage of the programs. This is not to say users expect to not have to learn to use the software. Adults generally accept that they must spend a reasonable amount of time in learning how to use a piece of software before they can do something useful and productive with it. But a simple-to-learn environment greatly enhances the value of the software, and if you consider children as target users, they just want to start using it right away without reading any documentation.

The more important part of the request for easy usage is a professional design that is functional and effective. To accomplish this, the programmers need expert knowledge, or at least a quick communication channel to experts to learn more about their requirements. One task for Debian Pure Blends is to bring programmers and experts who will use those special programs together.

Last, but not least, we find certain requirements beyond just which packages are provided in each target user group. These may differ between different Blends. For instance, while a doctor has to protect his database against snooping by outside attackers, the privacy risk for a child's system are of lesser importance. Thus, the Debian Junior project cares more for ensuring that the user himself does not damage the desktop environment while playing around with it than about remote attacks. So we find a "defined security profile" for each single Blend.

Profile of target administrators

In the field that should be covered by Debian Pure Blends, we have to face also some common problems for system administrators. Often they have limited time in which they must serve quite a number of computers, and thus they are happy about each simplification of the administration process. The time required to make special adaptations for the intended purpose has to be reduced to a minimum.

So, administrators are looking for timesaving in repetitive tasks. While this is a common issue for each general GNU/Linux distribution, this could have certain consequences in the special fields Debian Pure Blends want to address.

Another problem administrators face is that they are often not experts in their clients' special field of work. Thus, they may need some specialist knowledge to explain the use of special programs to their users, or at least need to be able to communicate well with the experts about their special needs, and how the software can be used to address them.

Status of specialised Free Software

Programs like a web server, or a mail user agent are used by many different users. That is why many gifted programmers feel obliged for this kind of Free Software - they just need it for their own. So you normally find a fast, growing community around Free Software packages that have a wide use. This is different for specialised software.

In this context, the term "specialised software" refers to the kind of software that is needed by some experts for their job. This might be a practice management system that is used by doctors, a graphical information system (GIS) that is used by geographers, a screen reader that helps blind people to work with the computer, etc. The difference between such software and widely used software like office suites is that the user base is relatively small. This is also true for certain software that supports special localisation issues. Specialist software is used only by a limited set of users (i.e. the specialists). There exists a set of software tools that work perfectly in the environment where they were developed. If the developers catch the idea of Free Software, and just release this software as-is, people in the new, broader user community often run into trouble getting it to work in their environment. This happens because the developers did not really care about a robust installation process that works outside their special environment. As well, installation instructions are often badly written, if they exist at all. But these problem can be easily solved by shipping the software as policy-compliant binary packages, which not only ease installation, but also require documentation to be included. Thus, mere inclusion in Debian benefits the whole user base of any specialised software. The trouble often continues in the maintenance of the installed software. When it comes to the usage of the specialist software, it often happens that it perfectly fits the needs of the developer who wrote it for his own purposes, and who is familiar with its quirks, but in many cases such software does not comply with ergonomic standards of user interfaces. Several existing programs that might be useful for specialists are not really free in the sense of the . Programs that are incompatible with the DFSG cannot be included in Debian. This is possibly a drawback for those programs, because they could profit by spreading widely on the back of Debian over the whole world. A certain number of programs are developed at universities by students or graduates. Once these people leave the university, the programs they developed might be orphaned; i.e., not actively maintained anymore. If their licenses are too restrictive, it may be impossible for anyone else to take over; sticking to AT: We should find a way to avoid printing the URL in PDF output. -free licenses avoids that problem. In special fields, often "typical" (not necessarily Intel-based) hardware architectures are used. Debian currently runs on 11 different architectures, and automatic build servers normally compile software packages as necessary. If auto-builders for other architectures show problems, Debian maintainers will normally fix them, and send the original authors a patch. Moreover, users can report run-time problems via the . Many programs that are written from scratch use their own non-standard file formats. However, it is often important for programs to be able to share data with each other. Often there are several programs that try to solve identical or similar problems. For instance the Debian Med team faces this in the case of programms claiming to serve as a medical practice management solution. Normally, all these programs take very interesting approaches but all of them have certain drawbacks. So, joining programmers' forces might make sense here. Sometimes the tools or back-ends used in Free Software are not appropriate for such applications. For instance, sometimes database servers that do not use transactions are used to store medical records, which is completely unacceptable. Other programs use web clients as their front-end, which is not really good for quick (mouse-less) usage, a great shortcoming for repetitive tasks.

General problem

Free Software development is a kind of evolutionary process. It needs a critical mass of supporters, who are: programmers and users Because specialised software has a limited set of users, (specialists,) this results in a limited set of programmers.

Debian wants to attract both groups to get it working.

Debian is the missing link between upstream developers and users.

Debian Pure Blends from philosophical point of view

Debian currently grows in several directions: Number of involved people Number of packages Number of architectures Number of bugs Number of users Number of derivatives Time span between releases So several features are changing at different rates their quantity. According to Hegel a change of quantity leads into a change in quality. That means that Debian will change at a certain point in time (or over a certain time span) its quality.

"To determine at the right moment the critical point where quantity changes into quality is one of the most important and difficult tasks in all the spheres of knowledge." (Trotzki) This might mean that we just passed the point in time when Debian changed its quality. At one point we even observed a change once the package pool system was implemented to cope with the increased number of packages while trying to reduce the time span between releases. Even if the plan to increase the frequencies of releases failed Debian became a new quality. People started using the testing distribution even in production which was not really intended and in a consequence even security in testing was implemented for Sarge.

According to Darwin evolution happens through quantitative transformations passing into qualitative. So Debian has to evolve and to cope with the inner changes and outer requirements to survive in the Linux distribution environment.

blends-0.6.16.4ubuntu2/doc/en/01_introduction.sgml0000644000000000000000000000562212147323454016516 0ustar Introduction

A general purpose operating system like Debian can be the perfect solution for many different problems. Whether you want Debian to work for you in the classroom, as a games machine, or in the office, each problem area has its own unique needs and requires a different subset of packages tailored in a different way.

Debian Pure Blends provide support for special user interests. They implement a new approach to cover interests of specialised users, who might be children, lawyers, medical staff, visually impaired people, etc. Of late, several Debian Pure Blends have evolved. The common goal of those is to make installation and administration of computers for their target users as easy as possible, and to serve in the role as the missing link between software developers and users well.

To clarify the relation between a Blend and a derivative which is frequently mixed up Ben Armstrong said in a : "While a Blend strives to mainstream with Debian, a derivative strives to differentiate from Debian."

Using the object oriented approach as an analogy, if Debian as a whole is an object, a Debian Pure Blend is an instance of this object that inherits all features while providing certain properties.

So the Debian project releases the Debian Distribution which includes several Blends. In contrast to this, there might be some other Debian related Projects, either external or non-official, which may create "derivative distributions". But these are not the responsibility of the Debian project.

A word of warning: The fact that a Blend covering a certain field of work does exist does not mean that it might be a complete drop in replacement of Free Software solutions for all tasks in this specific field. Some Blends just started to work on this and adopted the technical framework to formalise the work on the project but it might perfectly happen that there is just a lack of available Free Software solutions for certain tasks. Debian can do less about this because we just assemble a set of software which was developed outside the Debian GNU/Linux distribution. So it has to be checked whether a specific Blend is fit for the intended purpose, whether it might cover just some parts of a fields of work or whether it is just a concept to develop some solutions for the future.

blends-0.6.16.4ubuntu2/doc/en/08_websentinel.sgml0000644000000000000000000004127212147323454016324 0ustar The web sentinel Existing and prospective packages

The so called tasks pages probably give the most interesting overview about what a Blend is actually doing for newcomers as well as a nice quality assurance tool for developers. If you want to see examples for tasks pages just have a look at the using this technique and follow the links to the tasks pages once you selected one specific Blend.

If a Debian Pure Blend should be presented one of the first questions is, what packages are available. The next question might be which packages are on the todo list for inclusion in Debian to make Debian even more attractive for people the Blend is targeting at. Both questions can be answered if you point people to the dynamically created tasks page. The page is rebuild daily to stay up to date according to recent developments of the Blend. The build process works as follows: Read dependency information of the tasks files. Verify whether there is really a package with this name and print the description of this package. If there is no such package in Debian try to parse the tasks file whether there is some information given and mark the result as prospective package for further inclusion.

The rationale behind this is to provide as much as possible information about packages that might be interesting for the target user of the Blend. Moreover the page can provide useful information for developers about things that might be a useful help for the project to work down the todo list and build Debian packages for software that is not yet included in Debian.

Tasks files controling web sentinel content

The content of the tasks files that are used to build the metapackage content of a Blend is also used to determine the content of the web sentinel pages. Thus you can influence the tasks pages by simply editing the tasks files inside the SVN of the sources of the Blends metapackages. The canonical location of these tasks files inside the sources is (with the exception of Debian Edu that is locatet in Debian Edu SVN repositories) the Blends SVN at svn://svn.debian.org/svn/blends/projects/BLEND/trunk/SRCPKG/tasks Here you can add or remove additional Dependencies to existing packages or you can add additional information about so called prospective packages. The syntax how to do this is explained below.

To get the todo list builded it is necessary to add some additional information to the task files which are the main database of information for the Blend. The information is following the RFC822 syntax as all Debian control files do and is kept quite simple: Depends / Recommends / Suggests Even if there is no Debian package available for the moment the names of prospective packages are given as if they would exists. The rationale behind is that once such a package might exist the source of the metapackage does not have to be changed and will work out of the box after rebuilding. Ignore The Ignore key should be the favourite way to use for specifying prospective packages in case the packages should be evaluated once it appears in the Debian package pool. If "Depends", "Recommends" or "Suggests" are used for not yet existing packages they will be turned into the list of Suggests of the metapackage and thus might be possible to become installed on a users machine if the user decides to install all suggested packages. If some evaluation should be done first the "Ignore" tag is your friend. Homepage This is the URL to the software that should be packaged. WNPP In case there might be a WNPP bug filed for this software the bug number is given here. This helps to keep track of the ongoing effort to package the software. Responsible In case some developer claimed to care for the software (perhaps by issuing the WNPP bug report) the e-mail address of this developer is given here to enable an easy way to contact this person. License Debian cares always about the license. This information about prospective packages should be easily available. Vcs-Svn

If there is some Debian packaging stuff available this can be addressed in this field. Unofficial packages which have this field set are rendered in a separate section with links to the packaging SVN.

The usage for this field is the same as it is described in

Vcs-Git

If there is some Debian packaging stuff available this can be addressed in this field. Unofficial packages which have this field set are rendered in a separate section with links to the packaging Git.

The usage for this field is the same as it is described in

Vcs-Browser

If there is some Debian packaging stuff available this can be addressed in this field. Unofficial packages which have this field set are rendered in a separate section above unofficial packages outside the official Debian mirrors. If you have set Vcs-Svn or Vcs-Git there is no need to set Vcs-Browser explicitely because it is obtained automatically from the other fields. But you might override this automatically generated URL if needed.

The usage for this field is the same as it is described in

Pkg-URL In some cases there are unofficial packages for some software which are prepared by a third party. It helps our users if they could install such a package and thus the URL to it might be a helpful hint. This is also true for developers because they might have a look at this packaging before they start from scratch. Often packages are available at and prepared by people who do not yet have an official Debian maintainer status and thus are not able to upload packages to the Debian mirror. The packages at mentors are waiting for sponsoring of an official Debian maintainer and if such a package shows up in the Blend tasks list it might speed up the inclusion into official Debian distribution. Pkg-Description This tag should give reasonable information about the software as it normally is done in debian/control files. It can be either a copy of the description of the WNPP bug or could be used to file a WNPP bug and thus helps to simplify the packaging work. Remark In some cases it makes perfectly sense to add a remark on behalf of the Blends team to a package which is visible on the tasks page. This can be done using the Remark field. It can be used in the same syntax as a Description field in Debian control files. Registration Sometimes, specifically in the case of scientific software, the project authors ask for registration of their software to get numbers of users of their software. These numbers enable them to ask for further funding of their project. To support this intend of authors the tasks pages can feature a link to this registration page if the link is given in the tasks file in the Registration field. Published-* (deprecated)

These tags were previouosely used to specify scientific publications. Its use is now deprecated and you rather should use the file debian/upstream as documented in . The debian/upstream files will be gathered in their state in SVN - so changes become effective after some delay caused by cron jobs. This new way to handle publications prevents code duplication and can be used more flexible by single maintainers and is also useful for other purposes than only for Blends sentinel.

Configuring Web Sentinel pages per Blend

To set some typical values for the web sentinel per Blend each Blend has to provide a configuration file. These files are formatted in RFC822 files and . The following values can be set: Blend Id of the Blend (for instance debian-edu, debian-med, etc.) ProjectName Name the Blend in correct spelling. Please note that English spelling is without a dash and it is "Debian Edu" (not Debian-Edu) and Debian Med (not Debian-Med) ProjectUrl URL to technical information about the Blend Homepage URL to the user oriented homepage of the Blend AliothUrl URL of the Alioth project of the Blend (might be identical to ProjectUrl) LogoUrl URL to a logo image of the Blend ProjectList E-Mail address of a mailing list where developers and users of the Blend are communicating PkgList E-Mail address of a mailing list where developers of the Blend are discussing technical details of packaging OutputDir Directory where to put the rendered HTML pages. The Blends pages are hosted on Alioth and usually stored at /var/lib/gforge/chroot/home/groups/blends/htdocs/<ProjectName> DataDir Directory where the rendering code stores temporary data like SVN checkout of tasks files etc. This is usually set to /var/lib/gforge/chroot/home/groups/blends/data/<ProjectName> VcsDir Path to tasks files in Blends SVN /svn/blends/projects/science/trunk/<ProjectName> CSS In case a CSS file different from the default Blend CSS is wanted for a specific Blend a (relative) path to this file can be specified.

Debian Description Translation Project

The (see ) provides users of non English languages with information about Debian packages. The sense of supporting especially the translations of descriptions which are in the focus of a Blend is to make the Blend even more usable for our target users. Moreover people interested in the special field of the Blend are most probably able to provide good translations if it comes to texts that are specific to their field of knowledge. Thus there is a web page automatically created that parses the tasks packages for package names and verifies the translation status of the package descriptions.

Finally the DDTP descriptions are used to create internationalised pages of existing packages which might help users with insufficient skills in English to easily find their software of interest. If the browser locale is properly set the user will get translated descriptions of existing packages - provided that the DDTP translations for all these packages are existing.

Features of the web sentinel tasks pages

For so called prospective packages - packages which are not yet in Debian as discussed above - only the information given explicitely in the tasks file can be provided. For official packages the Debian infrastructure provides a lot of metadata, that is collected in the Ultimate Debian Database (UDD). The script which is creating the web sentinel pages collects all this data from UDD and tries to provide the most comprehensive overview over a set of packages for a given task of a Blend. The following list gives an overview over the metadata of packages belonging to the tasks of a Blend.

Short and long Description If there is a DDTP translation the descriptions are translated. Homepage The Homepage field is taken from the debian/control file. If this information is missing for some package on the tasks page it might be a sign that the package is not properly maintained and deserves a wishlist bug report to add this information (at least for non-native Debian packages. Maintainer / last Uploader Both are provides as mailto-links. If the latest Uploader is different from the Maintainer this information is given as well. This is specifically interesting for group maintained packages - actually a tendency in Blends to maintain packages as Blends team - where the maintainer is the Blends team and the Uploader is the name of the actual developer who uploaded the package. Popularity contest The popularity contest database contains different values. The tasks page is presenting the most relevant of them: the number of people who really use this package regularly and the number of people who upgraded this package recently Versions and architectures A button can be used to uncover the versions of this package in the Debian package pool as well as the architectures for which this version exists. The button is coloures in yellow if there is a new upstream version available which enables the Blends packaging team to easily detect work items to do.

Bugs overview

The goal of a Blend is to support their user as best as possible. So a feature to have a quick overview about all packages in our focus might be helpful. This is solved by the bugs overview page. To create this page the tasks files are parsed for the listed dependencies. Then the Debian Bug Tracking System is consulted about known bugs of these packages. All bugs are listed and marked with different colours according to their severity. So the developers can easily check this page in case they plan to fix some bugs that are relevant for the Blend.

If you want to see examples for those bugs pages just have a look at the using this technique and follow the links to the bugs pages once you selected one specific Blend.

SVN overview

This page gives a recent overview about the current development activities of the Blend developers.

Quality assurance report

The Debian Quality Assurance group does a decent job in watching the status o f Debian packages. If a package features a valid debian/watch the tool uscan is able to verify the upstream source location for newer versions. The QA report page reports issues about the packages that are relevant for a Blend.

blends-0.6.16.4ubuntu2/doc/en/C_bts.sgml0000644000000000000000000000472412147323454014531 0ustar Using the Bug Tracking System How to ask for packages which are not yet included

A very frequently asked question in mailing list is, whether program_xy can be integrated into a Debian Pure Blend. As long as there is an official package of this program it is an easy task. But mostly users ask for software which is not yet integrated into Debian.

There is a how anybody can ask for including a certain piece of software into Debian. It explains how to use the program reportbug for this purpose.

In Debian Pure Blends some house keeping of interesting packages is done and once an ITP is issued it should be mentioned at the relevant tasks page to keep other team members informed. To make this happen it is a minimum requirement to at least foreward the ITP mail to the relevant mailing list crossing fingers that somebody feels responsible to enter this information into the according tasks file. It is even better if you just include the information yourself (see for more details).

How to report problems

Debian has a very useful Bug Tracking System (BTS) but unfortunately users seldom know about this fact and how to use it right. This is the reason why users sometimes become angry about errors because they do not know what to do next and just install a different distribution instead of trying to solve the problem.

A is helpful in these cases. While the program reportbug fetches other reports from BTS before creating the bug report it is always a good idea to search for known problems and probably suggested solutions before calling reportbug.

blends-0.6.16.4ubuntu2/sources.list.UNRELEASED0000644000000000000000000000041312147323454015441 0ustar # For testing purposes this sources.list might be useful. It is a # good practice to use UNRELEASED in the changelog as target distribution # for not yet finished packages and blends-dev should also work in this # case deb http://ftp.debian.org/debian unstable main blends-0.6.16.4ubuntu2/sources.list.natty0000644000000000000000000000007212147323454015152 0ustar deb http://archive.ubuntu.com/ubuntu/ natty main universe blends-0.6.16.4ubuntu2/sources.list.lucid0000644000000000000000000000007212147323454015113 0ustar deb http://archive.ubuntu.com/ubuntu/ lucid main universe blends-0.6.16.4ubuntu2/sources.list.saucy0000644000000000000000000000007212147323606015136 0ustar deb http://archive.ubuntu.com/ubuntu/ saucy main universe blends-0.6.16.4ubuntu2/blend-update-usermenus.80000644000000000000000000000126512147323454016122 0ustar .TH blend-update-usermenus 8 "2008/11/05" "" "Debian Pure Blends" .SH NAME .B blend-update-usermenus \- update user menus of all Debian Pure Blend users .SH SYNOPSIS .B blend-update-menus <\fBBlend\fR> .SH DESCRIPTION The script can only be called by root and calls .B update-menus(1) for every user who is registered for the Debian Pure Blend \fBBlend\fR. If a user wants to update his own personal menu he should call .B update-menus(1) directly. .SH OPTIONS .TP .B Blend - one of the installed Blends, listed in /etc/blends/, for example (if installed): .I edu , .I gis , .I junior , .I med or .I science .SH AUTHOR Andreas Tille , Cosimo Alfarano blends-0.6.16.4ubuntu2/blend-update-usermenus0000755000000000000000000000235312147323454015756 0ustar #!/bin/bash # # $Id$ usage() { echo "Usage: `basename $0` " echo "Blend: `getBlendList|tr ' ' '|'`" echo echo "Updates user menus of all users registered for Blend" } # the base dir for Blend conffiles, where script expects to find dirs named like # each registered Blend CONFBASE=${CONFBASE:-/etc/blends} # a local per Blend conf is sourced later, after argument parsing . ${CONFBASE}/blends.conf # specific utilities for blend-update-menus . ${SHAREDIR}/blend-update-menus if ! amI root; then blendLog "$0 must be called by root. If you are a normal user just call update-menus ." exit 0 fi case $1 in -h|--help|"") usage exit 0 ;; *) set -e checkBlend $1 || \ blendFail $? "Debian Pure Blend $1 does not exist" BLEND=$1 set +e esac if [ -s /etc/blends/${BLEND}/${BLEND}.conf ] ; then . /etc/blends/${BLEND}/${BLEND}.conf fi for ROLE in `getBlendRoleList ${BLEND}`; do for BLENDUSER in `getUsersInRole ${BLEND} ${ROLE} 1`; do # Update user menus if UPDATEUSERMENU is set to yes blendLog "Adding menu for user ${BLENDUSER} of ${BLEND} ..." su ${BLENDUSER} -c "update-menus" done done blends-0.6.16.4ubuntu2/sources.list.unstable0000644000000000000000000000077512147323454015642 0ustar # using unstable as target distribution for the meta package dependencies # does actually not sound reasonable. The idea is to enable a smooth transition # to testing for all meta packages and thus here testing is used as target # distribution. You are free to provide your own source.list.unstable # in the source of your meta package building code to force unstable as # target or alternatively you could change this file (/etc/blends/sources.list.unstable). deb http://ftp.debian.org/debian testing main blends-0.6.16.4ubuntu2/blend-update-menus0000755000000000000000000000623212147323454015057 0ustar #!/bin/bash # # $Id$ usage() { echo "Usage: `basename $0` [ -u | -b ]" echo "Blend: `getBlendList|tr ' ' '|'`" echo "user: system user registerd to a Blend" echo echo "run as user updates only the user's menu script" } # the base dir for Blends conffiles, where script expects to find dirs named like # each registered Blend CONFBASE=${CONFBASE:-/etc/blends} # a local per Blend conf is sourced later, after argument parsing if [ ! -s ${CONFBASE}/blends.conf ] ; then echo "File ${CONFBASE}/blends.conf is missing. Please check installation of package blends-common." exit 13 fi . ${CONFBASE}/blends.conf # specific utilities for blend-update-menus if [ ! -s ${SHAREDIR}/blend-update-menus ] ; then echo "File ${SHAREDIR}/blend-update-menus is missing. Please check installation of package blends-common." exit 13 fi . ${SHAREDIR}/blend-update-menus # Get command line arguments GETOPT=`getopt -o b:d:u:h --long blend:,user:,help -n "$0" -- "$@"` eval set -- "$GETOPT" while true do case $1 in -h|--help) usage exit 0 ;; # get blend name # for compatibility reasons we need to handle -d option # here as well because postrm of previousely installed # CDDs are using this option -b|--blend|-d) if ! amI root; then blendLog "You must be root to specify --blend parameter" blendLog "" usage exit 64 elif [ -n "${BLENDUSER}" ]; then blendLog "You cannot specify --blend and --user at the same time" blendLog "" usage exit 0 else BLEND=$2 shift 2 fi ;; # get user name -u|--user) BLENDUSER=$2 shift 2 if ! amI root && ! amI "${BLENDUSER}"; then blendLog "You must be root to specify --user parameter with a user that's not you" usage exit 64 elif [ "${BLENDUSER}" == 'root' ]; then blendFail 64 "err: Menus for user 'root' cannot be updated" elif [ -n "${BLEND}" ]; then usage exit 0 fi ;; --) shift break ;; *) blendLog "$1 not recognized as option" >&2 exit 67 # EX_USAGE ;; esac done # update menu scripts for BLENDUSER, for any Blend, if any if [ -n "${BLENDUSER}" ]; then SYSSCRIPT="${SHAREDIR}/menu/blend-menu" USERSCRIPT="`getUserHome ${BLENDUSER}`/.menu/blend-menu" set -e checkUser ${BLENDUSER} || \ blendFail 67 "User does not exist" isUserRegistered ${BLENDUSER} || \ blendFail 67 "User ${BLENDUSER} is not registered to any Blend" # there's nothing to do on per user basis criteria #updateUser ${BLENDUSER} "${SYSSCRIPT}" "${USERSCRIPT}" set +e # update menu scripts for any user registered into the specified Blend elif [ -n "${BLEND}" ]; then # Now that we know the selected Blend, we can check if there is a local # configuration for it (ie differnt backend from the default one) test -n "${BLEND}" -a -f ${CONFBASE}/${BLEND}/${BLEND}.conf && . ${CONFBASE}/${BLEND}/${BLEND}.conf set -e checkBlend ${BLEND} || \ blendFail $? "Debian Pure Blend ${BLEND} does not exist" # there's nothing to do on per Blend basis criteria #SYSSCRIPT="${SHAREDIR}/menu/blend-menu" #updateBlend ${BLEND} "${SYSSCRIPT}" set +e else exec $0 --user `whoami` fi