On Thu, 5 Mar 2009, Samuel Thibault wrote:
It has been suggested a few times (471410, 511329, 516723) to
add an "accessibility" item to tasksel, which would e.g. install
gnome-accessibility. The task would be automatically selected when
accessibility features was used during d-i itself.
I wonder whether this effort might profit from maintaining metapackages
for accessibility as it is done in the blends effort. The blends-dev
has tasksel support as well - so it is easily possible to include
accessibility related packages into tasksel. The extra profit would
be that you can provide an easy overview about accesibility related
programs in Debian - the only way I know is
$ apt-cache search accessibility
which is quite weak. Thinks of alternatives like
http://blends.alioth.debian.org/science/tasks/
(which might even work for non native English speakers) and you also
have a developer related overview about bugs
http://blends.alioth.debian.org/science/bugs/
There is no extra effort to create these web pages once you defined
the tasks.
`While it is a possible approach to have the installer explicitly
select packages for the users who are going to use the machine,
it is also obvious that an administrator might not know in advance
that a person with special needs is going to use this machine.
If we think this through, we realize that what would be most desireable
is to have accessibility infrastructure installed by default on a
default desktop, so that a person with special needs can just activate
it at login time if they need to.'
I admit that my suggestion above does not really help in this aspect.
On the other hand there were some ideas raised in the past to enable
a user to install certain tasks quickly inside the Blends framework.
Perhaps we should raise this topic again.
`What if, for example, you walk up to a friend/coworker and talk about
some issue. You end up wanting to show them something, so you'd
actually like to login on tehir Linux machine with accessibility enabled
so that you can work together on the project. However, since nobody
thought their machine would ever be used by a disabled person, the
necessary software would not be installed.'
The problem is that the typical admin does not have the specific
knowledge what actually is needed. The idea to iron out this knowledge
inside the tasks files to enable admins who have not enough specific
knowledge about the needs of their users is one means to help in
this issue.
`That is why I think ultimately, accessibility infrastructure needs to be part
of the default desktop installation. There are a few other scenarios as well,
like public workstations (for instance in universities) running Linux.
Currently, for them to be accessible, the admin staff needs to know all the ins
and outs of accessibility, or they at least have to make a conscious decission
about providing it to users. If accessibility would work by default,
the chance of success for disabled people trying to find an accessible
computer would be much higher.'
I perfectly see the point here. On the other hand I assume there are
most probably urgently needed packages who should be installed per
default and others which are just Recommended and Suggested. So IMHO
it makes sense to have a accessibility-gnome / accessibility-kde
(perhaps accessibility-desktop) metapackages which are part of a
default installation. But most probably there are other packages
which should be handled with different priority and you can perfectly
handle these by using metapackages. The advantage of using
accessibility-gnome / accessibility-kde metapackages is that you
can perfectly handle the dependencies inside the accessibility project
because there will be no need to change d-i or the Gnome / KDE tasks.
They need only depend from one single package and you can change the
dependencies on your own in case some additional packages will show up
or some names will be changed for whatever reason.
So, I'm asking: would it seem reasonable to ask tasksel to install
accessibility packages along desktop packages?
IMHO yes - but in the way I suggested above and not by using explicite
package names.
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
