Re: Common knowledge in jhbuild for funny modules

On 8/8/06, Federico Mena Quintero <federico ximian com> wrote:
PolicyKit wants to install /lib/security/  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/ 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 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?

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]