[gentoo-dev] rfc: renaming "rc" binary in OpenRC

[gentoo-dev] rfc: renaming "rc" binary in OpenRC

[William Hubbs]

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

All,

We got a request from Debian to rename the "rc" binary of OpenRC due to
a naming conflict they have. They have a port of the at&t plan 9 shell,
which has a binary named "rc" as well[1].

My thought is to rename our "rc" to "openrc", since that would be
unique.

I know at least one thing that will break is everyone's inittab, so
should I sed their inittab in our live ebuild or expect them to fix it
and give a warning? I know that once OpenRC with this change is
released, it will need to probably be p.masked until there is a new
release of sysvinit that updates the inittab.

I'm not sure what else will break.

Does anyone have any ideas wrt other things to look for, or should I
make the changes upstream and have people let us know what
else breaks?

William

[1] https://bugs.gentoo.org/show_bug.cgi?id=493958

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

Re: [gentoo-dev] rfc: renaming "rc" binary in OpenRC

[Alon Bar-Lev]

On Wed, Dec 11, 2013 at 10:41 PM, William Hubbs <williamh@gentoo.org> wrote:
>
> All,
>
> We got a request from Debian to rename the "rc" binary of OpenRC due to
> a naming conflict they have. They have a port of the at&t plan 9 shell,
> which has a binary named "rc" as well[1].
>
> My thought is to rename our "rc" to "openrc", since that would be
> unique.
>
> I know at least one thing that will break is everyone's inittab, so
> should I sed their inittab in our live ebuild or expect them to fix it
> and give a warning? I know that once OpenRC with this change is
> released, it will need to probably be p.masked until there is a new
> release of sysvinit that updates the inittab.
>
> I'm not sure what else will break.
>
> Does anyone have any ideas wrt other things to look for, or should I
> make the changes upstream and have people let us know what
> else breaks?

are you going to rename also rc-service and rc-update?

>
> William
>
> [1] https://bugs.gentoo.org/show_bug.cgi?id=493958

Re: [gentoo-dev] rfc: renaming "rc" binary in OpenRC

[Chris Reffett]

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

On 12/11/2013 3:41 PM, William Hubbs wrote:
> All,
>
> We got a request from Debian to rename the "rc" binary of OpenRC due to
> a naming conflict they have. They have a port of the at&t plan 9 shell,
> which has a binary named "rc" as well[1].
>
> My thought is to rename our "rc" to "openrc", since that would be
> unique.
>
> I know at least one thing that will break is everyone's inittab, so
> should I sed their inittab in our live ebuild or expect them to fix it
> and give a warning? I know that once OpenRC with this change is
> released, it will need to probably be p.masked until there is a new
> release of sysvinit that updates the inittab.
>
> I'm not sure what else will break.
>
> Does anyone have any ideas wrt other things to look for, or should I
> make the changes upstream and have people let us know what
> else breaks?
>
> William
>
> [1] https://bugs.gentoo.org/show_bug.cgi?id=493958
The idea of running a sed on inittab in an ebuild, no matter what the
context, terrifies me. Perhaps we can ease this in slowly by renaming rc
-> openrc and symlinking rc -> openrc and making a release with that
change concurrent with a news item? Or even just do that in the ebuild
rather than in the actual sources. I don't think Debian will keel over
and die if it takes a little extra time for the change to go through,
and it beats a ton of broken systems.

Chris Reffett


[-- Attachment #2: Type: text/html, Size: 2118 bytes --]

Re: [gentoo-dev] rfc: renaming "rc" binary in OpenRC

[Markos Chandras]

On 12/11/2013 08:47 PM, Chris Reffett wrote:
> On 12/11/2013 3:41 PM, William Hubbs wrote:
>> All,
>>
>> We got a request from Debian to rename the "rc" binary of OpenRC due to
>> a naming conflict they have. They have a port of the at&t plan 9 shell,
>> which has a binary named "rc" as well[1].
>>
>> My thought is to rename our "rc" to "openrc", since that would be
>> unique.
>>
>> I know at least one thing that will break is everyone's inittab, so
>> should I sed their inittab in our live ebuild or expect them to fix it
>> and give a warning? I know that once OpenRC with this change is
>> released, it will need to probably be p.masked until there is a new
>> release of sysvinit that updates the inittab.
>>
>> I'm not sure what else will break.
>>
>> Does anyone have any ideas wrt other things to look for, or should I
>> make the changes upstream and have people let us know what
>> else breaks?
>>
>> William
>>
>> [1] https://bugs.gentoo.org/show_bug.cgi?id=493958
> The idea of running a sed on inittab in an ebuild, no matter what the
> context, terrifies me. Perhaps we can ease this in slowly by renaming rc
> -> openrc and symlinking rc -> openrc and making a release with that
> change concurrent with a news item? Or even just do that in the ebuild
> rather than in the actual sources. I don't think Debian will keel over
> and die if it takes a little extra time for the change to go through,
> and it beats a ton of broken systems.
> 
> Chris Reffett
> 
> 

+1

The ebuild can grep the inittab and it if finds an "rc" there, just
print a huge warning telling the user to migrate || die.

-- 
Regards,
Markos Chandras

Re: [gentoo-dev] rfc: renaming "rc" binary in OpenRC

[Paul Tagliamonte]

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


[I'm not the OpenRC maintainer, I'm only on gentoo-devel because I'm
 generally interested, and I saw this, I'm not speaking for zigo or
 anything here.]

On Wed, Dec 11, 2013 at 03:47:57PM -0500, Chris Reffett wrote:
>    The idea of running a sed on inittab in an ebuild, no matter what the
>    context, terrifies me. Perhaps we can ease this in slowly by renaming rc
>    -> openrc and symlinking rc -> openrc and making a release with that
>    change concurrent with a news item? Or even just do that in the ebuild
>    rather than in the actual sources. I don't think Debian will keel over and
>    die if it takes a little extra time for the change to go through, and it
>    beats a ton of broken systems.
> 
>    Chris Reffett

Hi, Gentoo (and hello world),

I'm breaking my streak of lurking to comment generally on the Debian
procedure here.

I'm sure the Debian folks would be happy to strip the symlink from the
deb over having to patch OpenRC's rc binary => openrc against the
upstream source.

Shipping /usr/bin/rc => /usr/bin/openrc would be totally cool for
Debian, I believe. Hopefully the OpenRC team will come in and correct me
if I'm wrong :)

Fondly,
  Paul

-- 
 .''`.  Paul Tagliamonte <paultag@debian.org>  |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `-     http://people.debian.org/~paultag/conduct-statement.txt

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

Re: [gentoo-dev] rfc: renaming "rc" binary in OpenRC

[William Hubbs]

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

On Wed, Dec 11, 2013 at 10:47:49PM +0200, Alon Bar-Lev wrote:
> On Wed, Dec 11, 2013 at 10:41 PM, William Hubbs <williamh@gentoo.org> wrote:
> >
> > All,
> >
> > We got a request from Debian to rename the "rc" binary of OpenRC due to
> > a naming conflict they have. They have a port of the at&t plan 9 shell,
> > which has a binary named "rc" as well[1].
> >
> > My thought is to rename our "rc" to "openrc", since that would be
> 
> are you going to rename also rc-service and rc-update?

No, there isn't a need for that, just "rc".

William


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

Re: [gentoo-dev] rfc: renaming "rc" binary in OpenRC

[Markos Chandras]

On 12/11/2013 08:56 PM, Paul Tagliamonte wrote:
> 
> [I'm not the OpenRC maintainer, I'm only on gentoo-devel because I'm
>  generally interested, and I saw this, I'm not speaking for zigo or
>  anything here.]
> 
> On Wed, Dec 11, 2013 at 03:47:57PM -0500, Chris Reffett wrote:
>>    The idea of running a sed on inittab in an ebuild, no matter what the
>>    context, terrifies me. Perhaps we can ease this in slowly by renaming rc
>>    -> openrc and symlinking rc -> openrc and making a release with that
>>    change concurrent with a news item? Or even just do that in the ebuild
>>    rather than in the actual sources. I don't think Debian will keel over and
>>    die if it takes a little extra time for the change to go through, and it
>>    beats a ton of broken systems.
>>
>>    Chris Reffett
> 
> Hi, Gentoo (and hello world),
> 
> I'm breaking my streak of lurking to comment generally on the Debian
> procedure here.
> 
> I'm sure the Debian folks would be happy to strip the symlink from the
> deb over having to patch OpenRC's rc binary => openrc against the
> upstream source.
> 
> Shipping /usr/bin/rc => /usr/bin/openrc would be totally cool for
> Debian, I believe. Hopefully the OpenRC team will come in and correct me
> if I'm wrong :)
> 
> Fondly,
>   Paul

> 
If that's the case then I see no reason to go through the migration path
for users :) The symlink thing can be done immediately.
I am wondering, wouldn't Debian be able to rename "rc" to "openrc" in
their openrc package just before merging it to the read filesystem (I
assume Debian also builds and installs in sandbox first?)? In this case
we will not have to touch openrc (or the ebuild) at all.

-- 
Regards,
Markos Chandras

Re: [gentoo-dev] rfc: renaming "rc" binary in OpenRC

[Paul Tagliamonte]

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

On Wed, Dec 11, 2013 at 09:09:16PM +0000, Markos Chandras wrote:
> If that's the case then I see no reason to go through the migration path
> for users :) The symlink thing can be done immediately.

Awesome. Great to hear it!

> I am wondering, wouldn't Debian be able to rename "rc" to "openrc" in
> their openrc package just before merging it to the read filesystem (I
> assume Debian also builds and installs in sandbox first?)? In this case
> we will not have to touch openrc (or the ebuild) at all.

Again, I'm not the maintainer, so don't hold me to this - but I remember
hearing something about something somewhere thinking the name is `rc',
even after moving the binary out of the way.

It'd also be great to have a similar setup in Gentoo and Debian, but I
can clearly see how Gentoo'ers would be resistant to such a tough change
to make.

> -- 
> Regards,
> Markos Chandras

Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte <paultag@debian.org>  |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `-     http://people.debian.org/~paultag/conduct-statement.txt

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

[gentoo-dev] Re: rfc: renaming "rc" binary in OpenRC

[Duncan]

Markos Chandras posted on Wed, 11 Dec 2013 20:53:04 +0000 as excerpted:

> On 12/11/2013 08:47 PM, Chris Reffett wrote:
>> On 12/11/2013 3:41 PM, William Hubbs wrote:
>>>
>>> My thought is to rename our "rc" to "openrc", since that would be
>>> unique.
>>>
>>> I know at least one thing that will break is everyone's inittab, so
>>> should I sed their inittab in our live ebuild or expect them to fix it
>>> and give a warning? I know that once OpenRC with this change is
>>> released, it will need to probably be p.masked until there is a new
>>> release of sysvinit that updates the inittab.

>> The idea of running a sed on inittab in an ebuild, no matter what the
>> context, terrifies me. Perhaps we can ease this in slowly by renaming
>> rc -> openrc and symlinking rc -> openrc and making a release with that
>> change concurrent with a news item? Or even just do that in the ebuild
>> rather than in the actual sources. I don't think Debian will keel over
>> and die if it takes a little extra time for the change to go through,
>> and it beats a ton of broken systems.

> +1
> 
> The ebuild can grep the inittab and it if finds an "rc" there, just
> print a huge warning telling the user to migrate || die.

I think it's worth noting two small details of williamh's original mail 
that may have gone unnoticed:

1) He proposes seding the *LIVE* ebuild, which I take as meaning 
openrc-9999.

2) He then proposes p.masking an openrc release until a sysvinit release 
updating inittab, with the contrast between that and the LIVE ebuild 
proposal thus again emphasized.

Question: How many people run the openrc-9999 LIVE ebuild, and given that 
it's masked and general gentoo policy is that people running live ebuilds 
should expect to keep the pieces of they can't handle occasionally 
unpredicted changes, how much should we actually worry about doing just 
that?

*I ask the above as an openrc-9999 user myself!  Of course, I also not 
only follow this list for heads-up notes such as this, but I also have a 
partially scripted update routine that checks openrc for changes every 
time I update, runs git log to check them out if there are any, and 
further runs git show on anything that I have questions about, *BEFORE* I 
actually do the update.  There's certainly a small window between my 
checks and the actual run of the openrc emerge, during which a git commit 
or two might in theory slip in, but other than that, I'd see such a 
change BEFORE I ever actually installed that openrc live update in the 
first place.

As a result, while I probably wouldn't have noted the linkage to inittab 
without this mail, I would have at least been aware of the name change 
when I did that live-build update, and would be prepared to boot with 
init=/bin/bash and find the problem, should it come to that, as I know it 
well might given the live-ebuild I choose to run.

Meanwhile, given the openrc-9999 bug history, with me as about the only 
bug reporter, I don't think there's that many actually running it.  
Certainly nothing I'd qualify as "a ton of broken systems" even if 
there's no sed and every one of those running it fails to see the warning 
until they've rebooted and suffered the consequences.

And the p.mask proposal for an actual release with the change, until a 
parallel sysvinit package update likely unmasked at the same time, does 
sound appropriately more responsible for ~arch as well, thus making both 
proposals at least not entirely insane.

Tho I too am a bit uncomfortable about sedding inittab directly from the 
ebuild.  Assuming it can work, the more gradual symlink and safer grep 
proposals sound much more reasonable, even at the live ebuild level.

Tho that said, given that I /am/ running a live ebuild for something as 
critical as openrc, if sed screws up and replaces the current inittab 
with an empty file, I'd better be prepared to deal with it.  That's part 
of the risk I took when unmasking that ebuild.  Now I'd be rather more 
annoyed if the ebuild pulled a trick like I did in one of my own scripts 
a few years ago, such that I used the wrong variable name as the absolute 
prefix to a rm command run as root, and said mis-named variable ended up 
null...

I was brown-bagging /that/ one for a few days! =:^\

But killing a single inittab file, meh!  If I can't deal with that, I've 
no business running an openrc-9999 version!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] rfc: renaming "rc" binary in OpenRC

[Rich Freeman]

On Wed, Dec 11, 2013 at 3:47 PM, Chris Reffett <creffett@gentoo.org> wrote:
> The idea of running a sed on inittab in an ebuild, no matter what the
> context, terrifies me. Perhaps we can ease this in slowly by renaming rc ->
> openrc and symlinking rc -> openrc and making a release with that change
> concurrent with a news item? Or even just do that in the ebuild rather than
> in the actual sources. I don't think Debian will keel over and die if it
> takes a little extra time for the change to go through, and it beats a ton
> of broken systems.

++

No reason the symlink couldn't be done in the ebuild either - which
keeps the package itself clean.  There could be news to clean up
inittab and such, and then perhaps down the road the compat symlink
could be removed.

Nice to see interest in Debian (granted, I know there was interest
quite a while back).  Having more and better options is just good for
everybody - I'd like to see OpenRC become the best traditional-style
service manager around (though honestly I'd be hard-pressed to think
of any that are quite as good already).

I think one thing that would be nice to dream about someday would be a
systemd-compatibility init.d script.  That would be symlinked to a
service name just like a typical network interface script, and would
look for a unit file and interpret it (perhaps just taking a path from
conf.d).  I'd think it wouldn't be hard to do, setting aside the more
active-management features of systemd.

Rich

Re: [gentoo-dev] Re: rfc: renaming "rc" binary in OpenRC

[William Hubbs]

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

On Wed, Dec 11, 2013 at 09:28:09PM +0000, Duncan wrote:
> Markos Chandras posted on Wed, 11 Dec 2013 20:53:04 +0000 as excerpted:
> 
> > On 12/11/2013 08:47 PM, Chris Reffett wrote:
> >> On 12/11/2013 3:41 PM, William Hubbs wrote:
> >>>
> >>> My thought is to rename our "rc" to "openrc", since that would be
> >>> unique.
> >>>
> >>> I know at least one thing that will break is everyone's inittab, so
> >>> should I sed their inittab in our live ebuild or expect them to fix it
> >>> and give a warning? I know that once OpenRC with this change is
> >>> released, it will need to probably be p.masked until there is a new
> >>> release of sysvinit that updates the inittab.
> 
> >> The idea of running a sed on inittab in an ebuild, no matter what the
> >> context, terrifies me. Perhaps we can ease this in slowly by renaming
> >> rc -> openrc and symlinking rc -> openrc and making a release with that
> >> change concurrent with a news item? Or even just do that in the ebuild
> >> rather than in the actual sources. I don't think Debian will keel over
> >> and die if it takes a little extra time for the change to go through,
> >> and it beats a ton of broken systems.
> 
> > +1
> > 
> > The ebuild can grep the inittab and it if finds an "rc" there, just
> > print a huge warning telling the user to migrate || die.
> 
> I think it's worth noting two small details of williamh's original mail 
> that may have gone unnoticed:
> 
> 1) He proposes seding the *LIVE* ebuild, which I take as meaning 
> openrc-9999.
> 
> 2) He then proposes p.masking an openrc release until a sysvinit release 
> updating inittab, with the contrast between that and the LIVE ebuild 
> proposal thus again emphasized.
> 
> Question: How many people run the openrc-9999 LIVE ebuild, and given that 
> it's masked and general gentoo policy is that people running live ebuilds 
> should expect to keep the pieces of they can't handle occasionally 
> unpredicted changes, how much should we actually worry about doing just 
> that?

We don't have to worry about the live ebuild per se, I was more
concerned about what to do when the next release comes out.

Duncan, it sounds like you would know how to recover with the live
ebuild.

But, with the proposal of creating a symlink from /sbin/rc->openrc,
there would no longer be a reason to p.mask the next release, because
people would be able to upgrade. A news item would definitely be
appropriate though.

William


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

Re: [gentoo-dev] rfc: renaming "rc" binary in OpenRC

[William Hubbs]

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

On Wed, Dec 11, 2013 at 09:09:16PM +0000, Markos Chandras wrote:
> If that's the case then I see no reason to go through the migration path
> for users :) The symlink thing can be done immediately.
> I am wondering, wouldn't Debian be able to rename "rc" to "openrc" in
> their openrc package just before merging it to the read filesystem (I
> assume Debian also builds and installs in sandbox first?)? In this case
> we will not have to touch openrc (or the ebuild) at all.

No, because of the symlinks that we point to it. Remember that rc is a
multi-call binary. for example, all of the symlinks in /lib*/rc/bin will
have to be adjusted.

William

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

Re: [gentoo-dev] rfc: renaming "rc" binary in OpenRC

[Patrick Lauer]

On 12/12/2013 04:41 AM, William Hubbs wrote:
> All,
> 
> We got a request from Debian to rename the "rc" binary of OpenRC due to
> a naming conflict they have. They have a port of the at&t plan 9 shell,
> which has a binary named "rc" as well[1].
> 
> My thought is to rename our "rc" to "openrc", since that would be
> unique.

Make it build-time configurable. Keep default at "rc". Let Debian and
others rename it as they want/need.

> I know at least one thing that will break is everyone's inittab, so
> should I sed their inittab in our live ebuild or expect them to fix it
> and give a warning?

It's change to change things, it doesn't fix any bugs we have.

So don't break things for fun, please ...

> I know that once OpenRC with this change is
> released, it will need to probably be p.masked until there is a new
> release of sysvinit that updates the inittab.
> 
> I'm not sure what else will break.
> 
> Does anyone have any ideas wrt other things to look for, or should I
> make the changes upstream and have people let us know what
> else breaks?
> 
> William
> 
> [1] https://bugs.gentoo.org/show_bug.cgi?id=493958
> 

Re: [gentoo-dev] rfc: renaming "rc" binary in OpenRC

[Patrick Lauer]

On 12/12/2013 05:28 AM, Rich Freeman wrote:
> On Wed, Dec 11, 2013 at 3:47 PM, Chris Reffett <creffett@gentoo.org> wrote:
>> The idea of running a sed on inittab in an ebuild, no matter what the
>> context, terrifies me. Perhaps we can ease this in slowly by renaming rc ->
>> openrc and symlinking rc -> openrc and making a release with that change
>> concurrent with a news item? Or even just do that in the ebuild rather than
>> in the actual sources. I don't think Debian will keel over and die if it
>> takes a little extra time for the change to go through, and it beats a ton
>> of broken systems.
> 
> ++
> 
> No reason the symlink couldn't be done in the ebuild either - which
> keeps the package itself clean.  There could be news to clean up
> inittab and such, and then perhaps down the road the compat symlink
> could be removed.
> 
> Nice to see interest in Debian (granted, I know there was interest
> quite a while back).  Having more and better options is just good for
> everybody - I'd like to see OpenRC become the best traditional-style
> service manager around (though honestly I'd be hard-pressed to think
> of any that are quite as good already).
> 
> I think one thing that would be nice to dream about someday would be a
> systemd-compatibility init.d script.  That would be symlinked to a
> service name just like a typical network interface script, and would
> look for a unit file and interpret it (perhaps just taking a path from
> conf.d).  I'd think it wouldn't be hard to do, setting aside the more
> active-management features of systemd.
> 

Well, given that systemd unit files don't express dependencies ...

I've thought about it and can't figure out a way to make mixed-mode work
sanely, at all. You'd have to either manually order the startup
sequence, or annotate the unit files with dependency info.

Plus you'd need some machinery like socket-activation proxies or you're
throwing away even more (to the point where the unit file is just a way
to run an executable)

I don't think this can be done in a way that adds value to users.

Re: [gentoo-dev] rfc: renaming "rc" binary in OpenRC

[Doug Goldstein]

On Wed, Dec 11, 2013 at 6:37 PM, Patrick Lauer <patrick@gentoo.org> wrote:
> On 12/12/2013 04:41 AM, William Hubbs wrote:
>> All,
>>
>> We got a request from Debian to rename the "rc" binary of OpenRC due to
>> a naming conflict they have. They have a port of the at&t plan 9 shell,
>> which has a binary named "rc" as well[1].
>>
>> My thought is to rename our "rc" to "openrc", since that would be
>> unique.
>
> Make it build-time configurable. Keep default at "rc". Let Debian and
> others rename it as they want/need.
>
>> I know at least one thing that will break is everyone's inittab, so
>> should I sed their inittab in our live ebuild or expect them to fix it
>> and give a warning?
>
> It's change to change things, it doesn't fix any bugs we have.
>
> So don't break things for fun, please ...

Honestly, with Linux systems a symlink won't matter. Just rename the
binary to "openrc" so that we are closer with Debian. It would be nice
if in the future docs and blogs and other things could share the same
info.

For Gentoo just symlink rc -> openrc and call it a day. There's also
no reason to remove the symlink in the next release like others have
said. Keep the thing around for as long as is possible. Cause if you
drop it, you're liable to break someone upgrading an old system and
they have a higher chance to miss an important ewarn and you know how
much I hate breaking upgrades.

-- 
Doug Goldstein

Re: [gentoo-dev] rfc: renaming "rc" binary in OpenRC

[Samuli Suominen]

On 11/12/13 22:41, William Hubbs wrote:
> All,
>
> We got a request from Debian to rename the "rc" binary of OpenRC due to
> a naming conflict they have. They have a port of the at&t plan 9 shell,
> which has a binary named "rc" as well[1].

which we ship as app-shells/rc and rename 'rc' to 'rcsh' for unique name

just saying

[gentoo-dev] Re: rfc: renaming "rc" binary in OpenRC

[Martin Vaeth]

Patrick Lauer <patrick@gentoo.org> wrote:
> On 12/12/2013 05:28 AM, Rich Freeman wrote:
>>
>> I think one thing that would be nice to dream about someday would be a
>> systemd-compatibility init.d script.

[...]

> I don't think this can be done in a way that adds value to users.

The converse is simpler and for certain cases already available
(the short openrc-wrapper script in the mv overlay):
You can use (simple) init.d scripts from within systemd.

Moreover, systemd's static /etc/modules-load.d mechanism can
trivially be emulated with the following line in /etc/conf.d/modules:

modules=$(sed -n -e '/^[^;#]/p' /etc/modules-load.d/*.conf \
   /usr/lib/modules-load.d/*.conf 2>/dev/null)

Using both mechanisms, it is not too hard to setup a system
which can boot with both init systems without duplicating too much
configuration (for that configuration which is in the intersection
of the features of both systems).
Main duplication is the netifrc/netctl setup which
would be way too complex to use outside of openrc/systemd.

Re: [gentoo-dev] rfc: renaming "rc" binary in OpenRC

[Rich Freeman]

On Wed, Dec 11, 2013 at 7:41 PM, Patrick Lauer <patrick@gentoo.org> wrote:
> Well, given that systemd unit files don't express dependencies ...
>

Sure they do.  They declare wants, after, wantedby, etc.  Looking in
my /usr/lib/systemd/system it seems like all the units I looked at
declared their dependencies.  I don't know how systemd could do
parallel service startup otherwise.

Of course, the challenge will be that those dependencies are against
other systemd units/targets/etc and not against openrc scripts.  For
the standards stuff you could translate, or perhaps even create
virtual services as a translation layer.  Also, systemd dependencies
could be against sockets vs full services, so again that is a
translation challenge (though openrc could still wait until the full
service is launched and not manage sockets).

I'm just thinking that in the long term it seems likely that upstream
will be supplying working systemd units, and fairly unlikely to supply
working openrc scripts.  If there is a shift of devs towards running
systemd that could translate into daemons in the tree that don't have
openrc scripts but do have systemd units.  A compatibility layer would
make that less of an issue.  However, just as devs and users
frequently submit systemd units for packages that don't have them, I'm
sure that the same will happen for packages that lack openrc scripts.

Rich

Re: [gentoo-dev] rfc: renaming "rc" binary in OpenRC

[William Hubbs]

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

On Thu, Dec 12, 2013 at 09:41:10AM +0200, Samuli Suominen wrote:
> 
> On 11/12/13 22:41, William Hubbs wrote:
> > All,
> >
> > We got a request from Debian to rename the "rc" binary of OpenRC due to
> > a naming conflict they have. They have a port of the at&t plan 9 shell,
> > which has a binary named "rc" as well[1].
> 
> which we ship as app-shells/rc and rename 'rc' to 'rcsh' for unique name
> 
> just saying

This is a separate topic, but maybe  we should stop renaming it after a
transition period. I am not comfortable with renaming upstream
binaries at the distro level.

William


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

Re: [gentoo-dev] rfc: renaming "rc" binary in OpenRC

[Alexander Berntsen]

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

On 11/12/13 21:41, William Hubbs wrote:
> My thought is to rename our "rc" to "openrc", since that would be 
> unique.
orc is shorter and more punny (nice excuse for designing an orcish cow
mascot).

On 11/12/13 22:04, William Hubbs wrote:> On Wed, Dec 11, 2013 at
10:47:49PM +0200, Alon Bar-Lev wrote:
>> are you going to rename also rc-service and rc-update?
> 
> No, there isn't a need for that, just "rc".
Please rename all of them, to provide uniform naming. This way, typing
orc, and tab-tabing in BASH will give you a list of orc-related
executables, just like with rc now.

- -- 
Alexander
alexander@plaimi.net
http://plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlKp2lcACgkQRtClrXBQc7XnwgEAsA4Z7Zgw351tyP9QfbVqOPK6
KYXCvKXqqJGpcDKvgRIA/jbIWS10BR/7a/kmeOUIeo50qOU4GehQ7PwKWHzI4tUS
=SLXN
-----END PGP SIGNATURE-----

Re: [gentoo-dev] rfc: renaming "rc" binary in OpenRC

[Samuli Suominen]

On 12/12/13 17:46, Alexander Berntsen wrote:
> On 11/12/13 21:41, William Hubbs wrote:
> > My thought is to rename our "rc" to "openrc", since that would be
> > unique.
> orc is shorter and more punny (nice excuse for designing an orcish cow
> mascot).
>

orc is dev-lang/orc, with binaries like orc-bugreport

> On 11/12/13 22:04, William Hubbs wrote:> On Wed, Dec 11, 2013 at
> 10:47:49PM +0200, Alon Bar-Lev wrote:
> >> are you going to rename also rc-service and rc-update?
>
> > No, there isn't a need for that, just "rc".
> Please rename all of them, to provide uniform naming. This way, typing
> orc, and tab-tabing in BASH will give you a list of orc-related
> executables, just like with rc now.
>

as said, with tab completion, orc-* would just get mixed up with
binaries from dev-lang/orc

Re: [gentoo-dev] rfc: renaming "rc" binary in OpenRC

[Alexander Berntsen]

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

On 13/12/13 13:31, Samuli Suominen wrote:
> orc is dev-lang/orc, with binaries like orc-bugreport
That's fine. There is no binary, orc.

> as said, with tab completion, orc-* would just get mixed up with 
> binaries from dev-lang/orc

Tab-completing orc- will only have one executable not related to
openrc. If you tab-complete "open" (which is already longer to type)
on most systems, you get a lot more. So you'd have to tab-complete
openrc. That's a lot longer than orc-.

Also, I would just tab-complete orc. orcc is obviously a compiler.
Most people have rcc (also obviously a compiler) on their system, so
we have that "issue" now as well.

So to sum up: I still think it's fine to call it orc. But honestly,
there are no catastrophic candidates. Any further discussion is mostly
just bikeshedding. Let's just nominate some candidates and vote. :-)
- -- 
Alexander
alexander@plaimi.net
http://plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlKrDBYACgkQRtClrXBQc7XK1gEArFhx0BE2eELesWVQ1p0KyxKC
TEkWlaqZZsxhvSTHf5cA/2jlE5QcODLk765pbmppIB/aw32BfVYSNxUHXssY4tsx
=iAkb
-----END PGP SIGNATURE-----

Re: [gentoo-dev] rfc: renaming "rc" binary in OpenRC

[Mike Gilbert]

On Thu, Dec 12, 2013 at 10:46 AM, Alexander Berntsen
<alexander@plaimi.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 11/12/13 21:41, William Hubbs wrote:
>> My thought is to rename our "rc" to "openrc", since that would be
>> unique.
> orc is shorter and more punny (nice excuse for designing an orcish cow
> mascot).
>
> On 11/12/13 22:04, William Hubbs wrote:> On Wed, Dec 11, 2013 at
> 10:47:49PM +0200, Alon Bar-Lev wrote:
>>> are you going to rename also rc-service and rc-update?
>>
>> No, there isn't a need for that, just "rc".
> Please rename all of them, to provide uniform naming. This way, typing
> orc, and tab-tabing in BASH will give you a list of orc-related
> executables, just like with rc now.
>

That makes no sense; there is almost no reason to manually invoke the
"rc" binary currently, an Gentoo users are already familiar with names
like "rc-update" and "service".

Renaming everything just forces users to learn new command names for no reason.

Re: [gentoo-dev] rfc: renaming "rc" binary in OpenRC

[William Hubbs]

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

On Fri, Dec 13, 2013 at 10:59:35AM -0500, Mike Gilbert wrote:
> On Thu, Dec 12, 2013 at 10:46 AM, Alexander Berntsen
> <alexander@plaimi.net> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> > On 11/12/13 21:41, William Hubbs wrote:
> >> My thought is to rename our "rc" to "openrc", since that would be
> >> unique.
> > orc is shorter and more punny (nice excuse for designing an orcish cow
> > mascot).
> >
> > On 11/12/13 22:04, William Hubbs wrote:> On Wed, Dec 11, 2013 at
> > 10:47:49PM +0200, Alon Bar-Lev wrote:
> >>> are you going to rename also rc-service and rc-update?
> >>
> >> No, there isn't a need for that, just "rc".
> > Please rename all of them, to provide uniform naming. This way, typing
> > orc, and tab-tabing in BASH will give you a list of orc-related
> > executables, just like with rc now.
> >
> 
> That makes no sense; there is almost no reason to manually invoke the
> "rc" binary currently, an Gentoo users are already familiar with names
> like "rc-update" and "service".
 
 There are reasons to run the rc binary directly; this is how you should
 be changing runlevels.

> Renaming everything just forces users to learn new command names for no reason.

Right, there is no reason to rename everything.

In git, what I've done is rename rc to openrc and provide rc as a
backward compatibility symlink.

I agree with the comment earlier in the thread; debating the name is
just bikeshedding.

William


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

[gentoo-dev] Re: rfc: renaming "rc" binary in OpenRC

[Duncan]

William Hubbs posted on Fri, 13 Dec 2013 11:23:07 -0600 as excerpted:

>  There are reasons to run the rc binary directly; this is how you should
>  be changing runlevels.

???

init 9 (or telinit 9, yes, I have a runlevel 9, basic, just gpm as it 
happens) isn't appropriate?

Of course, with gentoo's inittab, init then simply calls rc, but if rc is 
called directly, how does init know to change its runlevel, as seen as if 
it were passed on its commandline in top, etc?  And what about additional 
wait/once/respawn entries?  How will init know to take care of them?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: rfc: renaming "rc" binary in OpenRC

[William Hubbs]

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

On Fri, Dec 13, 2013 at 07:53:59PM +0000, Duncan wrote:
> William Hubbs posted on Fri, 13 Dec 2013 11:23:07 -0600 as excerpted:
> 
> >  There are reasons to run the rc binary directly; this is how you should
> >  be changing runlevels.
> 
> ???
> 
> init 9 (or telinit 9, yes, I have a runlevel 9, basic, just gpm as it 
> happens) isn't appropriate?

Well, I have to qualify what I said.

There are two "runlevels" you have to worry about.
The OpenRC runlevels are named; you can switch between these using rc
directly, for example:

rc default
rc single
rc nonetwork

The sysvinit runlevels are the numbered ones, and these are mapped to
things to run, like 3 is mapped to /sbin/rc default. I believe runlevel
3 is mapped to other things in inittab, so, I guess the best answer is,
it depends on what you are wanting to change. Does that make sense?

William


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

[gentoo-dev] Re: rfc: renaming "rc" binary in OpenRC

[Duncan]

William Hubbs posted on Fri, 13 Dec 2013 16:03:57 -0600 as excerpted:

> On Fri, Dec 13, 2013 at 07:53:59PM +0000, Duncan wrote:
>> William Hubbs posted on Fri, 13 Dec 2013 11:23:07 -0600 as excerpted:
>> 
>>>  There are reasons to run the rc binary directly; this is how you
>>>  should be changing runlevels.
>> 
>> ???
>> 
>> init 9 (or telinit 9, yes, I have a runlevel 9, basic, just gpm as it
>> happens) isn't appropriate?
> 
> Well, I have to qualify what I said.
> 
> There are two "runlevels" you have to worry about.
> The OpenRC runlevels are named; you can switch between these using rc
> directly, for example:
> 
> rc default
> rc single
> rc nonetwork
> 
> The sysvinit runlevels are the numbered ones, and these are mapped to
> things to run, like 3 is mapped to /sbin/rc default. I believe runlevel
> 3 is mapped to other things in inittab, so, I guess the best answer is,
> it depends on what you are wanting to change. Does that make sense?

Yes, it does.  Thanks.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman