Loïc Minier <[EMAIL PROTECTED]> writes:
> On Thu, Jan 11, 2007, Goswin von Brederlow wrote:
>> Replacing the /usr/lib/pango/1.5.0/module-files.d/* with
>> /usr/lib32/pango/1.5.0/module-files.d/* fixes this problem for 32bit
>> but obviously breaks 64 bit.
>
> Can we use /usr/lib32 in all cases or should we use /usr/lib32 only for
> the pango embedded in ia32-libs? IOW, can I change the pango/i386
> package to ship /usr/lib32/pango/1.5.0/module-files.d and the the
> pango/amd64 package to use /usr/lib64/pango/1.5.0/module-files.d -- and
> hence have no /usr/lib/pango/1.5.0/module-files.d except on other
> arches (m68k, arm, ...)?
On amd64 /usr/lib64 is a link to /usr/lib maintained by libc6 and if
you put any files in there then dpkg will complain on the next libc6
update about a file conflict for /usr/lib64. So you must ship the file
in /usr/lib even if you use /usr/lib64 to open them.
As for using /usr/lib32 on i386 that is totaly up to you. On i386
/usr/lib32 does not yet exist but I don't see a reason not to create
it. Note that you can't have system libraries in /usr/lib32 since it
is not a default lib dir on i486.
> Is it more useful to turn on the support for /usr/lib32 at runtime
> only, or is it ok to unconditionally setup this support at build time?
How would you turn it on at runtime? Policy forbidds to set an
environment variable in a package. You could have an /etc/pango/config
that tells libpango i386 to use lib32 and we ship it in ia32-libs-gtk
only. But isn't than more work than always using lib32?
Alternatively you could include the gnu tripple in the path to the
modules file like gcc uses:
/usr/lib/pango/x86_64-linux-gnu/1.5.0/module-files.d/
/usr/lib/pango/i486-linux-gnu/1.5.0/module-files.d/
or like cross-compilers:
/usr/x86_64-linux-gnu/lib/pango/1.5.0/module-files.d/
/usr/i486-linux-gnu/lib/pango/1.5.0/module-files.d/
> --
> Loïc Minier <[EMAIL PROTECTED]>
MfG
Goswin
