Loïc Minier <[EMAIL PROTECTED]> writes:
> On Sat, Jan 13, 2007, Goswin von Brederlow wrote:
>> The patch had a minor bug for /etc/pango32. It tested for /etc/pango32
>> but then overwrote the reult with /etc/pango anyway. Which is ok as
>> there seems to be no architecture specific file left in /etc/pango,
>> only the font aliases.
>
> It's not only that, we don't use pango.modules under Debian anymore,
> but /usr/lib/pango/1.5.0/module-files.d/*.modules. This is why the
> Ubuntu patch wont work as is.
>> I fixed that and also made the patch less conditional. The test for
>> uname is not needed and actualy breaks stuff. You might want to have
>> an uname of "i686" for your www-browser so some flash or java plugin
>> works. But you still want to be able to read pdf links too. 'linux32
>> www-browser' would result in acroread being started with uname 'i686'
>> and then pango fails.
>
> On the other hand, doesn't that save a stat() when the kernel is
> detected to not be 64 bits? This is in the startup of all libpango
> using apps.
Which means the kernel has to load /usr into cache and check if lib32
exists. That shouldn't even cause a disk access, just cache. I don't
see that as a problem.
>> I also added a g_getenv("PANGO32_SYSCONFDIR"); for symetry.
>> Are you sure the SYSCONFDIR part is still needed? The modules conffile
>> used to be there iirc but no more. I can't think of a reason why 32bit
>> and 64bit would need different fonts:
>
> No, it's not; the sysconfdir parts of pangohack and of the patch are
> irrelevant for the current layout of the *pango* package. The Gtk
> package is not at this level in unstable though.
Ok, so we agree that the SYSCONFDIR part is now obsolete. That
certainly simplifies things.
>> +#if defined(__linux__) && defined (__i386__)
>> + if (!access("/usr/lib32/pango", R_OK|X_OK))
>> + return "/usr/lib32/pango";
>> +#endif
>> return LIBDIR "/pango";
>> #endif
>> }
>
> I don't think this is the place to patch. IMO, we should not touch
> "libdir", only prepend
> /usr/lib32/pango/1.5.0/module-files.d
> to the search path on i386.
We have to replace the /usr/lib/pango/1.5.0/module-files.d with
/usr/lib32/pango/1.5.0/module-files.d on amd64 32bit otherwise every
single 64bit module generates a few lines error message.
Maybe there are better ways to solve this but this is simple and works
and the patch already exists.
> The biggest question I have is whether we should check the kernel at
> runtime or not and include this path conditionally; pros for using
> uname(): might save a stat(); cons: not clear what values the kernel
> may return.
Debian Personality uname needed dir
i386 32bit i[3456]86 /usr/lib
i386 64bit x86_64 /usr/lib
amd64 32bit i686 /usr/lib32
amd64 64bit x86_64 /usr/lib32
ia64 32bit i686 (or i[345]86?) /usr/lib32
ia64 64bit ia64 (?) /usr/lib32
Uname isn't helpfull here and access() is way simpler than asking dpkg
for the architecture, which would be the only way to be sure at runtime.
> Goswin, as ia32-libs-gtk is supposed to work on ia64, could you tell me
> whether "defined (__ia64__)" the correct test for this platform?
Should be. But why would you care? The ia64 libpango does not need the
test, only the i386 one.
> Are there other 64-bits platforms to be supported?
Only amd64 and ia64 support running i386 binaries. There is also the
possibility to use qemu on other archs but nothing is packaged for
that. Without the uname check it would work in qemu too no matter what
uname returns there, and I have no idea what it does return.
> Do you intend to conflict with other packages providing pango module
> files?
Why would I? With the stat test for /usr/lib32/pango there is no
change for any package except for ia32-libs-gtk. Only ia32-libs-gtk
would have /usr/lib32/pango and ia32-libs-gtk is the only package with
32bit pango modules for amd64. Nothing to conflict against.
> In the initial bug report, you requested support for /usr/lib64 in the
> 64-bits pango; first, I don't see an ia32-libs-gtk for 32-bits arches,
> and second, could you give me a list or arches and "defined()" tests
> for these arches?
There isn't an amd64-libs-gtk package (yet?) but it is kind of a
chicken&egg problem. Without support for /usr/lib64 there can't be
one.
The number of requests for 32bit gtk support for amd64 made us (and
ubuntu way before that) create the ia32-libs-gtk package. I haven't
seen requests for 64bit gtk support on i386 yet so we can ignore that
for Etch. And for Lenny we can hopefully just use multiarch finaly.
MfG
Goswin
