On Sun, Jan 14, 2007 at 04:25:43PM +0100, Loïc Minier wrote: > > It's still bletcherous special-casing IMO. Maintainer's choice whether to > > adopt this solution in the short term, but it's just going to mean changing > > again as we move to a solid multiarch solution.
> It's hard for me to get a sane overview of what's supportable and > what's not, what's going to become supported, and what will not. E.g., > I've heard that bi-arch was something working well and not too complex > to implement, yet X libs don't support it and I've heard they don't > want to support biarch; some people also tell me that biarch is complex > and a kludge as well. I don't know why anyone would claim biarch is "working well and not too complex". Every single biarch package requires special-cased build rules to build extra packages on a per-arch basis, and bloats the archive with extra packages that are essentially copies of the binaries for the other arch. > On multiarch, some people tell me I should keep /usr/triplet/lib > because it necessarily works due to cross-compilers, other tell me > /usr/lib/triplet is the true multiarch path. I think it's rather irresponsible for Goswin to advocate re-using the cross-compiler paths in a bug report against a single library, when TTBOMK there's been no discussion about this in the wider community that's looking to advance multiarch as a standard. > I've heard a lot of times that ia32-libs is very ugly (and I concur), > but I've also noticed it's widely used and popular. Lots of things are both ugly and popular... :) > Thanks for all the participants in the discussion, I think I am > inclined to: > - keep the switch of the multiarch path to the "standard" multiarch > path > - do not aim at reusing this for biarch or at implementing biarch, as > my current feeling is that it won't ever be supported in X (which is > a pre-requisite) and will be reverted and dropped > - implement ia32-libs support: > * by using /usr/lib32 and /usr/lib64 in the code instead of > /usr/lib/triplet to avoid the necessity of a conflict in the future > * on i386, ia64, and amd64 (and not anything else as no demand or use > case exist and this will be obsoleted with multiarch) > * by checking a different module path (and not by redefining libdir) > for consistency in the build process and internally to pango and > for clients of the pango ABI No (further) objection to any of the above. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/
