On Fri, Jan 18, 2002 at 02:46:38PM +0100, Guus Sliepen wrote:
> On Fri, Jan 18, 2002 at 02:05:48PM +0100, Tille, Andreas wrote:
> > I personally do not care about music and I have to admit that I mostly
> > switch it off (by software or by just removing the power connector of
> > the speakers ;-). But it was just an idea for those who might like it ...
> > It wouldn't be a real problem for me if there wouldn't be any sound.
>
> I'll ask the band that wrote the music about it.
>
> > Perhaps we build a further package junior-race?
> >
> > > (After hearing the soundtrack I think it wouldn't be
> > > suitable for Debian-Jr anyway.)
> > Well than it would go this way:
> >
> > junior-race
> >
> > Depends: trophy, race
> > Suggests: tuxracer ## only suggets, because it needs 3D support
> > Conflicts: race-sound ## if there would really be a race-sound
Not having heard the soundtrack, what is objectionable about it? It would
be nice if upstream could provide an alternative soundtrack that is
appropriate for children.
Also, Conflicts: race-sound is not acceptable from my point-of-view. This
would be fine for a child-only system, but we assume that some systems are
used both by young children and older siblings or parents. The soundtrack
may be perfectly acceptable to the older ones, so Conflicts is wrong.
Instead, we should look at solutions which make turning off a particular
feature that is inappropriate for children the default for child users.
This is getting to be a rather regular issue (that is, what to do
about features of a program that are deemed inappropriate for children)
so here are my thoughts (a sort of draft Debian Jr. policy, I guess).
The classic example is xpenguins. From the man page:
Some notes regarding the various activities. If you design a new
theme, feel free to make the splatted, squashed, zapped and exit
animations as gory and bloody as you like, but please keep the
explosion activity nice and tame; that way those of a nervous
disposition can employ the --no-blood option which replaces all
these violent deaths with a tasteful explosion that wouldn't offend
your grandmother.
So we should be encouraging upstream to do something like this. If upstream
decides to make such an option the default, great. If they don't, then
Debian Jr. may provide an alternate version that makes it the default and
conflicts with the non-junior version. Older users who wish to use the
"inappropriate for children" version can simply start the application with
the switch to enable the disabled feature. If upstream does not wish to add
such a switch, the DD may wish to patch it. If neither of these solutions
are implemented, Debian Jr. would simply drop the package. (Note: this
isn't such a bad solution, and is often the easiest. If a parent's
judgement differs from Debian Jr's and they wish to install the package and
use it with their children in the state it is in, they are certainly free
to do so.)
The "hard line" on this would be to rip out the feature from the code
altogether. If there is sufficient interest in providing packages that
do this, it may be that upstream also supports a build-time option to
disable it. But I feel that the approach I outlined above is the best
compromise for the general case. If there is sufficient interest in
providing an entirely "foolproof kid safe" version of a given package,
then the DD may elect to provide a third conflicting alternative binary
package built without the inappropriate feature. The default Debian Jr.
offering, however, will provide the "option" version.
Ben
--
nSLUG http://www.nslug.ns.ca [EMAIL PROTECTED]
Debian http://www.debian.org [EMAIL PROTECTED]
[ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]
[ gpg key fingerprint = 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
