... as far as you are not forced to do it on your own for every release.For me this sounds as a nightmare maintenance-wise. […]
Yes, I agree. The more our changes are integrated upstream, the less maintenance we'll have. This is one reason why we try to keep stuck to Debian as much as possible.
I bet that in most cases the set of dependencies is not choosen the way it is on purpose but due to a lack of user requirements. Just express your requirements apropriately and fix the thing inside Debian.
Do you mean there are official rules to set recommendations and suggestions, which I'm not aware of?
I do not understand what you mean with "sounds more complicated". Theonly thing that Ben and me suggested was, that *if* you have found adependency that does not fit your expectation, you should fix it insideDebian somehow.
What I mean is how can you surely conclude a package dependency is wrong? Let's suppose a large package is using a single command of ImageMagick. It may be quite difficult to find out that this dependency, although not very desirable, is still necessary. I fear deep source code inverstigation is necessary to be sure of unneeded dependencies. But maybe I'm just worrying for the worst possible case :).
Once I considered "Conflicts" inside metapackages. We did not tried this yet (because there was no actual need for it (at least not explicitely expressed to me). What do you think about this option?
Conflicts would not prevent from installing the whole meta-package, instead of putting unwanted packages of the meta-package list aside?
And BTW, editing the tasks files atsvn://svn.debian.org/svn/blends/projects/junior/trunk/debian-junior/tasksis actually not a thrilling high level technical thing and couldprobably be done by everybody who can use an editor and SVN. So I wouldrather suggest you simply start editing those files according to yourneeds instead of telling us what to change. (But for sure I'd volunteerto proxy your comparison into the tasks files if you mind editing there.)
We're using SVN for our project, so no problem to edit these files by myself. Except that I'd need SVN write access :). Note that Debian Jr. audience is large in age than our current one. I wonder if Debian Jr. should not split its packages to reflect main children skill evolutions (I don't like to classify by age because skills may vary a lot between children of the same age, depending on their environment and preferences).
From my experience with my own son (now close to 21 years studying physics): He liked playing on Debian as I installed it on my old computers which became his. Later he bought his own computer and basically used the "preinstalled system" most of the time for playing but the dual boot Debian I installed to do his homework for school or so. Now at study he detected Ubuntu for his computer and is using it basically all the time (with fewer and fewer exceptions steping back to the "preinstalled system").
Mine are younger (< 10) and say they prefer simple interfaces to the one found in traditional DE (I don't have any “preinstalled system” at home but at school and by their nany they have). I tend to think the same, and use keyboard shortcuts instead of menus. The drawback of EeePC-like interfaces appears when you've too many apps installed: it's kind of organized disorder in tabs! So I'm not sure it's relevant for teenagers, I'll tell in you in few years!
I note that your boy did not become a sysadmin, despite its early use of Debian. I hope many (young) users of DoudouLinux will be enthusiastic about the artistic and creative potential of computers. Maybe this part of the audience will still prefer a simple interface. For us this is also a way to do something enough different from the “preinstalled system” to worth the change.
All the best, JM.