Created attachment 139663 [details] [review]
Patch to change (mostly) configure.in

This patch changes configure.in mostly.  It removes gnome-speech from the requires portion in the orca.spec file because it's not needed to build or run orca.  It also gets rid of the pydoc build since we really don't do that any more.

I wrestle with the configure.in stuff.  There are build time requirements (which are minimal for Orca) and run time requirements.  In the past, we've been blasted by users for not including the run time requirements in the configure.in file.  So, this patch errs on the side of trying to check as many run time requirements as possible.  That, however, ends up turning them into build requirements since the configure will not succeed without them any longer.

I'm also confused about package names in the orca.spec.in.  Where do they come from?  I suspect this is to feed into jhbuild, so are they jhbuild package names?

I could use some help and advice from those more knowledgeable with the culture around this.  I suspect those familiar with jhbuild might be able to present the most reasonable insight.

Andre - you have any ideas who could help?

I'm guessing maybe I can pick module names from here for orca.spec.in *Requires lines (I know this is 2.26 and not 2.27):

http://ftp.gnome.org/pub/GNOME/teams/releng/2.26.0/versions

Still...there's the question of build vs. run time requirements.  Maybe I could modify the configure.in to issue warning messages, but not fail, for missing run time requirements.  That might appease the quick-to-send-a-flame-to-willie folks while also being more true to what's really needed for a build.

(In reply to comment #2)
> Still...there's the question of build vs. run time requirements.  Maybe I could
> modify the configure.in to issue warning messages, but not fail, for missing
> run time requirements.  That might appease the quick-to-send-a-flame-to-willie
> folks while also being more true to what's really needed for a build.

From what I can determine, the BuildRequires stuff tends to be for extra headers and stuff needed build/package modules (including *.c modules for Python) written in more traditional compile/link/run languages (e.g., C, C++, etc.).  These are typically the *-dev packages one encounters, for example.  For the pedantic, I realize there are many of kinds of things that can fit into the BuildRequires category.  For the sake of argument, however, I'd say that the BuildRequires stuff tends to be a superset of the runtime requirements.

So, I'm just going to make the decision that the build requirements are the same as the runtime requirements even if you don't technically need all the runtime modules to do the build for Orca.

Created attachment 139802 [details] [review]
Patch to configure.in that was committed

After trials and tribulations, this was the primary patch committed.  The main thing is does is:

0) Models some of the format after the gtk+ configure.in since those guys are smarter than we are.

1) Eliminates stuff we no longer need (e.g., shared library building support), which speeds up the run of autogen/configure.

2) Adds a PKG_CHECK_MODULES line that captures (ultimately) most of everything Orca needs at run time:

PKG_CHECK_MODULES(orca, \
        dbus-python >= 0.83.0 \
        gnome-python-desktop-2.0 >= 2.24.0 \
        libspi-1.0 > 1.24.0 \
)

3) As an extra check, just in case PKG_CHECK_MODULES doesn't capture everything, adds a bunch of checks for Python modules that we know we need.

4) Limits the absence of some things (e.g., brltty) to warnings if Orca can run without them.

5) Eliminates orca.spec.in per an IRC discussion with vuntz on #release-team.

This patch covers the bulk of the changes, but some others went in via these changes:

commit 4691e3bb41c4725587df2b3fb208cd0662b112da
commit 411cd476d7c7e21496acb7e941f7b50cc3152641
commit 91e121df840eae13bdddad51be53a411893171fa
commit cbe6eb94faaa37d05fe84f8d7b48bc00ef39f091
commit 155307be8c2592aabff9b92ddcc1fe0c4e45698a
commit d070d5099f7b7003fb7b4677bdda66fc3531d7d3