From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 95D1C1381F3 for ; Sat, 21 Sep 2013 19:21:13 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E2EB2E0C62; Sat, 21 Sep 2013 19:21:08 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 23DFDE0C52 for ; Sat, 21 Sep 2013 19:21:08 +0000 (UTC) Received: from [192.168.1.160] (bas1-ottawa09-1168026725.dsl.bell.ca [69.158.172.101]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: axs) by smtp.gentoo.org (Postfix) with ESMTPSA id D1C3133E935 for ; Sat, 21 Sep 2013 19:21:06 +0000 (UTC) Message-ID: <523DF1A3.2090102@gentoo.org> Date: Sat, 21 Sep 2013 15:21:07 -0400 From: Ian Stakenvicius User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130823 Thunderbird/17.0.8 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: rfc: status of OpenRC's public API References: <20130914001606.GA29108@linux1> <20130921190629.GA6459@linux1> In-Reply-To: <20130921190629.GA6459@linux1> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: b04da010-0165-440b-9795-3fd7a3439530 X-Archives-Hash: b9a05078639ef35fa5451b2749f6e4e5 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 21/09/13 03:06 PM, William Hubbs wrote: > All, > > this is a followup to the original message that started this > thread. > > A case has been made for librc, but not libeinfo. There could be > reasons to allow the librc functionality to stay around, but I'm > not convinced wrt libeinfo, especially since there are no > consumers. > > Does anyone see a reason we should keep the einfo/eerror/etc c > functions in a public API? > > William > IIRC we still don't have an openrc-replacement script in the tree for the /etc/init.d/function.sh symlink to target. Since libeinfo is already public, why not instead of making it private we go the other way -- keep it public, package it out separately in the tree, and make openrc (and others from bug 373219 and elsewhere) depend on it? grobian already has a fork of libeinfo with an independent build system and a functions.sh wrapper; we could leverage that for anything missing from a standalone package in portage. Probably the whole deal could be done in under an hour, and it's already long-proven code since it's what openrc and prefix has been using for years. Out of curiosity, what is the reasoning behind making these libs private? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlI98aMACgkQ2ugaI38ACPCTcQD9HIqOTlhia/ktPFANAZdJbfEv DqOh7CUCULZw+FqkOpQBAISPbWdsg+flecvnv5OfWGsnLqnYK6GPG4e23KwDyz1e =OCdp -----END PGP SIGNATURE-----