| 1 |
On Wed, Sep 25, 2013 at 7:08 PM, Michał Górny <mgorny@g.o> wrote: |
| 2 |
> Dnia 2013-09-13, o godz. 19:16:06 |
| 3 |
> William Hubbs <williamh@g.o> napisał(a): |
| 4 |
> |
| 5 |
>> OpenRC currently has a public api, consisting of librc and libeinfo |
| 6 |
>> (rc.h and einfo.h are the headers); however, I do not know of any |
| 7 |
>> released software that uses these, so, if there is nothing, I am |
| 8 |
>> considering making this code private to OpenRC and getting rid of the |
| 9 |
>> API. |
| 10 |
> |
| 11 |
> I won't oppose since I don't use OpenRC anymore and therefore my |
| 12 |
> opinion doesn't really matter here. However, I can't help but notice |
| 13 |
> a particular trend since Roy left the project. I see that OpenRC is |
| 14 |
> slowly regressing towards baselayout-1. |
| 15 |
> |
| 16 |
> First the oldnet thingie being made the default back. While I can |
| 17 |
> understand why people wanted it so badly, this doesn't make this less |
| 18 |
> of a carousel for Gentoo users. I mean, changing defaults with every |
| 19 |
> maintainer change. |
| 20 |
> |
| 21 |
> Then, functions.sh split. While itself good, I don't get what's |
| 22 |
> the benefit of converting the bash script from baselayout-1 while |
| 23 |
> a better one was provided with OpenRC. |
| 24 |
> |
| 25 |
> Now removing the public API because you don't care. While it may have |
| 26 |
> been unused indeed, it's simply crippling the thing, not making it more |
| 27 |
> useful. |
| 28 |
> |
| 29 |
> I'd like to see some kind of plan behind all this. Because as far as I |
| 30 |
> can see, it's just new maintainers slowly dropping all the new features |
| 31 |
> they don't care about without any specific vision. No offense intended. |
| 32 |
> |
| 33 |
> If OpenRC really wants to compete with systemd, it should at least have |
| 34 |
> some design plan, and you really should start working on providing |
| 35 |
> useful features rather than reverting, crippling and rewriting for |
| 36 |
> the sake of changing things. |
| 37 |
> |
| 38 |
> Just some material to think about. |
| 39 |
> |
| 40 |
> -- |
| 41 |
> Best regards, |
| 42 |
> Michał Górny |
| 43 |
|
| 44 |
I know I'm a bit late to this thread, but mgorny has a point. While |
| 45 |
it may not be immediately obvious, libeinfo is very useful, especially |
| 46 |
if your project aims to integrate nicely into a Gentoo system, by |
| 47 |
providing a standard set of printing functions with the formatting |
| 48 |
taken care of, resulting in output that is very familiar to users and |
| 49 |
is easy to scan with the eyes when looking for problems. One |
| 50 |
potential use-case would be reimplementing eselect in C. Not that I'm |
| 51 |
saying that this should happen, but anybody who attempts to do this |
| 52 |
would certainly appreciate having this bit taken care of for them. I |
| 53 |
would be more than willing to assist with maintenance of the library, |
| 54 |
even if split out into its own package, since it's small and rather |
| 55 |
simplistic, so there's unlikely to be any issues. I see no reason why |
| 56 |
we should remove something that isn't broken and doesn't cause us any |
| 57 |
maintenance burden. If somebody does open a bug against OpenRC |
| 58 |
because of an issue they're encountering while trying to use libeinfo, |
| 59 |
I give full license to assign the bug to me, and I'll happily |
| 60 |
investigate the issue. |
| 61 |
|
| 62 |
-Doug |
Archives