Re: Introducing DoudouLinux
On Wed, Aug 10, 2011 at 11:37:29PM +0200, Jean-Michel Philippe wrote:
> Currently we haven't done anything to solve it. One idea is to reduce
> the size of data by resampling or recompressing. For example a music
> file can be divided by 4 if you resample it at 22kHz instead of 44kHz
> and convert it from stereo to mono. I saw recently a game which has a
> data package in high resolution and another one in low resolution.
> Sounds like a good solution.
... 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. I would strongly
suggest to iron out your workflow as a script and provide it to upstream
or at least to the Debian package maintainer to let him provide small
alternative data packages. This saves you a lot of time and will
probably find other user outside DoudouLinux.
> Then we have several huge children apps, which come with a lot of images
> and sounds. Your proposal to split the data package sounds good too,
> especially because children never use all the features of these apps.
> Moreover many features may be overlapping between apps and we see that
> they're overlapping more and more with time.
Same her - try to work on this inside Debian.
> We do not do this systematically but, as we've disabled recommended
> packages, we're checking software usability as much as possible and we
> add the missing recommendations whenever required. Maybe we should write
> a tool to help this kind of investigations.
Same here: I would rather work with the package maintainer (directly or
via bug tracking system) to make the packages better suited. 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 ensure dependency relationships affecting footprint of the
>> package
>> are really appropriate and file bugs as needed. For example, ensure
>> that
>> every 'Depends' really is vital for the package to operate properly,
>> or
>> else perhaps it should be softened to 'Recommends' instead.
Ahhh, Ben just made this suggestion (I somehow skipped this mail formerly).
> Mmm, it sounds more complicated. Till now I've never supposed that there
> could be unneeded dependencies, but for sure it may happen. Sometimes I
> install Synaptic in a Live session and list packages by decreasing order
> of size. Then I click remove on suspect packages to see what can need
> such package, I should also ask myself about the relevancy of the
> dependency.
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.
>> One thing I wish Debian Live supported and I'll have to ask the team
>> about is a simple to use way to specify negative package selections.
>
> Oh yes, I've been thinking of such feature too :). Thank you for the
> workarounds, it may be useful.
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?
>> That's where you come
>> in. Without any technical involvement at all, you could provide the
>> remnants of the Debian Jr. team (Andreas, me, and anyone else who is
>> listening in) with metapackage suggestions and it will be a very
>> simple
>> matter for us to make those changes to the metapackages for you.
>
> Ok, then we'll compare both package sets and tell you.
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.)
> For sure, the more useful is our work the better. So we'll do our best
> to work not with but within Debian!
:-)
> Our work on ARM requires that we
> change our way to work in order to leave the special case of LiveCD's to
> reach something more universal.
While this is an interesting topic in any case I personally did not
dived into this.
> I perfectly agree. Finally the only difference seems to be that you have
> supposed children have a so-called helper to help them get into Debian,
> as we want children to believe computers are simple, while using Debian –
> kind of revolution ;).
>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").
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: