ok, differing arches all have the same source in common. So, maintaining for them is actually easier than you might think. All that would really be required to make an arch specific package is the proper scripts that patch and package for that arch. Otherwise, the source code, itself, is pretty common across all arches.
Now, I have done this in the past. Used a source tar ball and compiled on a debian based system and also compiled on a RedHat based system and in both cases, the utility that I compiled functioned the same and required the same libraries and development tools. THere is also the use of a ports tree (As seen in the BSD ecology). I have been able to compile some linux tools over there, but the ports tree is a bit limited and still depends on developer support. So, in that case, it could be problematic. Someone else pointed out that we may need an organization fronting some development as a means to get patches and packages reviewed faster. Perhaps we need to take a look at the guys at the NV Association (the makers of NVDA, the free windows screen reader). THey have a fairly sizable fundraising network and do a lot of work with some paid developers. Also, the guys running the organization are a pair of blind programers. Now, if we could get them involved, it might help to enhance operations in creating a standardized accessibility package set that can be arch independent. Now, mind you, I am not a coder. I can operate a compiler, even make some simple changes to get a compile working, but thats about as far as my developer skills go. My forte is security, intrusion detection, firewall scripting and auditing as well as advanced system administration. And yes, my preferred OS in a secure environment is in the BSD ecology. However, as a recent exchange with Theo DeRaadt demonstrates, there are just some folks who won't even consider supporting the idea of making an OS accessible. In fact (as that recent exchange demonstrated), they might just go out of their way to impede progress in this area. anyway, given all that we are striving for, some good help can be had out there (like the aforementioned NV association). It's just a matter of getting them onboard. -eric On Apr 23, 2017, at 4:13 AM, Linux for blind general discussion wrote: > On 4/18/2017 8:23 AM, Eric Oyen wrote: >> here is one thing that might be distro independent: create an accessibility >> package set. This would include the required libs, scripts, binaries and >> config files needed to make any distro accessible. It would include >> emacspeak, BrlTTY, ORCA, the appropriate audio drivers and libraries and >> even access to the kernel modules required to make it all work. > > > While great in principle, it's impossible and wouldn't work. First, how do > you maintain binaries for the different arches? The Raspberry Pi runs on ARM, > I'm running amd64, some old machines are 32-bit x86, etc. Again, speaking of > very limited resources, it would be impossible to maintain the latest > versions of all of these packages and build binaries for all of the arches. > Also, what about memory? A small ARMEL system isn't going to run Orca very > well, although I've read of people doing it. The list goes on. > > The other problem is you'd have massive system breakage. If I run a Fedora > binary on Debian, there is probably a shared library conflict. That means > everything has to be compiled statically, slowing down execution and > increasing memory. Even at that, you can't mix and match kernel modules in > most cases. My 4.3.3 Speakup modules probably won't run on my 4.6.4 kernel. > Finally, every distro puts files in different places. Do you have > /usr/bin/orca which overwrites the distro package or /usr/local/bin/orca? If > the later, what if /usr/local/bin/orca breaks, leaving you without speech? > You have to delete it to get /usr/bin/orca to run. What if the version of > Gnome supplied doesn't match Orca? The list goes on and on. > > There is a possible solution, however. It would be to create a list of as > many config files as possible for as many programs as possible, roughly > divided into console and GUI. My thought would be, for example, special > configs for Lynx the cat, Links the chain and whatever other console programs > people have customized. For graphical, you would have Orca plugins, weather > scripts like Vinux has, etc. They could be supplied as generic tarballs which > could be extracted on any OS, any platform and any distro. The only thing > special would be a custom installer or support in the existing upstream > installer. It could fetch the tarballs from a central place and extract them > on installation. Failing that, drop a script which runs at first boot to do > the same thing. Failing that, distribute a bash script which could be run > without speech once you're logged in as root. That would still require the > accessibility packages to be installed, but the script could do that > automatically. Lots of projec ts do that already, mostly on servers. They autodetect the distro, make sure the latest package lists are downloaded and install from either a central repo or the distro's repos. You could even ship a static .wav player and include spoken prompts. I've thought of designing a talking menu system that way. > > Getting back to your point, you could have two sets of central repos, one for > RPM and one for .deb as those are the two most popular. The script could > figure out which distro you're running, fetch from the central repo, install > and that's it. The user can pick what they want and whether they want console > or GUI. You would still have to compile everything statically, but you could > support Debian stable, testing, oldstable, Ubuntu, Fedora, maybe RHEL, etc. > That would let you ship custom RHEL kernels with working Speakup modules. > That is not only very doable but is already being done with webmin and lots > of other projects. It could easily be maintained by a few developers. You > have one for RPM, one for .deb and one for security and support. > > Even better, you could have a live CD which does this. I don't mean like > Vinux or Ubuntu. I mean after you install your favorite distro, you boot the > live CD and it runs the script to install accessibility on the already > installed distro. You could run that CD on hundreds of machines and in > theory, all could be made accessible. Then again, that makes me think if all > upstream distros made their installers accessible, this would all be a waste > of time. > > _______________________________________________ > Blinux-list mailing list > Blinux-list@redhat.com > https://www.redhat.com/mailman/listinfo/blinux-list _______________________________________________ Blinux-list mailing list Blinux-list@redhat.com https://www.redhat.com/mailman/listinfo/blinux-list
