GNOME Bugzilla – Bug 303633
gnopernicus should have support for brltty and load it if present
Last modified: 2006-04-06 11:33:08 UTC
Now, if brltty is not present at compile time, support is turned off. If brltty is installed after, gnopernicus has to be recompiled in order to use it. The desire behaviour is to compile that support, to check at run-time if brltty is present and to load it if present.
Created attachment 46269 [details] [review] proposed patch
Samuel, what are you suggestions/oppinions about patch above?
To be franc, I really would *not* do that. BrlAPI's API will probably not change, but BrlAPI's ABI might change, it is not really stable yet, so using such dlopen() is really not safe. And things have always been like this: if you don't have some library, configure will not use it. How is it that in your case brltty might not be installed when compiling ? The build-dep of Debian for gnopernicus include libbrlapi-dev for instance, and it works fine.
Samuel - do you have another suggestion for how to deal with this? We want to have BrlTTY support built at compile time (with libraries present), BUT if it isn't on the users' system at run-time, it should fail gracefully.
Samuel: the main motivation is to avoid a hard dependency of gnopernicus on brltty, in the resulting binaries. This is important for RPMS etc where the target machine isn't the same as the build machine.
How does a hard dependency pose big problems? Indeed, it makes the user need to download and install Dave's rpm on mielke.cc too. But a lot of other softwares just work this way, mplayer for instance. And it's easy to put the URL of Dave's rpms in front of the URL of gnopernicus rpms. And the distribution helps too: with debian for instance, the libbrlapi deb is available on official mirrors/cds, so that the user won't even need to download it from mielke.cc: when installing the gnopernicus deb, he gets an "I need the libbrlapi package" error, and hence runs apt-get install libbrlapi, and then it works fine. I guess Mandrake/RedHat/... distributions just behave the same. Maybe you will tell me that there can be a versioning problem. Well, yes. But the dlopen() approach just has the same problem: version only jumps up when the ABI changes (which, we hope, should be quite rare now), and that's precisely when the dlopen() approach will break! So this is not a good solution, even less since it needs updated even if brlapi's API doesn't change while its ABI changes.
I forgot: The user doesn't need to install and configure brltty. He only needs to install brlapi, which is just about 80K. It won't hurt to require all gnopernicus-using people install that. And yes, gnopernicus will gracefully fail, with an Error opening brlapi connection: Connection refused Please check that - /etc/brlapi.key exists and contains some data - you have read permission on /etc/brlapi.key - BRLTTY is running error message (which could be improved if needed btw, see braille/libbrl/ttybrl.c)
A colleague of mine proposed an alternate solution: couldn't ttybrl.c be compiled in a separate .so file, and gnopernicus dlopen() _that_ file ? If libbrlapi.so is available, it will work nicely. If not, dlopen() will fail (missing dependancy), and then the BRLTTY choice could be disabled at runtime.
That sounds like a great idea. The reason for avoiding a hard dependency is that gnopernicus is part of the official Gnome 'desktop release' and we try to reduce the number of new libs pulled in there. Of course it's OK to pull in new libs with justification, but if it can be avoided gracefully that's even better.
Created attachment 53411 [details] [review] proposed patch
Comment on attachment 53411 [details] [review] proposed patch patch applied on cvs head.