Re: find libxml2 using pkg-config

Noah Misch <noah(at)leadboat(dot)com> writes:
> On Wed, Mar 20, 2013 at 05:17:11PM -0400, Peter Eisentraut wrote:
>> On 3/4/13 1:36 PM, Noah Misch wrote:
>>> Do you have in mind a target system exhibiting a problem? CentOS 6 ships a
>>> single xml2-config, but its --cflags --libs output is the same regardless of
>>> the installed combination of libxml2-dev packages. Ubuntu 13.04 does not ship
>>> 32-bit libxml2, so it avoids the question.

>> It does, because you can just install the libxml2 package from the
>> 32-bit distribution. (So there will no longer be packages in the 64-bit
>> distribution that actually contain 32-bit code, at least in the long run.)

> Ah, interesting. Is there a plan or existing provision for arbitrating the
> resulting /usr/bin contents when mixing packages that way?

There is not. With my other hat on (the red fedora), this annoys me
tremendously. I believe the rationale is that users shouldn't really
care whether /usr/bin/foo is a 32-bit or 64-bit executable as long as it
gets the job done ... but that's a pretty thin rationale IMHO. In any
case, the existing design for multilib only takes care to allow parallel
installation of 32-bit and 64-bit *libraries*, not executables. For the
latter, I think what happens is you get the executables from whichever
package you installed last. At least on Red Hat-based systems.
Possibly other distros have a saner design here.

>> I think at this point, the issue is probably too obscure, and the people
>> affected by it hopefully know what they are doing, so it might not be
>> important in practice. In light of the other flaws that you have
>> pointed out, I'd be fine with withdrawing this patch for now. But we
>> should keep an eye on the situation.

> Agreed. Convincing a package to properly attach to its dependencies is no
> fun. I wanted to like this patch.

In the end, I think this is mostly the territory of packagers. We can't
force the right result as a platform-agnostic upstream source, and I'm
not sure we should try. I would suggest that any changes in this area
be driven by actual complaints from actual packagers.

regards, tom lane