libifconfig non-private in 13?

[Mark Johnston]

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?