Date: Fri, 16 May 2014 17:30:38 -0400 From: Julio Merino <jmmv@freebsd.org> To: "Simon J. Gerraty" <sjg@juniper.net> Cc: freebsd-arch@freebsd.org Subject: Re: Make atf libraries private Message-ID: <CAFY7cWANsR%2B52GSGLjc5Qt3nFMQ-gSBhmEcuwH2UKJqavQ5TPQ@mail.gmail.com> In-Reply-To: <20140516041003.E4469580A1@chaos.jnpr.net> References: <E0AFE433-3D7F-494C-BC23-02FFD62945CC@freebsd.org> <20140516041003.E4469580A1@chaos.jnpr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, May 16, 2014 at 12:10 AM, Simon J. Gerraty <sjg@juniper.net> wrote: >>I'd like to make the libatf-c and libatf-c++ private, both in CURRENT _and_ in >> stable/10. > > Can you briefly explain why Oh sure. Basically because I do not want the potentially-ancient ATF libraries in base to leak to external components, and because I do not want to have to worry about maintaining compatibility with these ancient versions when the time comes. (This will start happening as soon as FreeBSD 10 ages, for example.) At some point, ports that install tests (lutok, kyua, shtk, ...) *will* require a newer version of atf. Being able to just update devel/atf within ports and get the newer versions of the other ports working is trivial. Having to coordinate the ports updates with newer FreeBSD releases just so that those ports can be updated will be a nightmare. It seems nicer to me to restrict the ATF libraries in base to what FreeBSD needs them for: i.e. the ATF-based test programs inside the tree. Anything else can just install the external package from ports OR it can explicitly link against the private library -- clearly knowing what the compatibility-related consequences of doing so are. (As an aside, it seems that FreeBSD, as a project, wants to move as many libraries into private as possible partly for the reasons mentioned above. This came up during the devsummit. I'm wondering if this was documented anywhere...)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFY7cWANsR%2B52GSGLjc5Qt3nFMQ-gSBhmEcuwH2UKJqavQ5TPQ>