[gentoo-dev] rfc: status of OpenRC's public API

[gentoo-dev] rfc: status of OpenRC's public API

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 580 bytes --]

All,

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 will reconsider if someone tells me there is actual software out
there which links to these libraries besides OpenRC, but if there isn't,
I am inclined to make all of that code private.

So, if you know of something that uses these libraries, speak up; I know
of nothing myself.

Thanks,

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: status of OpenRC's public API

[Alexandre Rostovtsev]

On Fri, 2013-09-13 at 19:16 -0500, William Hubbs wrote:
> All,
> 
> 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 will reconsider if someone tells me there is actual software out
> there which links to these libraries besides OpenRC, but if there isn't,
> I am inclined to make all of that code private.
> 
> So, if you know of something that uses these libraries, speak up; I know
> of nothing myself.
> 
> Thanks,
> 
> William

app-admin/openrc-settingsd uses various functions (rc_sys(),
rc_runlevel_get(), rc_service_exists(), rc_service_in_runlevel(),
rc_service_resolve(), rc_service_mark() etc.) from rc.h

Re: [gentoo-dev] rfc: status of OpenRC's public API

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1086 bytes --]

On Fri, Sep 13, 2013 at 09:04:06PM -0400, Alexandre Rostovtsev wrote:
> On Fri, 2013-09-13 at 19:16 -0500, William Hubbs wrote:
> > All,
> > 
> > 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 will reconsider if someone tells me there is actual software out
> > there which links to these libraries besides OpenRC, but if there isn't,
> > I am inclined to make all of that code private.
> > 
> > So, if you know of something that uses these libraries, speak up; I know
> > of nothing myself.
> > 
> > Thanks,
> > 
> > William
> 
> app-admin/openrc-settingsd uses various functions (rc_sys(),
> rc_runlevel_get(), rc_service_exists(), rc_service_in_runlevel(),
> rc_service_resolve(), rc_service_mark() etc.) from rc.h

Will this still be needed once gnome 3.8 is stable everywhere?

Thanks,

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: status of OpenRC's public API

[Alexandre Rostovtsev]

[-- Attachment #1: Type: text/plain, Size: 497 bytes --]

On Fri, 2013-09-13 at 22:48 -0500, William Hubbs wrote:
> On Fri, Sep 13, 2013 at 09:04:06PM -0400, Alexandre Rostovtsev wrote:
> > app-admin/openrc-settingsd uses various functions (rc_sys(),
> > rc_runlevel_get(), rc_service_exists(), rc_service_in_runlevel(),
> > rc_service_resolve(), rc_service_mark() etc.) from rc.h
> 
> Will this still be needed once gnome 3.8 is stable everywhere?

It will not be needed for gnome. Possibly another desktop environment
might have a use for it.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] rfc: status of OpenRC's public API

[Gilles Dartiguelongue]

[-- Attachment #1: Type: text/plain, Size: 756 bytes --]

Le samedi 14 septembre 2013 à 00:47 -0400, Alexandre Rostovtsev a
écrit :
> On Fri, 2013-09-13 at 22:48 -0500, William Hubbs wrote:
> > On Fri, Sep 13, 2013 at 09:04:06PM -0400, Alexandre Rostovtsev wrote:
> > > app-admin/openrc-settingsd uses various functions (rc_sys(),
> > > rc_runlevel_get(), rc_service_exists(), rc_service_in_runlevel(),
> > > rc_service_resolve(), rc_service_mark() etc.) from rc.h
> > 
> > Will this still be needed once gnome 3.8 is stable everywhere?
> 
> It will not be needed for gnome. Possibly another desktop environment
> might have a use for it.

It will be needed if someone manages to implement a logind alternative
as well. If that ever happens.

-- 
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: status of OpenRC's public API

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2278 bytes --]

On Sat, Sep 14, 2013 at 12:47:04AM -0400, Alexandre Rostovtsev wrote:
> On Fri, 2013-09-13 at 22:48 -0500, William Hubbs wrote:
> > On Fri, Sep 13, 2013 at 09:04:06PM -0400, Alexandre Rostovtsev wrote:
> > > app-admin/openrc-settingsd uses various functions (rc_sys(),
> > > rc_runlevel_get(), rc_service_exists(), rc_service_in_runlevel(),
> > > rc_service_resolve(), rc_service_mark() etc.) from rc.h
> > 
> > Will this still be needed once gnome 3.8 is stable everywhere?
> 
> It will not be needed for gnome. Possibly another desktop environment
> might have a use for it.

Running " grep -r 'app-admin/openrc-settingsd' ."  in a current
gentoo-x86 tree shows the following output:

./app-admin/openrc-settingsd/openrc-settingsd-1.0.1.ebuild:# $Header: /var/cvsroot/gentoo-x86/app-admin/openrc-settingsd/openrc-settingsd-1.0.1.ebuild,v 1.8 2013/02/02 22:20:11 ago Exp $
./app-admin/openrc-settingsd/ChangeLog:# ChangeLog for app-admin/openrc-settingsd
./app-admin/openrc-settingsd/ChangeLog:# $Header: /var/cvsroot/gentoo-x86/app-admin/openrc-settingsd/ChangeLog,v 1.10 2013/02/02 22:20:11 ago Exp $
./app-admin/openrc-settingsd/CVS/Repository:gentoo-x86/app-admin/openrc-settingsd
./gnome-base/gnome-control-center/gnome-control-center-3.8.3.ebuild:	|| ( ( app-admin/openrc-settingsd sys-auth/consolekit ) >=sys-apps/systemd-31 )
./gnome-base/gnome-control-center/gnome-control-center-3.8.4.1-r1.ebuild:	|| ( ( app-admin/openrc-settingsd sys-auth/consolekit ) >=sys-apps/systemd-31 )
./gnome-base/gnome-control-center/gnome-control-center-3.8.4.1.ebuild:	|| ( ( app-admin/openrc-settingsd sys-auth/consolekit ) >=sys-apps/systemd-31 )
./gnome-base/gnome-control-center/gnome-control-center-3.6.3-r1.ebuild:		app-admin/openrc-settingsd
./gnome-extra/cinnamon/cinnamon-1.8.8.1.ebuild:		app-admin/openrc-settingsd
./gnome-extra/cinnamon/cinnamon-1.6.7-r2.ebuild:		app-admin/openrc-settingsd

It looks like this is gnome specific to me.

I would be concerned about another desktop environment linking to these
libraries because that seems to be the same type of vertical integration
gnome is doing with systemd.
linking to these libraries because that seems to be the same type of
vertical integration gnome is doing with systemd.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: status of OpenRC's public API

[Pacho Ramos]

El sáb, 14-09-2013 a las 11:35 -0500, William Hubbs escribió:
> On Sat, Sep 14, 2013 at 12:47:04AM -0400, Alexandre Rostovtsev wrote:
> > On Fri, 2013-09-13 at 22:48 -0500, William Hubbs wrote:
> > > On Fri, Sep 13, 2013 at 09:04:06PM -0400, Alexandre Rostovtsev wrote:
> > > > app-admin/openrc-settingsd uses various functions (rc_sys(),
> > > > rc_runlevel_get(), rc_service_exists(), rc_service_in_runlevel(),
> > > > rc_service_resolve(), rc_service_mark() etc.) from rc.h
> > > 
> > > Will this still be needed once gnome 3.8 is stable everywhere?
> > 
> > It will not be needed for gnome. Possibly another desktop environment
> > might have a use for it.
> 
> Running " grep -r 'app-admin/openrc-settingsd' ."  in a current
> gentoo-x86 tree shows the following output:
> 
> ./app-admin/openrc-settingsd/openrc-settingsd-1.0.1.ebuild:# $Header: /var/cvsroot/gentoo-x86/app-admin/openrc-settingsd/openrc-settingsd-1.0.1.ebuild,v 1.8 2013/02/02 22:20:11 ago Exp $
> ./app-admin/openrc-settingsd/ChangeLog:# ChangeLog for app-admin/openrc-settingsd
> ./app-admin/openrc-settingsd/ChangeLog:# $Header: /var/cvsroot/gentoo-x86/app-admin/openrc-settingsd/ChangeLog,v 1.10 2013/02/02 22:20:11 ago Exp $
> ./app-admin/openrc-settingsd/CVS/Repository:gentoo-x86/app-admin/openrc-settingsd
> ./gnome-base/gnome-control-center/gnome-control-center-3.8.3.ebuild:	|| ( ( app-admin/openrc-settingsd sys-auth/consolekit ) >=sys-apps/systemd-31 )
> ./gnome-base/gnome-control-center/gnome-control-center-3.8.4.1-r1.ebuild:	|| ( ( app-admin/openrc-settingsd sys-auth/consolekit ) >=sys-apps/systemd-31 )
> ./gnome-base/gnome-control-center/gnome-control-center-3.8.4.1.ebuild:	|| ( ( app-admin/openrc-settingsd sys-auth/consolekit ) >=sys-apps/systemd-31 )
> ./gnome-base/gnome-control-center/gnome-control-center-3.6.3-r1.ebuild:		app-admin/openrc-settingsd
> ./gnome-extra/cinnamon/cinnamon-1.8.8.1.ebuild:		app-admin/openrc-settingsd
> ./gnome-extra/cinnamon/cinnamon-1.6.7-r2.ebuild:		app-admin/openrc-settingsd
> 
> It looks like this is gnome specific to me.
> 
> I would be concerned about another desktop environment linking to these
> libraries because that seems to be the same type of vertical integration
> gnome is doing with systemd.
> linking to these libraries because that seems to be the same type of
> vertical integration gnome is doing with systemd.
> 
> William
> 

openrc-settings will need to be kept if we ever want to implement:
https://bugs.gentoo.org/show_bug.cgi?id=480336

Re: [gentoo-dev] rfc: status of OpenRC's public API

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 484 bytes --]

On Sat, Sep 14, 2013 at 10:59:57PM +0200, Pacho Ramos wrote:
> openrc-settings will need to be kept if we ever want to implement:
> https://bugs.gentoo.org/show_bug.cgi?id=480336

There may be other reasons to keep the api, that's why I put out the
question.

However, I thought the gnome team had agreed that you were going to
just mandate systemd for gnome 3.8 and newer since logind is unusable
outside of systemd. In that case, can't we just close this bug as
wontfix?


William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: status of OpenRC's public API

[Pacho Ramos]

El sáb, 14-09-2013 a las 18:07 -0500, William Hubbs escribió:
> On Sat, Sep 14, 2013 at 10:59:57PM +0200, Pacho Ramos wrote:
> > openrc-settings will need to be kept if we ever want to implement:
> > https://bugs.gentoo.org/show_bug.cgi?id=480336
> 
> There may be other reasons to keep the api, that's why I put out the
> question.
> 
> However, I thought the gnome team had agreed that you were going to
> just mandate systemd for gnome 3.8 and newer since logind is unusable
> outside of systemd. In that case, can't we just close this bug as
> wontfix?
> 
> 
> William
> 

The reasoning for that bug is explained in the bug itself and the mail
thread pointed there:
https://bugs.gentoo.org/show_bug.cgi?id=480336
http://www.gossamer-threads.com/lists/gentoo/dev/276077 (see the talk
with chithanh there)

Re: [gentoo-dev] rfc: status of OpenRC's public API

[Doug Goldstein]

On Sat, Sep 14, 2013 at 11:35 AM, William Hubbs <williamh@gentoo.org> wrote:
> On Sat, Sep 14, 2013 at 12:47:04AM -0400, Alexandre Rostovtsev wrote:
>> On Fri, 2013-09-13 at 22:48 -0500, William Hubbs wrote:
>> > On Fri, Sep 13, 2013 at 09:04:06PM -0400, Alexandre Rostovtsev wrote:
>> > > app-admin/openrc-settingsd uses various functions (rc_sys(),
>> > > rc_runlevel_get(), rc_service_exists(), rc_service_in_runlevel(),
>> > > rc_service_resolve(), rc_service_mark() etc.) from rc.h
>> >
>> > Will this still be needed once gnome 3.8 is stable everywhere?
>>
>> It will not be needed for gnome. Possibly another desktop environment
>> might have a use for it.
>
> Running " grep -r 'app-admin/openrc-settingsd' ."  in a current
> gentoo-x86 tree shows the following output:
>
> ./app-admin/openrc-settingsd/openrc-settingsd-1.0.1.ebuild:# $Header: /var/cvsroot/gentoo-x86/app-admin/openrc-settingsd/openrc-settingsd-1.0.1.ebuild,v 1.8 2013/02/02 22:20:11 ago Exp $
> ./app-admin/openrc-settingsd/ChangeLog:# ChangeLog for app-admin/openrc-settingsd
> ./app-admin/openrc-settingsd/ChangeLog:# $Header: /var/cvsroot/gentoo-x86/app-admin/openrc-settingsd/ChangeLog,v 1.10 2013/02/02 22:20:11 ago Exp $
> ./app-admin/openrc-settingsd/CVS/Repository:gentoo-x86/app-admin/openrc-settingsd
> ./gnome-base/gnome-control-center/gnome-control-center-3.8.3.ebuild:    || ( ( app-admin/openrc-settingsd sys-auth/consolekit ) >=sys-apps/systemd-31 )
> ./gnome-base/gnome-control-center/gnome-control-center-3.8.4.1-r1.ebuild:       || ( ( app-admin/openrc-settingsd sys-auth/consolekit ) >=sys-apps/systemd-31 )
> ./gnome-base/gnome-control-center/gnome-control-center-3.8.4.1.ebuild:  || ( ( app-admin/openrc-settingsd sys-auth/consolekit ) >=sys-apps/systemd-31 )
> ./gnome-base/gnome-control-center/gnome-control-center-3.6.3-r1.ebuild:         app-admin/openrc-settingsd
> ./gnome-extra/cinnamon/cinnamon-1.8.8.1.ebuild:         app-admin/openrc-settingsd
> ./gnome-extra/cinnamon/cinnamon-1.6.7-r2.ebuild:                app-admin/openrc-settingsd
>
> It looks like this is gnome specific to me.
>
> I would be concerned about another desktop environment linking to these
> libraries because that seems to be the same type of vertical integration
> gnome is doing with systemd.
> linking to these libraries because that seems to be the same type of
> vertical integration gnome is doing with systemd.
>
> William
>

Cinnamon is not requiring systemd, so removing openrc-settingd will
break that environment.

-- 
Doug Goldstein

Re: [gentoo-dev] rfc: status of OpenRC's public API

[Gilles Dartiguelongue]

Le samedi 14 septembre 2013 à 18:07 -0500, William Hubbs a écrit :
> On Sat, Sep 14, 2013 at 10:59:57PM +0200, Pacho Ramos wrote:
> > openrc-settings will need to be kept if we ever want to implement:
> > https://bugs.gentoo.org/show_bug.cgi?id=480336
> 
> There may be other reasons to keep the api, that's why I put out the
> question.
> 
> However, I thought the gnome team had agreed that you were going to
> just mandate systemd for gnome 3.8 and newer since logind is unusable
> outside of systemd. In that case, can't we just close this bug as
> wontfix?
> 

I'll repeat what I wrote on this list at least 4 times now. The gnome
team decided to move forward and use systemd as we have not enough man
power to develop our own alternative to logind.

If there ever was such alternative, we would most likely drop the
systemd requirement and I would, for sure, be the first to try it out
since I very much prefer openrc.

-- 
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo

[gentoo-dev] Re: rfc: status of OpenRC's public API

[Steven J. Long]

On Fri, Sep 13, 2013, William Hubbs wrote:
> 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.

Wow, I didn't realise those were there, at least not as a public API.
Thanks for bringing them to light.
 
> I will reconsider if someone tells me there is actual software out
> there which links to these libraries besides OpenRC, but if there isn't,
> I am inclined to make all of that code private.

On Sat, Sep 14, 2013, William Hubbs wrote: 
> There may be other reasons to keep the api, that's why I put out the
> question.

Personally I think they are useful: UberLord must have thought that they
have wider applicability, eg at the juncture between script and the init-system
in terms of implementation. It's easy to eg code a lua or python interface
to the API. It also provides a basis for the things qnikst has been discussing
in #openrc.

WRT your concern about "vertical integration" I don't think that should be
a worry. So long as you simply provide the API (which has been stable all
this time) and make no bones about what a higher layer does with it, you are
not committing any coupling no-nos.

It's only an issue at system-level when your code is dependent on what the
higher layer is going to do with your output, or requires a specific higher
layer to run at all(!).

Regards,
steveL
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: rfc: status of OpenRC's public API

[Rich Freeman]

On Mon, Sep 16, 2013 at 7:28 AM, Steven J. Long
<slong@rathaus.eclipse.co.uk> wrote:
> It's only an issue at system-level when your code is dependent on what the
> higher layer is going to do with your output, or requires a specific higher
> layer to run at all(!).

I think the real issue is the lack of any kind of standardization
around an API for a service manager.  For eons there really hasn't
been any kind of cross-distro service manager in the first place, let
alone a standard interface for them.

The vertical integration issues mainly seem to stem from a lack of any
kind of abstraction at this layer.

Rich

[gentoo-dev] Re: Re: rfc: status of OpenRC's public API

[Steven J. Long]

On Mon, Sep 16, 2013, Rich Freeman wrote:
> On Mon, Sep 16, 2013 at 7:28 AM, Steven J. Long
> > It's only an issue at system-level when your code is dependent on what
> > the higher layer is going to do with your output, or requires a specific
> > higher layer to run at all(!).
> 
> I think the real issue is the lack of any kind of standardization
> around an API for a service manager.  For eons there really hasn't
> been any kind of cross-distro service manager in the first place,

cross-distro is so limited: cross-operating-system is far more flexible and
shows much more capability and maturity from a developer, in my eyes; and
openrc has been doing that for quite a while now.

> let alone a standard interface for them.

IDK it's pretty clear what must people want to tell their services to do:
things like start, stop, reload, check (ie running correctly: eg an httpd
should respond to GET /), and hooks. Other than that, configuration should
be declarative, with the option for the admin to modify the execution,
similar to how a packager patches code.

An API is simply a way to do that from C, which is more relevant nowadays,
with the event-based approach to hardware activation, cgroup notification
which can be far more frequent than a sh scripter would be comfortable with,
and the desire to extend xinetd, as well as incorporate monitoring.

> The vertical integration issues mainly seem to stem from a lack of any
> kind of abstraction at this layer.

I have to disagree. Sloppy discipline in the craft has got nothing to do
with an abstraction being available. And inversion of coupling is nothing
but amateur, not vertical integration. This is not at the boundary between
the kernel and libc: this is userland, pure and simple.

For a counter-example of how to do it, consider LADSPA [1] and the number
of successful applications using it, including backends like gstreamer.
Because the API is deliberately kept simple, it is possible to build a
higher layer on top of it (ie: vertically integrated, if it cannot work
with multiple backend libs) eg: DSSI [2] which again is a deliberately
simple API, providing the UI abstraction for audio plugins.

And both are multi-platform.

The similarity between LADSPA and the rc.h interface, in that regard, is
striking.

Regards,
steveL.

[1] http://www.ladspa.org/
[2] http://dssi.sourceforge.net/
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

[gentoo-dev] Re: rfc: status of OpenRC's public API

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 376 bytes --]

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


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: rfc: status of OpenRC's public API

[Ian Stakenvicius]

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

Re: [gentoo-dev] Re: rfc: status of OpenRC's public API

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1510 bytes --]

On Sat, Sep 21, 2013 at 03:21:07PM -0400, Ian Stakenvicius wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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?

Because it is a c library, which means that another program would have
to be written which provides the einfo/ewarn/etc shell commands and a
functions.sh wrapper so the shell scripts can use it.
 
 Since the consumers on bug 373219 are shell scripts, why have the
 complexity of a wrapper and not just provide a shell script?

 I know I have been slow about it. mostly because I've been doing a lot
 of work on OpenRC lately wrt bug #482396. That should be wrapping up
 soon.


> Out of curiosity, what is the reasoning behind making these libs private?

Well, the thought has changed slightly. librc can't be made private
currently because of openrc-settingsd. libeinfo, on the other hand, does
not have any known consumers, so there is no reason to keep it as a
library.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.20 (GNU/Linux)
> 
> iF4EAREIAAYFAlI98aMACgkQ2ugaI38ACPCTcQD9HIqOTlhia/ktPFANAZdJbfEv
> DqOh7CUCULZw+FqkOpQBAISPbWdsg+flecvnv5OfWGsnLqnYK6GPG4e23KwDyz1e
> =OCdp
> -----END PGP SIGNATURE-----
> 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: rfc: status of OpenRC's public API

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 24/09/13 02:15 PM, William Hubbs wrote:
> On Sat, Sep 21, 2013 at 03:21:07PM -0400, Ian Stakenvicius wrote:
>> Out of curiosity, what is the reasoning behind making these libs
>> private?
> 
> Well, the thought has changed slightly. librc can't be made
> private currently because of openrc-settingsd. libeinfo, on the
> other hand, does not have any known consumers, so there is no
> reason to keep it as a library.

That doesn't answer my question, though; yes at this point there's no
reason to keep it public, but -why- move it to private?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iF4EAREIAAYFAlJB2EoACgkQ2ugaI38ACPC8uwD+PwSGgcRI1Yv4COVjfavrbt4p
tag4I4xzueXBvBBeIygA/RPCV+xnK5SHwdGluxQxPUj0Zpg4EPeeJ/+F1gpWVPC7
=cEZR
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: rfc: status of OpenRC's public API

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]

On Tue, Sep 24, 2013 at 02:22:02PM -0400, Ian Stakenvicius wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 24/09/13 02:15 PM, William Hubbs wrote:
> > On Sat, Sep 21, 2013 at 03:21:07PM -0400, Ian Stakenvicius wrote:
> >> Out of curiosity, what is the reasoning behind making these libs
> >> private?
> > 
> > Well, the thought has changed slightly. librc can't be made
> > private currently because of openrc-settingsd. libeinfo, on the
> > other hand, does not have any known consumers, so there is no
> > reason to keep it as a library.
> 
> That doesn't answer my question, though; yes at this point there's no
> reason to keep it public, but -why- move it to private?

This library has been around for some time, and there are no known
consumers.

Since there are no known consumers, there is no need for us to have the
overhead of linking a shared library for code that only OpenRC uses.

I think the KISS principle [1] applies here very nicely.

William

[1] http://en.wikipedia.org/wiki/Kiss_principle

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: rfc: status of OpenRC's public API

[Mike Gilbert]

On Wed, Sep 25, 2013 at 4:04 PM, William Hubbs <williamh@gentoo.org> wrote:
> On Tue, Sep 24, 2013 at 02:22:02PM -0400, Ian Stakenvicius wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> On 24/09/13 02:15 PM, William Hubbs wrote:
>> > On Sat, Sep 21, 2013 at 03:21:07PM -0400, Ian Stakenvicius wrote:
>> >> Out of curiosity, what is the reasoning behind making these libs
>> >> private?
>> >
>> > Well, the thought has changed slightly. librc can't be made
>> > private currently because of openrc-settingsd. libeinfo, on the
>> > other hand, does not have any known consumers, so there is no
>> > reason to keep it as a library.
>>
>> That doesn't answer my question, though; yes at this point there's no
>> reason to keep it public, but -why- move it to private?
>
> This library has been around for some time, and there are no known
> consumers.
>
> Since there are no known consumers, there is no need for us to have the
> overhead of linking a shared library for code that only OpenRC uses.

So is your plan to convert it to a static helper library, or to have
the openrc binaries link in the necessary object files directly?

Re: [gentoo-dev] Re: rfc: status of OpenRC's public API

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1488 bytes --]

On Wed, Sep 25, 2013 at 04:27:42PM -0400, Mike Gilbert wrote:
> On Wed, Sep 25, 2013 at 4:04 PM, William Hubbs <williamh@gentoo.org> wrote:
> > On Tue, Sep 24, 2013 at 02:22:02PM -0400, Ian Stakenvicius wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA256
> >>
> >> On 24/09/13 02:15 PM, William Hubbs wrote:
> >> > On Sat, Sep 21, 2013 at 03:21:07PM -0400, Ian Stakenvicius wrote:
> >> >> Out of curiosity, what is the reasoning behind making these libs
> >> >> private?
> >> >
> >> > Well, the thought has changed slightly. librc can't be made
> >> > private currently because of openrc-settingsd. libeinfo, on the
> >> > other hand, does not have any known consumers, so there is no
> >> > reason to keep it as a library.
> >>
> >> That doesn't answer my question, though; yes at this point there's no
> >> reason to keep it public, but -why- move it to private?
> >
> > This library has been around for some time, and there are no known
> > consumers.
> >
> > Since there are no known consumers, there is no need for us to have the
> > overhead of linking a shared library for code that only OpenRC uses.
> 
> So is your plan to convert it to a static helper library, or to have
> the openrc binaries link in the necessary object files directly?

OpenRC is just one binary, rc. libeinfo is currently just one c source
and one header file, so I'm thinking of just linking the object into the
binary directly.

What do you think?

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: rfc: status of OpenRC's public API

[Mike Gilbert]

On Wed, Sep 25, 2013 at 5:01 PM, William Hubbs <williamh@gentoo.org> wrote:
> On Wed, Sep 25, 2013 at 04:27:42PM -0400, Mike Gilbert wrote:
>> On Wed, Sep 25, 2013 at 4:04 PM, William Hubbs <williamh@gentoo.org> wrote:
>> > On Tue, Sep 24, 2013 at 02:22:02PM -0400, Ian Stakenvicius wrote:
>> >> -----BEGIN PGP SIGNED MESSAGE-----
>> >> Hash: SHA256
>> >>
>> >> On 24/09/13 02:15 PM, William Hubbs wrote:
>> >> > On Sat, Sep 21, 2013 at 03:21:07PM -0400, Ian Stakenvicius wrote:
>> >> >> Out of curiosity, what is the reasoning behind making these libs
>> >> >> private?
>> >> >
>> >> > Well, the thought has changed slightly. librc can't be made
>> >> > private currently because of openrc-settingsd. libeinfo, on the
>> >> > other hand, does not have any known consumers, so there is no
>> >> > reason to keep it as a library.
>> >>
>> >> That doesn't answer my question, though; yes at this point there's no
>> >> reason to keep it public, but -why- move it to private?
>> >
>> > This library has been around for some time, and there are no known
>> > consumers.
>> >
>> > Since there are no known consumers, there is no need for us to have the
>> > overhead of linking a shared library for code that only OpenRC uses.
>>
>> So is your plan to convert it to a static helper library, or to have
>> the openrc binaries link in the necessary object files directly?
>
> OpenRC is just one binary, rc. libeinfo is currently just one c source
> and one header file, so I'm thinking of just linking the object into the
> binary directly.
>
> What do you think?
>

Makes sense.

Re: [gentoo-dev] rfc: status of OpenRC's public API

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1720 bytes --]

Dnia 2013-09-13, o godz. 19:16:06
William Hubbs <williamh@gentoo.org> napisał(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.

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.

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.

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.

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.

Just some material to think about.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] rfc: status of OpenRC's public API

[Douglas Freed]

On Wed, Sep 25, 2013 at 7:08 PM, Michał Górny <mgorny@gentoo.org> wrote:
> Dnia 2013-09-13, o godz. 19:16:06
> William Hubbs <williamh@gentoo.org> napisał(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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Just some material to think about.
>
> --
> Best regards,
> Michał Górny

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.

-Doug

Re: [gentoo-dev] rfc: status of OpenRC's public API

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 5913 bytes --]

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ł Górny <mgorny@gentoo.org> wrote:
> > Dnia 2013-09-13, o godz. 19:16:06
> > William Hubbs <williamh@gentoo.org> napisał(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


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]