On Sat, Jan 13, 2007, Goswin von Brederlow wrote: > 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.
Yeah, same here, it's my preferred solution as well from the two; I wonder why Ubuntu folks picked uname(). > Ok, so we agree that the SYSCONFDIR part is now obsolete. That > certainly simplifies things. (Not for Gtk, but this is far more complex and I prefer getting things done cleanly on Pango first which is simpler and then doing the same on Gtk plus the needed extra hacks.) > 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. Yes, but I don't consider it wise to change the internal definition of libdir for pango; I prefer changing the specific path to /usr/lib/pango/1.5.0/module-files.d to not use libdir but lib32dir for example or something similar. Of course, one could check how pango uses its libdir in the whole pango source code, but pango_get_lib_subdirectory() is part of the ABI and this could change in future releases, I prefer not taking the risk, if the code relative to modules changes, at least the patch wont apply. > 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 Nice. > 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. Ok, that settles it then. > > 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. I cared for the 32-bits support under ia64, but since we'll use the i386 *.debs, it's not needed indeed. However, I do need it for the lib64 check in the amd64 version; is it "defined(__x86_64__)"? Could you complement the above list of arches / unames / personalities combination for powerpc / powerpc64 and sparc / sparc64 if it makes sense? Does it make sense to support m68k, arm etc. for a 64-bits personality? Or should this be revisited for bi-arch? Why not test for 32-bits/64-bits instead of defined(__i386__) or defined(__x86_64__)? > > 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. Hmm, it was simpler for me to unconditionnally prepend the /usr/lib32 path before /usr/lib; but it's cleaner to disable /usr/lib when /usr/lib32 is found. > > 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. Ok, but we can implement it nevertheless, it's the same amount of work. Could you hand me the relevant arches/"defined()" tests couples? Of perhaps we can switch to a 32-bits/64-bits test. > 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. Yeah, I am aware of the high demand and use of this setup; it's a terrible pity that your package went into etch one month ago, and that you file RCs for this support at this point of the release cycle... For lenny, it might also make sense to work on biarch; there are some functional package in the archives, and its support is close to the requests in this report. -- Loïc Minier <[EMAIL PROTECTED]>
