Re: [gentoo-dev] rfc: status of OpenRC's public API
On Wed, Sep 25, 2013 at 7:08 PM, Michał Górny mgo...@gentoo.org wrote: Dnia 2013-09-13, o godz. 19:16:06 William Hubbs willi...@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
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 mgo...@gentoo.org wrote: Dnia 2013-09-13, o godz. 19:16:06 William Hubbs willi...@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
Re: [gentoo-dev] rfc: status of OpenRC's public API
Dnia 2013-09-13, o godz. 19:16:06 William Hubbs willi...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: status of OpenRC's public API
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 e...@gentoo.org Gentoo
Re: [gentoo-dev] rfc: status of OpenRC's public API
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 e...@gentoo.org Gentoo signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: status of OpenRC's public API
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 signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: status of OpenRC's public API
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
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 signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: status of OpenRC's public API
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
On Sat, Sep 14, 2013 at 11:35 AM, William Hubbs willi...@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
[gentoo-dev] rfc: status of OpenRC's public API
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 signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: status of OpenRC's public API
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
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 signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: status of OpenRC's public API
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. signature.asc Description: This is a digitally signed message part
