-----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-----
