Re: Common knowledge in jhbuild for funny modules

["Elijah Newren" <newren gmail com>]

On 8/8/06, Federico Mena Quintero <federico ximian com> wrote:
> PolicyKit wants to install /lib/security/pamblahblah.so.  Since I don't
> run jhbuild as root, and I definitely don't want it to mess with my
> system installation, I need to
>
> 1. wait for the (already painful) jhbuild process to reach PolicyKit,
> and watch it fail.
>
> 2. Parse the error in my head.  Decide that installing stuff to system
> directories is stupid if I'm running jhbuild.
>
> 3. Look in PolicyKit/configure.in to see if it has an option to set an
> alternate path.
>
> 4. Find the option, and pass --with-pam-module-dir=/home/federico/blah
>
> Should this kind of knowledge be encoded in jhbuild somewhere?  Or
> should modules detect that they are not being installed to the system
> location, and so it really doesn't make sense for them to try to install
> stuff in system directories?

/me starts cheerleading federico on

I don't know the answers, but the building-gnome nightmare is long
overdue for discussion.

> Then, we have avahi, which lists dbus-python as a dependency.  In turn,
> jhbuild requires pyrex in order to build dbus-python.  However, pyrex
> is *not* installed as part of jhbuild's bootstrap installation of
> Python.  So, dbus-python is unbuildable.

This one has actually been fixed.  For a long time, jhbuild did not
support distutils modules, so jhbuild could not build pyrex.  See bug
311563.  If someone is still affected by this, they need to update
their copy of jhbuild and re-build the bootstrap modules.  But it was
an issue for a *long* time; several months IIRC.

> My WSOP student wasted about three weeks trying to get jhbuild to work
> up to Evolution.  It shouldn't be this painful.

Magnus Therning spent a similar amount of time recently, with the gory
details archives on the gnome-love list.  I totally agree with you.


Most of the build issues are due to the fact that we allow
dependencies on cvs versions of freedesktop.org modules.  I'd like to
propose that we move away from that, and just pick certain tarball
versions to depend on at the beginning of a release; and require
specific proposals to allow dependencies on newer tarball versions if
issues come up.  Thoughts?  Comments?