1 |
I just saw this today, because the original msg went to another mailbox, |
2 |
but the reply showed up here on -dev. |
3 |
|
4 |
On Mon, Sep 30, 2013 at 08:39:06AM -0400, Douglas Freed wrote: |
5 |
> On Wed, Sep 25, 2013 at 7:08 PM, Michał Górny <mgorny@g.o> wrote: |
6 |
> > Dnia 2013-09-13, o godz. 19:16:06 |
7 |
> > William Hubbs <williamh@g.o> napisał(a): |
8 |
> > |
9 |
> >> OpenRC currently has a public api, consisting of librc and libeinfo |
10 |
> >> (rc.h and einfo.h are the headers); however, I do not know of any |
11 |
> >> released software that uses these, so, if there is nothing, I am |
12 |
> >> considering making this code private to OpenRC and getting rid of the |
13 |
> >> API. |
14 |
> > |
15 |
> > I won't oppose since I don't use OpenRC anymore and therefore my |
16 |
> > opinion doesn't really matter here. However, I can't help but notice |
17 |
> > a particular trend since Roy left the project. I see that OpenRC is |
18 |
> > slowly regressing towards baselayout-1. |
19 |
|
20 |
I'm not sure how you figure that, since you weren't on the project when |
21 |
bl1 was being used, so I'll answer your concerns below. |
22 |
|
23 |
> > First the oldnet thingie being made the default back. While I can |
24 |
> > understand why people wanted it so badly, this doesn't make this less |
25 |
> > of a carousel for Gentoo users. I mean, changing defaults with every |
26 |
> > maintainer change. |
27 |
|
28 |
Actually oldnet is a separate package you can get rid of now. It is the |
29 |
default in Gentoo, not OpenRC. It is forced onto everyone's system by |
30 |
default because of popular demand only. I would rather have released a |
31 |
newsitem with OpenRC-0.12 telling people that they had to emerge netifrc |
32 |
if they wanted it, but this proposal was met with strong resistance, up |
33 |
to and including threats to revert the change to the OpenRC ebuilds if |
34 |
we had taken that route. |
35 |
|
36 |
> > Then, functions.sh split. While itself good, I don't get what's |
37 |
> > the benefit of converting the bash script from baselayout-1 while |
38 |
> > a better one was provided with OpenRC. |
39 |
|
40 |
The one in OpenRC is not a pure script. It is a wrapper around the rc |
41 |
binary which is what actually provides the einfo/ewarn/eerror etc calls. |
42 |
|
43 |
> > Now removing the public API because you don't care. While it may have |
44 |
> > been unused indeed, it's simply crippling the thing, not making it more |
45 |
> > useful. |
46 |
|
47 |
librc is still being used, so it isn't being removed. libeinfo has been |
48 |
available for years, but no one took up using it. Since no one is using |
49 |
it, I would rather not have the overhead of linking a shared library |
50 |
that isn't being shared with anyone else. |
51 |
|
52 |
> > I'd like to see some kind of plan behind all this. Because as far as I |
53 |
> > can see, it's just new maintainers slowly dropping all the new features |
54 |
> > they don't care about without any specific vision. No offense intended. |
55 |
> > |
56 |
> > If OpenRC really wants to compete with systemd, it should at least have |
57 |
> > some design plan, and you really should start working on providing |
58 |
> > useful features rather than reverting, crippling and rewriting for |
59 |
> > the sake of changing things. |
60 |
|
61 |
I don't really see OpenRC as trying to compete with systemd. OpenRC |
62 |
isn't an init system on its own; it is just init scripts. |
63 |
|
64 |
I think the only thing systemd has that OpenRC doesn't currently as far |
65 |
as booting/shutting down a system is service supervision. |
66 |
|
67 |
That is going to be a bigger project, because sysvinit doesn't have any |
68 |
service supervision functionality at all, and we still run on top of |
69 |
sysvinit by default. |
70 |
|
71 |
runit or s6 have been suggested as possible init systems to use, but I |
72 |
haven't really looked into either one much yet. |
73 |
|
74 |
Then comes the issue of how they should be used -- should we get |
75 |
base-system to consider replacing sysvinit, or should we try to use them |
76 |
under sysvinit? |
77 |
|
78 |
> I know I'm a bit late to this thread, but mgorny has a point. While |
79 |
> it may not be immediately obvious, libeinfo is very useful, especially |
80 |
> if your project aims to integrate nicely into a Gentoo system, by |
81 |
> providing a standard set of printing functions with the formatting |
82 |
> taken care of, resulting in output that is very familiar to users and |
83 |
> is easy to scan with the eyes when looking for problems. One |
84 |
> potential use-case would be reimplementing eselect in C. Not that I'm |
85 |
> saying that this should happen, but anybody who attempts to do this |
86 |
> would certainly appreciate having this bit taken care of for them. I |
87 |
> would be more than willing to assist with maintenance of the library, |
88 |
> even if split out into its own package, since it's small and rather |
89 |
> simplistic, so there's unlikely to be any issues. I see no reason why |
90 |
> we should remove something that isn't broken and doesn't cause us any |
91 |
> maintenance burden. If somebody does open a bug against OpenRC |
92 |
> because of an issue they're encountering while trying to use libeinfo, |
93 |
> I give full license to assign the bug to me, and I'll happily |
94 |
> investigate the issue. |
95 |
|
96 |
As I said above, libeinfo was around in stable for years and no one took |
97 |
up using it, so what you are talking about is a theoretical use case, |
98 |
which really doesn't exist, and has no reason to exist. Why should |
99 |
someone want to implement eselect in c? |
100 |
|
101 |
There wasn't a burden as far as maintaining it goes, so I'm not sure |
102 |
that splitting it out would have been a good choice. The burden was the |
103 |
overhead of linking to a shared library. If there had been someone else |
104 |
using it that would be one thing, but there isn't. |
105 |
|
106 |
I put the call out before I rolled the library into rc because I wanted |
107 |
to find out if someone was in fact using this library. |
108 |
|
109 |
All of the code that needs these functions outside of OpenRC is in |
110 |
shell, so it seems a bit over the top to have shell scripts calling a |
111 |
binary that in turn loads a shared library just for printing functions. |
112 |
|
113 |
I can be convinced, but I'm just not convinced at this point that |
114 |
keeping libeinfo as a shared library is worth the overhead. |
115 |
|
116 |
William |