[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] rfc: status of OpenRC's public API
From:       William Hubbs <williamh () gentoo ! org>
Date:       2013-09-30 16:50:47
Message-ID: 20130930165047.GA21455 () linux1
[Download RAW message or body]


I just saw this today, because the original msg went to another mailbox,
but the reply showed up here on -dev.

On Mon, Sep 30, 2013 at 08:39:06AM -0400, Douglas Freed wrote:
> On Wed, Sep 25, 2013 at 7:08 PM, Micha=C5=82 G=C3=B3rny <mgorny@gentoo.or=
g> wrote:
> > Dnia 2013-09-13, o godz. 19:16:06
> > William Hubbs <williamh@gentoo.org> napisa=C5=82(a):
> >
> >> OpenRC currently has a public api, consisting of librc and libeinfo
> >> (rc.h and einfo.h are the headers); however, I do not know of any
> >> released software that uses these, so, if there is nothing, I am
> >> considering making this code private to OpenRC and getting rid of the
> >> API.
> >
> > I won't oppose since I don't use OpenRC anymore and therefore my
> > opinion doesn't really matter here. However, I can't help but notice
> > a particular trend since Roy left the project. I see that OpenRC is
> > slowly regressing towards baselayout-1.

I'm not sure how you figure that, since you weren't on the project when
bl1 was being used, so I'll answer your concerns below.

> > First the oldnet thingie being made the default back. While I can
> > understand why people wanted it so badly, this doesn't make this less
> > of a carousel for Gentoo users. I mean, changing defaults with every
> > maintainer change.

Actually oldnet is a separate package you can get rid of now. It is the
default in Gentoo, not OpenRC. It is forced onto everyone's system by
default because of popular demand only. I would rather have released a
newsitem with OpenRC-0.12 telling people that they had to emerge netifrc
if they wanted it, but this proposal was met with strong resistance, up
to and including threats to revert the change to the OpenRC ebuilds if
we had taken that route.

> > Then, functions.sh split. While itself good, I don't get what's
> > the benefit of converting the bash script from baselayout-1 while
> > a better one was provided with OpenRC.

The one in OpenRC is not a pure script. It is a wrapper around the rc
binary which is what actually provides the einfo/ewarn/eerror etc calls.

> > Now removing the public API because you don't care. While it may have
> > been unused indeed, it's simply crippling the thing, not making it more
> > useful.

librc is still being used, so it isn't being removed. libeinfo has been
available for years, but no one took up using it. Since no one is using
it, I would rather not have the overhead of linking a shared library
that isn't being shared with anyone else.

> > I'd like to see some kind of plan behind all this. Because as far as I
> > can see, it's just new maintainers slowly dropping all the new features
> > they don't care about without any specific vision. No offense intended.
> >
> > If OpenRC really wants to compete with systemd, it should at least have
> > some design plan, and you really should start working on providing
> > useful features rather than reverting, crippling and rewriting for
> > the sake of changing things.

I don't really see OpenRC as trying to compete with systemd. OpenRC
isn't an init system on its own; it is just init scripts.

I think the only thing systemd has that OpenRC doesn't currently as far
as booting/shutting down a system is service supervision.

That is going to be a bigger project, because sysvinit doesn't have any
service supervision functionality at all, and we still run on top of
sysvinit by default.

runit or s6 have been suggested as possible init systems to use, but I
haven't really looked into either one much yet.

Then comes the issue of how they should be used -- should we get
base-system to consider replacing sysvinit, or should we try to use them
under sysvinit?

> I know I'm a bit late to this thread, but mgorny has a point.  While
> it may not be immediately obvious, libeinfo is very useful, especially
> if your project aims to integrate nicely into a Gentoo system, by
> providing a standard set of printing functions with the formatting
> taken care of, resulting in output that is very familiar to users and
> is easy to scan with the eyes when looking for problems.  One
> potential use-case would be reimplementing eselect in C.  Not that I'm
> saying that this should happen, but anybody who attempts to do this
> would certainly appreciate having this bit taken care of for them.  I
> would be more than willing to assist with maintenance of the library,
> even if split out into its own package, since it's small and rather
> simplistic, so there's unlikely to be any issues.  I see no reason why
> we should remove something that isn't broken and doesn't cause us any
> maintenance burden.  If somebody does open a bug against OpenRC
> because of an issue they're encountering while trying to use libeinfo,
> I give full license to assign the bug to me, and I'll happily
> investigate the issue.

As I said above, libeinfo was around in stable for years and no one took
up using it, so what you are talking about is a theoretical use case,
which really doesn't exist, and has no reason to exist. Why should
someone want to implement eselect in c?

There wasn't a burden as far as maintaining it goes, so I'm not sure
that splitting it out would have been a good choice. The burden was the
overhead of linking to a shared library. If there had been someone else
using it that would be one thing, but there isn't.

I put the call out before I rolled the library into rc because I wanted
to find out if someone was in fact using this library.

All of the code that needs these functions outside of OpenRC is in
shell, so it seems a bit over the top to have shell scripts calling a
binary that in turn loads a shared library just for printing functions.

I can be convinced, but I'm just not convinced at this point that
keeping libeinfo as a shared library is worth the overhead.

William


["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]