GNOME Bugzilla – Bug 589244
Remove libgail-gnome usage, use gail in gtk+ instead
Last modified: 2009-11-09 21:35:12 UTC
Orca seems to be the last consumer of libgail-gnome (instead of gail in gtk+) which should die. http://bugzilla.gnome.org/show_bug.cgi?id=563684#c16 <WillieWalker> wwalker@opensolaris:~/work/orca$ grep gail configure.in <WillieWalker> # libgail-gnome 1.1.3 <WillieWalker> # gail >= 1.8.11 \ <WillieWalker> It's commented out. <WillieWalker> BUt... <WillieWalker> wwalker@opensolaris:~/work/orca$ grep gail orca.spec <WillieWalker> %define gail_version 1.8.11 <WillieWalker> %define libgail_version 1.1.3 <WillieWalker> BuildRequires: gail >= %{gail_version} <WillieWalker> Requires: gail >= %{gail_version} <WillieWalker> Requires: libgail-gnome >= %{libgail_version} <WillieWalker> andre: I need to go through the Orca dependencies and figure out the best way to represent them.
Created attachment 139020 [details] [review] Patch to eliminate gail, libgail, cspi from the orca spec file. This patch should prevent jhbuild from sucking in libgail-gnome, but I could use some help with figuring out and specifying exactly what the build-time and run-time dependencies. I believe all the build needs at this point is Python 2.4 and the set of tools needed for autogen. To run, however, it also needs to have the entire accessibility stack, ORBit, bonobo, gnome-speech, gnome-mag, brltty, liblouis, etc. I'm not sure how to express all that in a minimal way (i.e., reducing the number of redundancies due to some dependencies also sucking in other dependencies).
(In reply to comment #1) > ... I'm not sure how to express all that in a minimal way (i.e., reducing the > number of redundancies due to some dependencies also sucking in other > dependencies). I'm curious, why would you want to do this? What I mean is that, in an hypothetic scenario in which we have: 1. Project A depends on project B and project C. 2. Project B depends on project C. Let's say Orca==A, why would you want to remove project C from the dependencies list? If you do that, it may happen that, in the future, B stops depending on C, so you're screwed (because A still depends on C).
(In reply to comment #2) > (In reply to comment #1) > > ... I'm not sure how to express all that in a minimal way (i.e., reducing the > > number of redundancies due to some dependencies also sucking in other > > dependencies). > > I'm curious, why would you want to do this? > > What I mean is that, in an hypothetic scenario in which we have: > > 1. Project A depends on project B and project C. > 2. Project B depends on project C. > > Let's say Orca==A, why would you want to remove project C from the dependencies > list? If you do that, it may happen that, in the future, B stops depending on > C, so you're screwed (because A still depends on C). This is not the scenario I'm thinking of. I'm thinking of the following scenario: A uses B, B uses C, A does *not* directly use C (as it does in your scenario). Thus, A should not need to list C in its dependency list. I think we have or had some of that in the orca.spec file and in the commented out section in configure.in. In any case, it sounds like you might be very interested in helping determining the direct dependencies of Orca for building it and for running it. :-) Can you help here?
(In reply to comment #3) > This is not the scenario I'm thinking of. I'm thinking of the following > scenario: A uses B, B uses C, A does *not* directly use C (as it does in your > scenario). Thus, A should not need to list C in its dependency list. I think Ah, makes sense, I wonder then why C ended up in the dependencies list... > we have or had some of that in the orca.spec file and in the commented out > section in configure.in. Blame packagers :) > In any case, it sounds like you might be very interested in helping determining > the direct dependencies of Orca for building it and for running it. :-) Can > you help here? No sorry, not very familiar with Orca. I was just lurking... ;)
The topic for this bug has been fixed. I opened bug #590378 for the configure.in and orca.spec.in issues.
For the record: Filed bug 590359 to update jhbuild modulesets and after that automatically get libgail-gnome out of the 2.99 stats at http://www.gnome.org/~fpeters/299.html .