Renaming a shared library in the port-framework to match FreeBSD naming schemes?

[O. Hartmann]

On 11/24/10 02:58, Andrew W. Nosenko wrote:
> On Tue, Nov 23, 2010 at 03:42, O. Hartmann
> <ohartman at mail.zedat.fu-berlin.de>  wrote:
>> On 11/23/10 02:14, Andrew W. Nosenko wrote:
>>>
>>> On Mon, Nov 22, 2010 at 22:20, O. Hartmann
>>> <ohartman at mail.zedat.fu-berlin.de>    wrote:
>>>
>>> But there lives another problem: Xerces people doesn't expect parallel
>>> installation of the "evelopment" part of Xerces-C (headers,
>>> pkg-config, etc).  At least it seems so by listing the libxerces-c
>>> package from Ubuntu.
>>
>> I guess so, but some ports of the FreeBSD ports (i.e. textproc/xalan-c) want
>> xerces-c2 (which is 2.7.0). I try build xalan-c with the new xerces-c3 and
>> see if it can handle the new header and libraries.
>>
>>>
>>> I see three variants:
>>> (1) simple: just mark these ports (c2 and c3) as conflicting,
>>
>> ... in my testcase I did.
>
> And, for my personal taste, it is the best option.  Be close to
> upstream as much as possible, IMHO, is the best way.
>
>>> (2) semi-simple: split each xerces-c port at the two: run-time and
>>> development.  Runtime contains a shered library, development contains
>>> anything other.  Mark development parts as conflictitng.
>>
>> ... well, in such a case we converge much to the weird Linux mess, I guess.
>>
>>> (3) move each port away from each other's way: move headers into own
>>> versioned deirectory (e.g. from include/xercesc/ to
>>> insclude/xercesc-3.1/xercesc/), drop libxerces-c.so (if any -- I don't
>>> know), rename pkg-config (.pc) file, and static library (if any), may
>>> be something yet another, like documentation -- need to look at the
>>> actual install.  All these changes hidden from the users through
>>> pkg-config's .pc, therefore only one problem for developers will be
>>> changed (non-standard name of the .pc file, i.e. pkg-config's module).
>>
>> ... this would bring up other complications for ports expecting libs and
>> headers at places where the solo installation normally resides.
>>
>>>   But ATM I see no better way to allow parallel installation of the
>>> packages that aren't intended for parallel installation by theirs
>>> authors...
>>
>> I tend to install it as a unique port with conflicts activated. Hope there
>> are no further conflicts other than xalan-c.
>
> And I have some feelings that either existing xalan-c able to compile
> against current xerces-c or there is newer version that able.
>

I tried to build xalan-c against xerces-c 3.1.1 and it doesn't work. The 
Apache website for Xalan explicitely says that Xalan-c 1.X is for 
Xerces-c 2.7. And I did not figure out where they'he hide a newer 
version compatible to the new Xerces-C 3.1.1.

Also, ports graphics/visionworkbench, graphics/gdal, graphics/osg 
(Openscene Graph) also depend on Xerces-c 2.7, as far as I see.

That leaeves me with the option of having a additional port xerces-c3 
separated from the other xerces-c2. This is messy ...