libifconfig non-private in 13?

[Daniel Eischen]

> On Jan 12, 2021, at 12:37 PM, Mark Johnston <markj at freebsd.org> 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?

Perhaps there are exceptions, but I would suggest that any new base library being made public provide versioned symbols.

--
DE