Date: Tue, 12 Jan 2021 13:48:42 -0500 From: Daniel Eischen <deischen@freebsd.org> To: Mark Johnston <markj@freebsd.org> Cc: Kristof Provost <kp@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: libifconfig non-private in 13? Message-ID: <9CA63E1A-C206-4FF3-9B29-DB630D06D4A7@freebsd.org> In-Reply-To: <X/3eCk7gj6broQYt@raichu>
index | next in thread | previous in thread | raw e-mail
> On Jan 12, 2021, at 12:37 PM, Mark Johnston <markj@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. -- DEhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9CA63E1A-C206-4FF3-9B29-DB630D06D4A7>