Bug#467069: pango1.0: biarch support

[Javier Serrano Polo]

Package: pango1.0
Version: 1.18.4-1
Severity: wishlist

El dj 21 de 02 del 2008 a les 21:03 +0100, en/na Loïc Minier va
escriure:
> On Thu, Feb 21, 2008, Javier Serrano Polo wrote:
> > I'm working on ia32 libraries support and I had to recompile pango,
> > using a different library path and an extra chrpath call.
> 
>  Hmm you shouldn't have to rebuild; copying the i386 build into
>  ia32-libs is supposed to work.

I should note first I'm not using ia32-libs, ia32-libs-gtk or any other
library compilation. I'm using each library with its own package,
preserving dependencies. The scheme is initially described in #464796.

While most packages work out of the i386 box, by simple repackage,
others make use of modules or private libraries. These are accessed
through hard coded paths, so I need to configure with a different
library path.
I'm using /usr/lib32 instead of /emul/ia32-linux/usr/lib because it
should be portable to other 32 bit archs.

> > The final solution would be to build two new flavors (e.g., shared32 and
> > static32) but I need to get the dependencies in first.
> 
>  This was considered when multiarch was implemented, but it was
>  considered:
>  - complex and messy, especially with multiarch at the same time
>  - useless if we get multiarch

The paths I mentioned are currently working, even /usr/lib32 is
standard. I don't have any sign of another multiarch approach. Please
correct me if I'm wrong.
Anyway, I'll freeze the new flavors topic. It's useless without the
needed dependencies.

Going back to the rebuild, I'd need a simple way to set the library path
through DEB_BUILD_OPTIONS. pango1.0 is almost done. Packages gtk+2.0 and
libao have the same problem (and probably 22 more packages).
I'd like to know if I can count on you to help or accept my help, so I
can automate this more reliably.