Re: Metapackages for accessibility
[CC to debian-blends because of some general ideas]
On Wed, Jul 21, 2010 at 09:46:29PM +0200, Samuel Thibault wrote:
> Mario Lang, le Tue 20 Jul 2010 21:29:34 +0200, a écrit :
> > * "console-screen-reader" has several solutions which
> > the user is not likely to use at once. More likely is that
> > they pick one and use it. But installing all of them might
> > lead to conflicts maybe?
>
> We talked a bit more with Mario on IRC. In a lot of cases, it indeed
> doesn't make sense to run several screen readers at the same time. It
> would then make sense to not start them by default. But then it's a pain
> for people who'd just expect apt-get install brltty to be enough to get
> started.
That's perfectly true. BTW, I'm normally not on IRC but I would happily
join an IRC meeting in evening hours.
> Now, what such package would be useful for? Mario thinks that a pitfall
> would be to make people believe that merely installing those will be
> sufficient to be accessible, which is clearly not the case: making a
> workstation accessible means starting and configuring a precise set of
> tools that the user will be able to use and combine, as well as
> configuring some system parameters, etc. A mere meta-package doesn't
> help at all here, but might even hurt in that people would think it's
> sufficient.
I think I understand now a bit better what Mario tried to tell me last
year. However, you perhaps might call me stubborn, but don't you see
any chance to really make it sufficient? IMHO we have the tools which
are needed in Debian to aproach this. If every screen reading package
would provide a virtual package screenreader (and perhaps - I can not
tell how much sense this makes conflicts to other screenreaders to make
sure there will not be conflicting packages installed) and we design a
metapackage which
Recommends: screenreader | <the-most-favourite-screenreader>
Suggests: other screenreaders
we just need to define what is our most favourite screenreader. You
might see a conflict with the freedom of choice here, but IMHO expertise
is also making a choice. A newbee will be happy about a reasonable
choice somebody has done in advance. The freedom is guaranteed because
nobody will prevent you from exchanging the screenreader by some other
package which provides this functionality.
> Actually, I'd tend to think that it raises the question I've discussed a
> bit in LSM 2010's OS session: ideally, somebody with disability should
> be able to go to a public box, plug some USB stuff or press some
> shortcut, and get accessibility tools to let him use the box. This might
> sound as a too idealistic example, but that's what should really ideally
> happen. And that's what should happen for accessible liveCDs (be it a
> standard system, or some teaching material, etc.).
... which is totally in line with what I said: Somebody has to make a
choice what will happen if this person is pushing the button you
mentioned.
> So maybe instead of these meta-package there should be some packages
> which provide tools that have these dependencies, and provide some tools
> to choose and configure accessibility tools. Like a control panel,
> shortcuts, etc.
Well, the metapackages as they are builded by the Blends tools can carry
more than only Dependency relations. You can perfectly design all
{pre,post}{inst,rm} scripts as well as debconf. You also can add extra
content like scripts which might provide an easy to use (debconf-alike)
interface to select and start one of the screenreaders which are
installed by the metapackage.
The idea is: How can I make users life easier. IMHO doing nothing and
let find out the user himself what fits best is not easy. I think
making some reasonable decisions is better and we have two ways to
enable decision making in the Blends framework: Metapackages and tasksel
definitions. Both are created from the tasks files by using blends-dev
packaging tools. Tasksel is IMHO to simple because it is lacking the
"suggsts" functionality (for either not so important or
contrib/non-free) and has also not the feature of extra scripts as
mentioned above. If you know another way to "make decisions about
installation" which might fit better - I would be interested. Otherwise
I would suggest to dive a bit deeper into the features we really have
which might be useful or perhaps you might have ideas about features
which need to be implemented to make it easy for disabled users to get
a box running as quickly as possible.
> > * "gnome" looks neat but the problem is already solved in a better way.
> > GNOME actually considers accessibility a core part of its
> > infrastructure which means that pkg-gnome is already pulling most of the
> > required stuff at least via Recommends. I consider this a great
> > thing and the way to go, thanks GNOME!
>
> I think it's probably better to let gnome do its own integration rather
> than trying to follow what's happening in the gnome world.
My suggestion[1] was about two options: One was do mention every
accessibility related package in Gnome explicitely and the other option
was to recommend Gnome in general. Your statement implies that you are
in favour of the latter which is fine. In the sense what I said above:
I would iron out this decision in some code (=metapackage or other
means) ... while leaving the freedom of choice in case the user has
different preferences.
> > * Most of what is in "speech-synthesis" is going to be pulled via Depends.
> > I am not sure how useful it is to just install everything there is.
>
> It might make sense in the same way as locales-all is used for: just
> provide speech synthesis for as many languages as possible, served via
> speech-dispatcher. Ideally that should be available on all liveCDs, but
> there's still the same issue: it should probably not be started by
> default due to its heaviness?
If you just put it on suggests we just raise the awareness of the user
without pushing him to really install this stuff.
> > > I would consider it as a good idea to do so because this might enable
> > > pointing to the Debian Accessibility project in the release notes for
> > > Squeeze which will probably increase the popularity of the Debian
> > > Accessibility project amongst Debian users and makes Debian more
> > > attractive in this field.
> >
> > Well, we can already point at these nice webpages, can't we?
>
> That's already a good point, yes.
> I'd even say Meta-packages are not so much useful compared to that.
Again, just call me stubborn, but IMHO you are underestimating the power
of metapackages. I can not exclude that you are finally right but you
seem to understand that installing a metapackage is a simple process
where everything which is in the list of dependencies will simply be
installed and fullstop. You have not discussed the usage of virtual
packages, the differentiation between Depends/Recommends/Suggests, the
default {pre,post}{inst,rm} and config scripts as well as the extra
workload we might add for other means.
In my eyes a metapackage is some kind of technically realising a
decision some knowledged people (you, the accessibility team in this
case) have made and will be ironed out in recommendations of different
strengthes to the uneducated user. IMHO it is just a question how
clever you design the metapackage to fullfill this purpose.
Kind regards
Andreas.
[1] http://lists.debian.org/debian-accessibility/2010/07/msg00015.html
--
http://fam-tille.de
Reply to: