svn commit: r364287 - head/ports-mgmt/pkg-devel

[Matthias Andree]

Am 07.08.2014 um 19:25 schrieb Baptiste Daroussin:

>> Matthias is talking about the SONAME Elf field.  For libxml2.so.2.9.1
>> it gives:
>>
>> % objdump -p /usr/local/lib/libxml2.so.2.9.1  | grep SONAME
>>   SONAME      libxml2.so.2
>>
>> This is what is recorded in the NEEDED field of programs/libraries
>> that depend on libxml2 and can be used for shared lib provides.
>>
> 
> That is exactly what we do use.
> 
> The problem is things like i386-wine are providing libxml2 as well which SONAME
> is also libxml2.so.2 how do we differentiate both ?

I don't fully oversee how it the i386-wine port works, and am not eager
to get acquainted with it, but let's pretend it "just works" for the
sake of the argument, and that reading its pkg-plist suffices.
Feel free to fill me in on additional details.

i386-wine is not providing a *system-wide* libxml2.so.2, because it's
not in the regular library search path. Meaning that i386-wine will not
be able to satisfy a regular LIB_DEPENDS of my random amd64 port.

So you cannot list i386-wine's private libxml2.so.2 as a global
"provides".   Easy identification is to prefix the path relative to
$PREFIX to the SONAME if the SONAME is from a file not in the default
library search path.  This hinges on the assumption that the path+SONAME
is unique.

You could record that as lib32/libxml2.so.2, libxml2.so.2:prefix=lib32,
or thereabouts.  The scheme should be unique and extensible.