On Sat, Jan 13, 2007, Steve Langasek wrote:
> That shouldn't prevent using /usr/lib/i486-linux-gnu/pango as a modules
> subdir, because binutils doesn't need to know about /that/ path. It does
> prevent moving libpango.so to /usr/lib/i486-linux-gnu until binutils
> supports it.
Aurélien commented that using /usr/lib/i486-linux-gnu/pango might mean
a conflict with ia32-libs-gtk when we move to multiarch; if instead I
use /usr/lib32, respectively /usr/lib64, I wont have to add the
conflict in the multiarch era.
> If the two paths are coupled in an inconvenient fashion in the pango build
> rules such that the maintainers prefer to keep them all in one directory,
> then yes, /emul/blah/barf is the best option for now.
(Yes, you fully understand the problem, I'm okay to add module pathes,
but I don't want to lie to the internal "get lib dir" function of pango
or patch it to not return the real libdir (since the lib isn't in
there), especially because this function is part of the ABI and is used
for different things. It's even worse in Gtk.)
> 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.
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'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.
This is absolutely not a rant about you or anyone else in the bug, I
think all participants have a good technical picture, but very
different opinions.
I wish we would have a technical leader on these subjects who would
have the authority to go forward on the subjects and who would follow a
spec writing process to reach consensus and produce:
- specs for implementing multiarch in packages (looks like this is
going to happen long term): where we currently are, how to implement
it fully, special cases, how to permit building it conditionally
right now (e.g. I used DEB_BUILD_OPTIONS=multiarch), etc.
- specs for implementing biarch in packages (looks like this started
happening, but finally has too many *opponents* which will prevent it
from happening): where we currently are, how to implement it fully,
special cases, when it makes sense, on which arches, etc.
- specs for implementing packages usable in ia32-libs in the sanest way
for the future (e.g. when multiarch will be there) -- looks like some
packages will continue to happen short term and this will be
obsoleted with multiarch
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
Now would be a good time to shout if I didn't understand something,
if you think one of the above choices is not the best, or if some
arguments are missing from the discussion! :)
--
Loïc Minier <[EMAIL PROTECTED]>
