CDBS repo?

[Jeff and I were discussing the future of CDBS, and a feature where it
could automatically create -dbgsym packages for debugging using the
dh-strip feature.]

Another thing I thought of is to automate building of 32-bit versions of
libraries for x86_64.  I made a few changes to the ia32-libs-gtk

  http://www.laclinux.com/~karlheg/experimental/

... to get it to work right.  I can run 'realplay' now.

The changes are in the patch to the gtk+ source that's in the source to
that.  In brief, what was wrong is that it was using the
default ./configure settings to build the gtk+ libraries, and so they
were looking in /etc/gtk and /usr/lib/gtk for their stuff.  When I tried
to run 'realplay', it could not load it's pixmaps, since gdkpixbuf needs
to find shared objects that are used to load the images.  The ones it
needs are in /usr/lib32, but it was looking in /usr/lib.  The
debian/rules was moving the objects, but could not patch the binaries to
make them look in the new location.

I added some code in debian/rules that checks for 'ia32-libs' in the
DEBIAN_BUILD_OPTS, and if that's present, it uses lib32 rather than lib,
and puts the /etc files in /etc/ia32-libs/*.  If the same thing is done
to the libpango, the 'pangohack.so' can go away.  There may be other
libraries that need similar modifications.

Q: Could this be essentially why something is not finding a locale file
in the Oracle 10 problem?  Could it be looking in the wrong place?  You
tell me and we'll both know; I don't know enough about it.

Another option would be to modify those libraries in such a way that
they use an environment variable to find those conffiles and shared
objects.

I think that having a separate build for them is fine.  What I don't
like is having to compile the ia32-libs in an i386 chroot.  It does not
build on pure64 with the -m32 switch, as far as I can tell.  I don't
have time right now (college) to learn more about it.

-- 
Karl Hegbloom <hegbloom at pdx.edu>