Date: Tue, 12 Jan 2021 12:36:10 -0500 From: Mark Johnston <markj@freebsd.org> To: Kristof Provost <kp@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: libifconfig non-private in 13? Message-ID: <X/3eCk7gj6broQYt@raichu> In-Reply-To: <1EB6D7ED-F370-42EA-AC66-93D8BC96F29C@FreeBSD.org> References: <1EB6D7ED-F370-42EA-AC66-93D8BC96F29C@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?X/3eCk7gj6broQYt>