From: Ian Stakenvicius <axs@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Re: rfc: status of OpenRC's public API
Date: Sat, 21 Sep 2013 15:21:07 -0400 [thread overview]
Message-ID: <523DF1A3.2090102@gentoo.org> (raw)
In-Reply-To: <20130921190629.GA6459@linux1>
-----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-----
next prev parent reply other threads:[~2013-09-21 19:21 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-14 0:16 [gentoo-dev] rfc: status of OpenRC's public API William Hubbs
2013-09-14 1:04 ` Alexandre Rostovtsev
2013-09-14 3:48 ` William Hubbs
2013-09-14 4:47 ` Alexandre Rostovtsev
2013-09-14 13:17 ` Gilles Dartiguelongue
2013-09-14 16:35 ` William Hubbs
2013-09-14 20:59 ` Pacho Ramos
2013-09-14 23:07 ` William Hubbs
2013-09-14 23:20 ` Pacho Ramos
2013-09-15 22:39 ` Gilles Dartiguelongue
2013-09-15 4:36 ` Doug Goldstein
2013-09-16 11:28 ` [gentoo-dev] " Steven J. Long
2013-09-16 22:20 ` Rich Freeman
2013-09-18 12:05 ` [gentoo-dev] " Steven J. Long
2013-09-21 19:06 ` [gentoo-dev] " William Hubbs
2013-09-21 19:21 ` Ian Stakenvicius [this message]
2013-09-24 18:15 ` William Hubbs
2013-09-24 18:22 ` Ian Stakenvicius
2013-09-25 20:04 ` William Hubbs
2013-09-25 20:27 ` Mike Gilbert
2013-09-25 21:01 ` William Hubbs
2013-09-25 21:45 ` Mike Gilbert
2013-09-25 23:08 ` [gentoo-dev] " Michał Górny
2013-09-30 12:39 ` Douglas Freed
2013-09-30 16:50 ` William Hubbs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=523DF1A3.2090102@gentoo.org \
--to=axs@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox