Too many libconfig's

Bryan Blackburn blb at macports.org
Tue Nov 18 18:57:57 PST 2008


On Tue, Nov 18, 2008 at 07:12:39PM -0600, Ryan Schmidt said:
> On Nov 18, 2008, at 18:57, David Evans wrote:
[...]
>>
>> The homepage for our libconfig is
>>
>> http://www.rkeene.org/oss/libconfig
>>
>> Found the libconfig that ntfsprogs is looking for at
>>
>> http://www.hyperrealm.com/libconfig/

There's also

<http://sourceforge.net/projects/libconfig/>

>>
>>
>> So the question is how to differentiate these two packages:
>>
>> 1) Current libconfig port  is not referenced by any other port based on
>> grep of the current dports tree. Could replace this one with the new one
>> but they really are different packages and someone might be using the
>> current one somewhere.

That could be confusing, maybe someone is using it currently.

>>
>> 2) Commit the new libconfig package as libconfig-new or the like
>> (suggestions welcome) and make ntfsprogs depend upon it.

Definitely the way to go, though a better name I think would be
libconfig-cxx (since it has C++ support as well) or libconfig-lgpl since
that's the license it uses.  Or other options maybe?

>>
>> 3) Rename the existing one (libconfig-old) and make the new one  
>> libconfig.
>>
>> 4) Something else.
>>
>> Ideas and suggestions are solicited and appreciated.
>>
>> By the way, the newer package has both C and C++ interfaces which may be
>> the story behind this ticket:
>>
>> http://trac.macports.org/ticket/14035
>
> (3) is problematic because there is no built-in way to rename ports.  
> Sure, you can "svn mv" the old port to a different directory, but  
> MacPorts doesn't know you did that; any users who have the old port  
> installed will think it's the same as the new port since they'll share the 
> same name.
>
> You may want to contact the authors of both software packages. Ask if  
> there is any relation between the two, if one is meant to replace the  
> other, or what. And if not, if they have any suggestions for  
> disambiguating the names (this problem won't be unique to MacPorts and 
> should ideally be fixed upstream).

Unfortunately I think this is just a case where a library is needed and
handles config info, so several different people all came up with
'libconfig'.

Bryan



More information about the macports-dev mailing list