... 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".
The
only thing that Ben and me suggested was, that *if* you have found a
dependency that does not fit your expectation, you should fix it
inside
Debian 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 at
svn://svn.debian.org/svn/blends/projects/junior/trunk/debian-junior/tasks
is actually not a thrilling high level technical thing and could
probably be done by everybody who can use an editor and SVN. So I
would
rather suggest you simply start editing those files according to your
needs instead of telling us what to change. (But for sure I'd
volunteer
to 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.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive:
http://lists.debian.org/[email protected]
