Re: Add a package to a liveCD?
>
> > b) Including enabling of accessibility in the tasksel seems a problem. First because it implies changing several ones, while the stuff is transversal.
>
> The end-of-time goal is that it is transversal. But ATM it is completely
> useless to enable it on desktop where it will just not work. That's why
> it is currently not enabled in all tasksels for installed systems.
> That's the same for liveCDs: there is no point in making the image
> bigger if it's useless.
Well... the image should not be much bigger. It does not add anything, it only passes gsettings commands to enable what is needed in the dconf and others. For lighdm, it just creates a directory with a small file. But indeed, except GNOME and MATE, it would not be relevant for other DE.
> > Next because I guess if it is not in desktops such as MATE, it is likely to avoid some issues.
>
> It's rather a mere question of unneeded space use. That question is the
> same with liveCDs. Again, I believe there is nothing more to be done
> here than for installed systems, because the issues at stake are the
> same.
I agree. But for installed systems, the accessibility activating happens at the end, here it should be activated at the starting of the session, or be activable manually.
> > that is why BRLTTY, as well as the speakup scripts, include accessibility enabling it, if the installer uses brltty and speakup, as the last step of the process. So here, it should be the 1st step of the process, and an additional script to add to the livecd when running the live session on the desktop.
>
> Probably in the liveCD case we indeed need a shortcut to make it run
> brltty, i.e. pressing the shortcut would mean "yes, I'm sure I don't
> have any serial-to-usb board for flashing devices, so it's safe to run
> brltty".
Yes. And as a consequence, pass the gsettings commands to enable accessibility. So if I understand the infrastructure, enabling the brltty.udeb script at another time for the liveCD case.
But again, that's the same issue as on an installed system that
> you would find out at a public library or elsewhere, there is nothing
> specific to liveCDs here.
Right. But while I can understand it on an installed system, as it is for specific needs of each user, and the universality point makes that we cannot activate the accessibilty if useless, especially brltty due to its potential consequences (it is better to let the user request explicitly installing the package), I think that on a liveCD, as it is designed for testing Debian, running the installer, etc, we should ship the needed packages (brltty) and disabling them by default, but allowing to enable them if needed. The user expects to access to a liveCD normally, whereas on an installed system, he can understand that in order to access to it, we need to install brltty and passing some config lines to activate specific needs. On a public space, the same as on a liveCD could be set anyway.
regards
> Samuel
>
Reply to: