libifconfig non-private in 13?

[Kristof Provost]

On 12 Jan 2021, at 18:36, Mark Johnston wrote:
> On Mon, Dec 21, 2020 at 09:02:00PM +0100, Kristof Provost wrote:
>> Hi,
>>
>> Libifconfig was marked as private (and experimental) back in 2016.
>> It’s since made some strides and has grown a few users. Ifconfig 
>> now
>> depends on it as well.
>>
>> While it’s far from finished it’d be more useful for some users 
>> if
>> it were public. That would at least imply some level of API/ABI
>> stability, which is why I’m bringing it up here before pulling the
>> trigger.
>>
>> Does anyone see any reasons to not do this?
>
> I note that libifconfig doesn't version its symbols.  In other words,
> compatibility-breaking changes generally require a shlib version bump,
> which will be painful for out-of-tree consumers (and if we don't 
> expect
> to have such consumers there's no reason to make it a public library).
> Symbol versioning isn't perfect but makes some kinds of breaking 
> changes
> easier to handle, and might be worthwhile here since I'd expect
> libifconfig to keep evolving for a while.  Should we add a symbol map
> ahead of making libifconfig public?

Yes, we should to that, as well as write up a man page for the current 
API.
I did make a start on the man page a while back, but spare time has been 
hard to come by.

Best regards,
Kristof