svn commit: r325739 - in head: lib/libcasper/services lib/libcasper/services/cap_syslog share/mk

[John Baldwin]

On Sunday, March 18, 2018 01:07:38 PM Mark Johnston wrote:
> On Sun, Mar 18, 2018 at 03:20:39PM +0100, Mariusz Zaborski wrote:
> > On Mon, Mar 05, 2018 at 11:19:16AM -0600, Mark Linimon wrote:
> > > On Mon, Mar 05, 2018 at 11:13:58AM -0500, Mark Johnston wrote:
> > > > The growing divergence with stable/11 makes it rather painful to
> > > > maintain a port, depending on libcasper, that aims to work on both 11
> > > > and head.
> > > 
> > > Even an MFC won't help you, in the medium-term.
> > > 
> > > e.g. via https://www.freebsd.org/security/#sup, even if the MFC made it
> > > into 11.2, you would still have several months of supporting the old
> > > one.  (The FreeBSD package builds are based on the oldest supported
> > > point release from a branch.)  The current estimate for 11.2 is late June.
> > > 
> > > mcl
> > 
> > Hi,
> > 
> > Sorry for delay I just get back.
> > 
> > Yes I can integrate all my changes in libcasper and I guess libcapsicum.
> > I'm did do a lot of integrations to stable so I have one question -
> > if I understand correctly all changes which change API/ABI but are
> > pointed as SHLIB_MAJOR I can safety integrate.
> > 
> > Mark what else can I do?
> 
> Sorry, I don't quite follow. I don't think SHLIB_MAJOR bumps can be
> MFCed: what happens if an SA is later released for the library in
> question?

We have MFC'd them in the past I believe and rolled the <N-1> shlib into
the misc/compatXX package (so that one might need misc/compat11 to run
older 11.x binaries even on an 11.x host).  We haven't done that nearly as
often since adding symbol versioning though.  I don't know if we ever had
to deal with merging an SA to an old library version though.

-- 
John Baldwin