| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 21/09/13 03:06 PM, William Hubbs wrote: |
| 5 |
> All, |
| 6 |
> |
| 7 |
> this is a followup to the original message that started this |
| 8 |
> thread. |
| 9 |
> |
| 10 |
> A case has been made for librc, but not libeinfo. There could be |
| 11 |
> reasons to allow the librc functionality to stay around, but I'm |
| 12 |
> not convinced wrt libeinfo, especially since there are no |
| 13 |
> consumers. |
| 14 |
> |
| 15 |
> Does anyone see a reason we should keep the einfo/eerror/etc c |
| 16 |
> functions in a public API? |
| 17 |
> |
| 18 |
> William |
| 19 |
> |
| 20 |
|
| 21 |
IIRC we still don't have an openrc-replacement script in the tree for |
| 22 |
the /etc/init.d/function.sh symlink to target. Since libeinfo is |
| 23 |
already public, why not instead of making it private we go the other |
| 24 |
way -- keep it public, package it out separately in the tree, and make |
| 25 |
openrc (and others from bug 373219 and elsewhere) depend on it? |
| 26 |
|
| 27 |
grobian already has a fork of libeinfo with an independent build |
| 28 |
system and a functions.sh wrapper; we could leverage that for anything |
| 29 |
missing from a standalone package in portage. Probably the whole deal |
| 30 |
could be done in under an hour, and it's already long-proven code |
| 31 |
since it's what openrc and prefix has been using for years. |
| 32 |
|
| 33 |
Out of curiosity, what is the reasoning behind making these libs private? |
| 34 |
-----BEGIN PGP SIGNATURE----- |
| 35 |
Version: GnuPG v2.0.20 (GNU/Linux) |
| 36 |
|
| 37 |
iF4EAREIAAYFAlI98aMACgkQ2ugaI38ACPCTcQD9HIqOTlhia/ktPFANAZdJbfEv |
| 38 |
DqOh7CUCULZw+FqkOpQBAISPbWdsg+flecvnv5OfWGsnLqnYK6GPG4e23KwDyz1e |
| 39 |
=OCdp |
| 40 |
-----END PGP SIGNATURE----- |
Archives