Re: Introducing DoudouLinux

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