[gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Robin H. Johnson]

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

Hi folks,

This is a summary of how to detect Baselayout-2/OpenRC from within
init.d scripts. We raised it in January, without any actual final
agreement:
http://archives.gentoo.org/gentoo-dev/msg_5959bcfaf3ba566c551823039643f5c5.xml

Also, there were some items that weren't raised in the previous
discussion:
- The Vserver team needs the actual version of OpenRC, AND it must be
  available without any exec()/fork()/clone() calls.
- init.d/sysfs might be removed on some embedded systems.

The final solution that everybody agreed on is as follows.
1. OpenRC will provide /libexec/rc/version, a text file containing the
   version (possible including a git ID) of the release.
2. Right now, every init.d script that needs to detection should revbump
   and change to the following:
   [[ -f /lib/librc.so -o -f /etc/init.d/sysfs -o -f /libexec/rc/version ]]
   This allows a safe migration.
3. Approximately 6 months after OpenRC and Baselayout2 go stable, the
   detection will drop to:
   [[ -f /libexec/rc/version ]]
4. For vserver and anybody else that needs the version details of
   OpenRC, you get to read the file, and RDEPEND on the minimal package
   version you want.

GDP team:
(I didn't hear from you in the bug)
Could you please update:
- handbook section "Writing Init scripts"
- OpenRC migration guide

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

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

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Samuli Suominen]

Robin H. Johnson wrote:
> GDP team:
> (I didn't hear from you in the bug)
> Could you please update:
> - handbook section "Writing Init scripts"
> - OpenRC migration guide

ACK on this one, we are already overwhelmed by openrc changes wrt init
scripts at media teams. Or at least, I am.

Thanks, Samuli

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Josh Saddler]

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

Samuli Suominen wrote:
> Robin H. Johnson wrote:
>> GDP team:
>> (I didn't hear from you in the bug)
>> Could you please update:
>> - handbook section "Writing Init scripts"
>> - OpenRC migration guide
> 
> ACK on this one, we are already overwhelmed by openrc changes wrt init
> scripts at media teams. Or at least, I am.

Then, my fellow developers, ya'll need to tell us exactly what needs to
change. That has not yet happened on the bugs, just a lot of offtopic
discussion relevant to the package maintainers, but not to the GDP for
documentation purposes. Just because there's lots of chatter on e.g.
http://bugs.gentoo.org/show_bug.cgi?id=270646 doesn't mean that the GDP
has any idea of how to proceed.

GuideXML patches are nice, but not necessary. What we *do* need, at a
minimum, is a concise description of what the current text says, and
what it needs to say. Thanks.

* * *

Also, if OpenRC/baselayout is dropping support for things like PPP or
ADSL[1], and will not guarantee a "stable" configuration (i.e. as
"final" as baselayout-1 has been, not needing constant user-side
updates)[2] . . . then we need to find some other solution for our users.

If upstream doesn't ever want to slow down, wants to constantly stick in
new features, try out new things, that's all well and good. More power
to 'em. But I think that is ultimately not such a good thing for our
users. Especially if it means constantly dropping support for features,
sacrificing compatibility, etc. We're already having enough trouble
trying to ensure future Portage compatibility via EAPIs, we should not
add in a potential baselayout/OpenRC mess atop that.

Oh, yes . . . and there's the workload it would put on the GDP folks. We
already have a helluva time running around chasing devs down and prying
out straight answers about what to update in the existing documentation.
We'd probably all quit if we had to do the same thing for every new
openrc/baselayout release.

[1]
http://news.gmane.org/find-root.php?message_id=%3c200905252003.42176.rbu%40gentoo.org%3e
[2]
http://news.gmane.org/find-root.php?message_id=%3c200905252003.42176.rbu%40gentoo.org%3e


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

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Roy Marples]

Josh Saddler wrote:
> Also, if OpenRC/baselayout is dropping support for things like PPP or
> ADSL[1], and will not guarantee a "stable" configuration (i.e. as
> "final" as baselayout-1 has been, not needing constant user-side
> updates)[2] . . . then we need to find some other solution for our users.

Just to clarify - net.lo and friends, along with bash specific configs 
are NOT going away. They're just not actively being developed with new 
features, nor will they get priority for any fixes. However, net.lo nor 
the modules are installed by default (MKOLDNET=yes is required).

So existing documentation works just fine.

Also, writing documentation to support things like ADSL and PPP now 
entirely depends on upstream working with new stuff. For example, 
wpa_supplicant does not react by itself to hotplugged interfaces and the 
  new OpenRC network script no longer supports per interface 
start/stops. This is a problem, and I've spent some time working on 
patches to wpa_supplicant for this, but upstream is not sure about the 
whole idea.

> If upstream doesn't ever want to slow down, wants to constantly stick in
> new features, try out new things, that's all well and good. More power
> to 'em. But I think that is ultimately not such a good thing for our
> users. Especially if it means constantly dropping support for features,
> sacrificing compatibility, etc. We're already having enough trouble
> trying to ensure future Portage compatibility via EAPIs, we should not
> add in a potential baselayout/OpenRC mess atop that.

Development on OpenRC has slowed down a lot of late, mainly as most of 
my goals of where it should go have now been met. And with moving 
networking to a very simple script, future changes will only be on a per 
init script basis. As OpenRC just supplies enough init scripts to boot a 
basic system any future changes will be in the init scripts themselves 
and thus removed from OpenRC specific documentation.

Of course that doesn't stop various upstreams that Gentoo uses from 
totally changing their user interface.

> Oh, yes . . . and there's the workload it would put on the GDP folks. We
> already have a helluva time running around chasing devs down and prying
> out straight answers about what to update in the existing documentation.
> We'd probably all quit if we had to do the same thing for every new
> openrc/baselayout release.

You could always try writing the code instead ;)

Thanks

Roy

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Robin H. Johnson]

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

On Sun, Jun 07, 2009 at 01:45:15PM -0700, Josh Saddler wrote:
> Then, my fellow developers, ya'll need to tell us exactly what needs to
> change. That has not yet happened on the bugs, just a lot of offtopic
> discussion relevant to the package maintainers, but not to the GDP for
> documentation purposes. Just because there's lots of chatter on e.g.
> http://bugs.gentoo.org/show_bug.cgi?id=270646 doesn't mean that the GDP
> has any idea of how to proceed.
The final decision was pretty clear I thought, but I've written out the text of
what you need to add, so that you can add it ASAP to the documentation.

In handbook section "4.d. Writing Init Scripts", please add a link to the
OpenRC migration document. Alternatively, add everything below to the 4.d
block, and a link BACK from the OpenRC migration document to the portion of the
handbook.

The following goes into openrc-migration.xml:
Add a new toplevel L1 block, after the 'Finishing Up' L2 block:

=============

<h1>Converting init.d scripts</h1>
<note>
  This section is intended primarily for developers, but is also relevant to
  anybody with custom init.d scripts.
</note>
<h2>Detecting OpenRC</h2>
<p>
  If your init.d script needs to detect being run under OpenRC specifically to
  perform different actions, you are strongly encourage to use the following as
  the means of detecting OpenRC:
</p>
<code description="OpenRC detection test, transitional">
  [[ -f /lib/librc.so -o -f /etc/init.d/sysfs -o -f /libexec/rc/version ]]
</code>

<code description="Example usage">
depend() {
  if [[ -f /lib/librc.so -o -f /etc/init.d/sysfs -o -f /libexec/rc/version ]]; then
    need sysfs
  fi
}
start() {
  echo foobar >/sys/...
}
</code>

<p>
  After $DATE [1], the official detection test will be:
</p>
<code description="OpenRC detection test, final">
  [[ -f /libexec/rc/version ]]
</code>
<h2>Detecting the OpenRC version</h2>
<p>
  If you need to know the exact version of OpenRC, you should RDEPEND on the
  minimum version, and then read the file as follows:
</p>
<code description="OpenRC version query">
  read version </libexec/rc/version
</code>

=============
I've just put $DATE in here since we don't know when yet.

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

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

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Josh Saddler]

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

Robin H. Johnson wrote:
> [stuff]

Thanks, will take a look.


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

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Ulrich Mueller]

>>>>> On Sun, 7 Jun 2009, Robin H Johnson wrote:

> 2. Right now, every init.d script that needs to detection should revbump
>    and change to the following:
>    [[ -f /lib/librc.so -o -f /etc/init.d/sysfs -o -f /libexec/rc/version ]]

Wasn't the convention for init scripts to use only single square
brackets, i.e. POSIX shell syntax?

Ulrich

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Robin H. Johnson]

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

On Mon, Jun 08, 2009 at 12:02:44AM +0200, Ulrich Mueller wrote:
> >>>>> On Sun, 7 Jun 2009, Robin H Johnson wrote:
> > 2. Right now, every init.d script that needs to detection should revbump
> >    and change to the following:
> >    [[ -f /lib/librc.so -o -f /etc/init.d/sysfs -o -f /libexec/rc/version ]]
> Wasn't the convention for init scripts to use only single square
> brackets, i.e. POSIX shell syntax?
That was raised in the bug as well. My testing was with bash --posix, so
if that doesn't implement POSIX correctly, then yes, we'd need to
change.

Roy: [[ or [?

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

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

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Roy Marples]

Robin H. Johnson wrote:
> On Mon, Jun 08, 2009 at 12:02:44AM +0200, Ulrich Mueller wrote:
>>>>>>> On Sun, 7 Jun 2009, Robin H Johnson wrote:
>>> 2. Right now, every init.d script that needs to detection should revbump
>>>    and change to the following:
>>>    [[ -f /lib/librc.so -o -f /etc/init.d/sysfs -o -f /libexec/rc/version ]]
>> Wasn't the convention for init scripts to use only single square
>> brackets, i.e. POSIX shell syntax?
> That was raised in the bug as well. My testing was with bash --posix, so
> if that doesn't implement POSIX correctly, then yes, we'd need to
> change.
> 
> Roy: [[ or [?

Entirely depends on system.
OpenRC uses /bin/sh to process the actual init script. We rely on 
/bin/sh claiming POSIX compat [1]. On Gentoo Linux systems, this is 
normally a link to bash, so you can use bashisms if you so wish.

However, on Gentoo FreeBSD systems, or Gentoo Embedded systems that 
predominately use busybox then the bashisms won't obviously work. So the 
question becomes, does the init script developer want to support non 
bash by default systems?

Franky, I've given up on trying to enforce anything POSIX related over 
something else (like say GNU or implementation extensions over an 
accepted standard). I just don't care. I used to, but developer and user 
backlash (see the archives) was just too much for me and was one of the 
resaons why I retired from Gentoo.

Just Do What The Fuck You Like, Just Don't Bug Me pretty much somes up 
my attitude right now. Why do I have this attiude? Well, bug #175783 is 
a very good example. It's over two years since I submitted replacement 
scripts and did more besides. It's just like the courier-imap fiasco 
when baselayout-1.12 was touted for stable, but this time I Just Don't Care.

But as you asked, here's what the good doc [1] has to say

The following words may be recognized as reserved words on some 
implementations (when none of the characters are quoted), causing 
unspecified results:
[[ ]] function select

In other words, I won/t make any claims whether [[ ]] works in OpenRC.

Thanks

Roy

[1] http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Robin H. Johnson]

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

On Mon, Jun 08, 2009 at 12:00:59AM +0100, Roy Marples wrote:
>> Roy: [[ or [?
> Entirely depends on system.
> OpenRC uses /bin/sh to process the actual init script. We rely on /bin/sh 
> claiming POSIX compat [1]. On Gentoo Linux systems, this is normally a link 
> to bash, so you can use bashisms if you so wish.
Is "[[" a bashism or not? That's all I'm asking. 
What's a good way to test for POSIX compatibility so that the testing
CAN actually be done. My testcase was 'bash --posix'. Testing under
busybox's ash seems to work perfectly with "[[" as well.

> But as you asked, here's what the good doc [1] has to say
> The following words may be recognized as reserved words on some 
> implementations (when none of the characters are quoted), causing 
> unspecified results:
> [[ ]] function select
> In other words, I won/t make any claims whether [[ ]] works in OpenRC.
That doesn't answer if it's a bashism. I interpret that part of the
document to simply be that it's implementation detail is not covered by
the POSIX spec.

> Franky, I've given up on trying to enforce anything POSIX related over 
> something else (like say GNU or implementation extensions over an accepted 
> standard). I just don't care. I used to, but developer and user backlash 
> (see the archives) was just too much for me and was one of the resaons why 
> I retired from Gentoo.
I'm all for going with something that will work more globally, IFF it
can be easily tested for (on pure Gentoo Linux machines, which is what
most developers are running, because they won't be bothered to test
under G/FBSD or Prefix/OSX etc), vs. just going by what the
specification says.

> Just Do What The Fuck You Like, Just Don't Bug Me pretty much somes up my 
> attitude right now. Why do I have this attiude? Well, bug #175783 is a very 
> good example. It's over two years since I submitted replacement scripts and 
> did more besides. It's just like the courier-imap fiasco when 
> baselayout-1.12 was touted for stable, but this time I Just Don't Care.
There hasn't been any release of the mysql-init-scripts in 2 years.
It's not that anything contrary to your opinions has been done on that
bug, it's more that I haven't have any specific need to fix that package
yet. That bug there also raised the openrc detection issue. I hadn't
read the comments in it for nearly a year now.

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

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

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Ulrich Mueller]

>>>>> On Sun, 7 Jun 2009, Robin H Johnson wrote:

> Is "[[" a bashism or not? That's all I'm asking. 

/bin/sh under FreeBSD 7.0:
   $ [[ -n "foo" ]]
   [[: not found

Ulrich

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Roy Marples]

Robin H. Johnson wrote:
> On Mon, Jun 08, 2009 at 12:00:59AM +0100, Roy Marples wrote:
>>> Roy: [[ or [?
>> Entirely depends on system.
>> OpenRC uses /bin/sh to process the actual init script. We rely on /bin/sh 
>> claiming POSIX compat [1]. On Gentoo Linux systems, this is normally a link 
>> to bash, so you can use bashisms if you so wish.
> Is "[[" a bashism or not? That's all I'm asking. 
> What's a good way to test for POSIX compatibility so that the testing
> CAN actually be done. My testcase was 'bash --posix'. Testing under
> busybox's ash seems to work perfectly with "[[" as well.

bash(1) only documents the --posix option to modify how bash starts up. 
It does not mention restricting bash extensions such as [[

IIRC vapier patched busybox to alias [[ to [, which is worse as you 
still have to quote correctly as if [ and you don't get the =~ operator 
from [[.

> 
>> But as you asked, here's what the good doc [1] has to say
>> The following words may be recognized as reserved words on some 
>> implementations (when none of the characters are quoted), causing 
>> unspecified results:
>> [[ ]] function select
>> In other words, I won/t make any claims whether [[ ]] works in OpenRC.
> That doesn't answer if it's a bashism. I interpret that part of the
> document to simply be that it's implementation detail is not covered by
> the POSIX spec.

If it's not in the spec, then it has to be an extension. Thus, if bash 
is extending it then it's a bashism.

> I'm all for going with something that will work more globally, IFF it
> can be easily tested for (on pure Gentoo Linux machines, which is what
> most developers are running, because they won't be bothered to test
> under G/FBSD or Prefix/OSX etc), vs. just going by what the
> specification says.

The only available shell on Linux that doesn't do anything other than 
the POSIX spec is dash. However, even that shell is not entirely 
compliant (a few missing features last I looked).

>> Just Do What The Fuck You Like, Just Don't Bug Me pretty much somes up my 
>> attitude right now. Why do I have this attiude? Well, bug #175783 is a very 
>> good example. It's over two years since I submitted replacement scripts and 
>> did more besides. It's just like the courier-imap fiasco when 
>> baselayout-1.12 was touted for stable, but this time I Just Don't Care.
> There hasn't been any release of the mysql-init-scripts in 2 years.
> It's not that anything contrary to your opinions has been done on that
> bug, it's more that I haven't have any specific need to fix that package
> yet.

Other than the need to actually allow mysql to work on Gentoo/FreeBSD.
Ah, you've already said that you don't want to run anything other than 
Linux. Fine, that's your choice, but please hand mysql over to someone 
who cares about Gentoo running on alternative OS's as you've just 
demonstrated you just don't care.

Thanks

Roy

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Mike Frysinger]

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

On Monday 08 June 2009 06:00:14 Roy Marples wrote:
> Robin H. Johnson wrote:
> > On Mon, Jun 08, 2009 at 12:00:59AM +0100, Roy Marples wrote:
> IIRC vapier patched busybox to alias [[ to [, which is worse as you
> still have to quote correctly as if [ and you don't get the =~ operator
> from [[.

i reverted that from busybox' ash a while ago

> > I'm all for going with something that will work more globally, IFF it
> > can be easily tested for (on pure Gentoo Linux machines, which is what
> > most developers are running, because they won't be bothered to test
> > under G/FBSD or Prefix/OSX etc), vs. just going by what the
> > specification says.
>
> The only available shell on Linux that doesn't do anything other than
> the POSIX spec is dash. However, even that shell is not entirely
> compliant (a few missing features last I looked).

and a few extra :p

busybox' hush is pretty good, but not as widely tested yet
-mike

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

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Mike Frysinger]

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

On Sunday 07 June 2009 15:59:50 Robin H. Johnson wrote:
> 1. OpenRC will provide /libexec/rc/version, a text file containing the
>    version (possible including a git ID) of the release.

that requires us to actually utilize /libexec/ which is not a Linux convention 
on any system ive ever seen.  i dont think we should start for one package.  i 
didnt see any problem with using /etc/openrc-release ?
-mike

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

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Roy Marples]

Mike Frysinger wrote:
> On Sunday 07 June 2009 15:59:50 Robin H. Johnson wrote:
>> 1. OpenRC will provide /libexec/rc/version, a text file containing the
>>    version (possible including a git ID) of the release.
> 
> that requires us to actually utilize /libexec/ which is not a Linux convention 
> on any system ive ever seen.

OpenRC works on systems other than Linux and uses the best hierarchy it 
can to match them all.

Linux has /usr/libexec and I see no reason why it cannot exist on / for 
when /usr is not available like other OS's do.

Robin asked for an upstream decision of where to place the version file 
and in the OpenRC world the best place is /libexec as /etc is just meant 
for user configuration.

Thanks

Roy

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Mike Frysinger]

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

On Monday 08 June 2009 06:12:04 Roy Marples wrote:
> Mike Frysinger wrote:
> > On Sunday 07 June 2009 15:59:50 Robin H. Johnson wrote:
> >> 1. OpenRC will provide /libexec/rc/version, a text file containing the
> >>    version (possible including a git ID) of the release.
> >
> > that requires us to actually utilize /libexec/ which is not a Linux
> > convention on any system ive ever seen.
>
> OpenRC works on systems other than Linux and uses the best hierarchy it
> can to match them all.

i know why you use it, but that doesnt mean Gentoo (Linux) should

> Linux has /usr/libexec and I see no reason why it cannot exist on / for
> when /usr is not available like other OS's do.
>
> Robin asked for an upstream decision of where to place the version file
> and in the OpenRC world the best place is /libexec as /etc is just meant
> for user configuration.

maybe, but since we arent going to use /libexec/ at this time, that means /etc 
is the next best place
-mike

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

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Roy Marples]

Mike Frysinger wrote:
> On Monday 08 June 2009 06:12:04 Roy Marples wrote:
>> Mike Frysinger wrote:
>>> On Sunday 07 June 2009 15:59:50 Robin H. Johnson wrote:
>>>> 1. OpenRC will provide /libexec/rc/version, a text file containing the
>>>>    version (possible including a git ID) of the release.
>>> that requires us to actually utilize /libexec/ which is not a Linux
>>> convention on any system ive ever seen.
>> OpenRC works on systems other than Linux and uses the best hierarchy it
>> can to match them all.
> 
> i know why you use it, but that doesnt mean Gentoo (Linux) should

rhetorical:
Should Gentoo (FreeBSD)?
Also, should Gentoo (Linux) never break with tradition even if 
somethings are better elsewhere?

Note, I'm not pushing for Gentoo to use /libexec at all, but you'll have 
to move the version file in the ebuild as it just won't work when you 
pass LIBEXECDIR=/lib/rc to the make targets.

Thanks

Roy

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Mike Frysinger]

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

On Monday 08 June 2009 06:35:37 Roy Marples wrote:
> Mike Frysinger wrote:
> > On Monday 08 June 2009 06:12:04 Roy Marples wrote:
> >> Mike Frysinger wrote:
> >>> On Sunday 07 June 2009 15:59:50 Robin H. Johnson wrote:
> >>>> 1. OpenRC will provide /libexec/rc/version, a text file containing the
> >>>>    version (possible including a git ID) of the release.
> >>>
> >>> that requires us to actually utilize /libexec/ which is not a Linux
> >>> convention on any system ive ever seen.
> >>
> >> OpenRC works on systems other than Linux and uses the best hierarchy it
> >> can to match them all.
> >
> > i know why you use it, but that doesnt mean Gentoo (Linux) should
>
> rhetorical:
> Should Gentoo (FreeBSD)?

that's for the Gentoo/BSD team to decide

> Also, should Gentoo (Linux) never break with tradition even if
> somethings are better elsewhere?

no, there is no "innovation" here nor any incentive to do so.  i also 
personally dont believe in /usr/libexec/, so i'm not going to randomly be 
convinced by /libexec/ in the meantime.

> Note, I'm not pushing for Gentoo to use /libexec at all, but you'll have
> to move the version file in the ebuild as it just won't work when you
> pass LIBEXECDIR=/lib/rc to the make targets.

if the make system doesnt have a way of controlling the root libexecdir path, 
sounds like the make system is limited and/or broken and in need of fixing
-mike

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

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Roy Marples]

Mike Frysinger wrote:
> On Monday 08 June 2009 06:35:37 Roy Marples wrote:
>> Mike Frysinger wrote:
>>> On Monday 08 June 2009 06:12:04 Roy Marples wrote:
>>>> Mike Frysinger wrote:
>>>>> On Sunday 07 June 2009 15:59:50 Robin H. Johnson wrote:
>>>>>> 1. OpenRC will provide /libexec/rc/version, a text file containing the
>>>>>>    version (possible including a git ID) of the release.
>>>>> that requires us to actually utilize /libexec/ which is not a Linux
>>>>> convention on any system ive ever seen.
>>>> OpenRC works on systems other than Linux and uses the best hierarchy it
>>>> can to match them all.
>>> i know why you use it, but that doesnt mean Gentoo (Linux) should
>> rhetorical:
>> Should Gentoo (FreeBSD)?
> 
> that's for the Gentoo/BSD team to decide

So you're now advocating the check being

[ -f /etc/openrc-version -o -f /libexec/rc/version ]

Way to go.

> 
>> Also, should Gentoo (Linux) never break with tradition even if
>> somethings are better elsewhere?
> 
> no, there is no "innovation" here nor any incentive to do so.  i also 
> personally dont believe in /usr/libexec/, so i'm not going to randomly be 
> convinced by /libexec/ in the meantime.

The "innovation" here being shell scripts and text files are not 32/64 
bit dependent and thus don't belong in a directory clearly marked as such.

> 
>> Note, I'm not pushing for Gentoo to use /libexec at all, but you'll have
>> to move the version file in the ebuild as it just won't work when you
>> pass LIBEXECDIR=/lib/rc to the make targets.
> 
> if the make system doesnt have a way of controlling the root libexecdir path, 
> sounds like the make system is limited and/or broken and in need of fixing

Eh? I just told you it does. To keep the status quo with /libexec/rc vs 
/lib/rc I provide a make knob. Now you want to move 1 specific file out 
of /lib/rc (because it could be in /lib64 or /lib32 and not in /lib) and 
into /etc because of the /lib brokenness.

Thanks

Roy

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Mike Frysinger]

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

On Monday 08 June 2009 07:03:37 Roy Marples wrote:
> Mike Frysinger wrote:
> > On Monday 08 June 2009 06:35:37 Roy Marples wrote:
> >> Mike Frysinger wrote:
> >>> On Monday 08 June 2009 06:12:04 Roy Marples wrote:
> >>>> Mike Frysinger wrote:
> >>>>> On Sunday 07 June 2009 15:59:50 Robin H. Johnson wrote:
> >>>>>> 1. OpenRC will provide /libexec/rc/version, a text file containing
> >>>>>> the version (possible including a git ID) of the release.
> >>>>>
> >>>>> that requires us to actually utilize /libexec/ which is not a Linux
> >>>>> convention on any system ive ever seen.
> >>>>
> >>>> OpenRC works on systems other than Linux and uses the best hierarchy
> >>>> it can to match them all.
> >>>
> >>> i know why you use it, but that doesnt mean Gentoo (Linux) should
> >>
> >> rhetorical:
> >> Should Gentoo (FreeBSD)?
> >
> > that's for the Gentoo/BSD team to decide
>
> So you're now advocating the check being
>
> [ -f /etc/openrc-version -o -f /libexec/rc/version ]

the openrc ebuild will always provide a file in /etc regardless of libexec 
path

> Way to go.

try not to douche up the thread

> >> Also, should Gentoo (Linux) never break with tradition even if
> >> somethings are better elsewhere?
> >
> > no, there is no "innovation" here nor any incentive to do so.  i also
> > personally dont believe in /usr/libexec/, so i'm not going to randomly be
> > convinced by /libexec/ in the meantime.
>
> The "innovation" here being shell scripts and text files are not 32/64
> bit dependent and thus don't belong in a directory clearly marked as such.

ABI is really not the driving force behind libexec vs lib, nor does it really 
matter here.  openrc isnt a multilib package nor does it need to be.

> >> Note, I'm not pushing for Gentoo to use /libexec at all, but you'll have
> >> to move the version file in the ebuild as it just won't work when you
> >> pass LIBEXECDIR=/lib/rc to the make targets.
> >
> > if the make system doesnt have a way of controlling the root libexecdir
> > path, sounds like the make system is limited and/or broken and in need of
> > fixing
>
> Eh? I just told you it does. To keep the status quo with /libexec/rc vs
> /lib/rc I provide a make knob. Now you want to move 1 specific file out
> of /lib/rc (because it could be in /lib64 or /lib32 and not in /lib) and
> into /etc because of the /lib brokenness.

the original discussion made it sound like /etc/openrc-version always existed 
independent of libexec
-mike

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

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Roy Marples]

Mike Frysinger wrote:
> the original discussion made it sound like /etc/openrc-version always existed 
> independent of libexec

That is incorrect.

Thanks

Roy

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Robin H. Johnson]

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

On Mon, Jun 08, 2009 at 07:27:02AM -0400, Mike Frysinger wrote:
> > >> Also, should Gentoo (Linux) never break with tradition even if
> > >> somethings are better elsewhere?
> > > no, there is no "innovation" here nor any incentive to do so.  i also
> > > personally dont believe in /usr/libexec/, so i'm not going to randomly be
> > > convinced by /libexec/ in the meantime.
> > The "innovation" here being shell scripts and text files are not 32/64
> > bit dependent and thus don't belong in a directory clearly marked as such.
> ABI is really not the driving force behind libexec vs lib, nor does it really 
> matter here.  openrc isnt a multilib package nor does it need to be.
Even while it isn't a multilib package, there's precedent to move stuff
out of /lib (/usr/lib etc).

One of the reasons to move stuff OUT of /lib are all the profiles where
SYMLINK_LIB is disabled AND LIBDIR_${arch} != "lib". On non-multilib
systems (so there is no lib23/64) or multilib systems where /lib is the
correct location, then any test against /lib/rc/version would be fine.
On anything else, it's not.

Having it in a different location from upstream (OpenRC), means that any
other distributions using OpenRC's /libexec/rc/version location would
need to patch all their init.d scripts.

vapier: I take it by this entire discussion that you aren't going take
the rest of OpenRC's move of scripts to /libexec either?

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

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

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Mike Frysinger]

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

On Monday 08 June 2009 19:23:01 Robin H. Johnson wrote:
> On Mon, Jun 08, 2009 at 07:27:02AM -0400, Mike Frysinger wrote:
> > > >> Also, should Gentoo (Linux) never break with tradition even if
> > > >> somethings are better elsewhere?
> > > >
> > > > no, there is no "innovation" here nor any incentive to do so.  i also
> > > > personally dont believe in /usr/libexec/, so i'm not going to
> > > > randomly be convinced by /libexec/ in the meantime.
> > >
> > > The "innovation" here being shell scripts and text files are not 32/64
> > > bit dependent and thus don't belong in a directory clearly marked as
> > > such.
> >
> > ABI is really not the driving force behind libexec vs lib, nor does it
> > really matter here.  openrc isnt a multilib package nor does it need to
> > be.
>
> Even while it isn't a multilib package, there's precedent to move stuff
> out of /lib (/usr/lib etc).

not really.  the precedent is to move from / to /usr.  we havent really cared 
about anything else (ignoring correctness of moving state files to /var).

> One of the reasons to move stuff OUT of /lib are all the profiles where
> SYMLINK_LIB is disabled AND LIBDIR_${arch} != "lib". On non-multilib
> systems (so there is no lib23/64) or multilib systems where /lib is the
> correct location, then any test against /lib/rc/version would be fine.
> On anything else, it's not.
>
> Having it in a different location from upstream (OpenRC), means that any
> other distributions using OpenRC's /libexec/rc/version location would
> need to patch all their init.d scripts.

the proposed /sbin/functions.sh check would makes this issue moot

> vapier: I take it by this entire discussion that you aren't going take
> the rest of OpenRC's move of scripts to /libexec either?

ive already added that change to the openrc-9999 to keep things in /lib/rc/
-mike

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

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Robin H. Johnson]

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

On Mon, Jun 08, 2009 at 07:42:17PM -0400, Mike Frysinger wrote:
> > One of the reasons to move stuff OUT of /lib are all the profiles where
> > SYMLINK_LIB is disabled AND LIBDIR_${arch} != "lib". On non-multilib
> > systems (so there is no lib23/64) or multilib systems where /lib is the
> > correct location, then any test against /lib/rc/version would be fine.
> > On anything else, it's not.
> >
> > Having it in a different location from upstream (OpenRC), means that any
> > other distributions using OpenRC's /libexec/rc/version location would
> > need to patch all their init.d scripts.
> the proposed /sbin/functions.sh check would makes this issue moot
And why the hell didn't you come forward on bug 270646 with this?

I'm concerned that absence tests like that will not be as useful as
OpenRC spreads. Sure in Gentoo, baselayout1 provides /sbin/functions.sh,
but other users won't.

Since /libexec and /lib are out for the discussed reasons, this leaves
us coming back to /etc/openrc-version, with the same file in
CONFIG_PROTECT_MASK.

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

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

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Mike Frysinger]

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

On Monday 08 June 2009 20:44:35 Robin H. Johnson wrote:
> On Mon, Jun 08, 2009 at 07:42:17PM -0400, Mike Frysinger wrote:
> > > One of the reasons to move stuff OUT of /lib are all the profiles where
> > > SYMLINK_LIB is disabled AND LIBDIR_${arch} != "lib". On non-multilib
> > > systems (so there is no lib23/64) or multilib systems where /lib is the
> > > correct location, then any test against /lib/rc/version would be fine.
> > > On anything else, it's not.
> > >
> > > Having it in a different location from upstream (OpenRC), means that
> > > any other distributions using OpenRC's /libexec/rc/version location
> > > would need to patch all their init.d scripts.
> >
> > the proposed /sbin/functions.sh check would makes this issue moot
>
> And why the hell didn't you come forward on bug 270646 with this?

i'm busy, deal

> I'm concerned that absence tests like that will not be as useful as
> OpenRC spreads. Sure in Gentoo, baselayout1 provides /sbin/functions.sh,
> but other users won't.

i dont see how that is relevant.  we only care about Gentoo here.  plus, the 
test is: if /sbin/functions.sh exists, it's baselayout-1 (which no one else 
outside of Gentoo will be using), otherwise it's openrc.  once we toss 
baselayout-1, there is no test as everything requires openrc.
-mike

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

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Peter Volkov]

В Пнд, 08/06/2009 в 20:54 -0400, Mike Frysinger пишет:
> i dont see how that is relevant.  we only care about Gentoo here.  plus, the 
> test is: if /sbin/functions.sh exists, it's baselayout-1 (which no one else 
> outside of Gentoo will be using), otherwise it's openrc.  once we toss 
> baselayout-1, there is no test as everything requires openrc.

Is there any problem with /etc/openrc-version? Some people already use
other service startup/shutdown systems and there are plans to move this
work to the tree (e.g. runit, that is in tree, but init scripts still
not). So clear check what rc-system is installed will be useful for
cases where we need to modify configuration files automatically.

-- 
Peter.

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Peter Volkov]

On Monday 08 June 2009 10:00:23 Roy Marples wrote: 
> You would have to ask the VServer team, but my understanding was they
> needed to detect version of OpenRC in a container from the host before
> the container is started.

Eh, I lead everybody to astray due to wrong tests results. In reality
openvz does not needs this and probably every configuration that needs
to find out openrc version outside container or chroot can do things
like vzclt (basically chroot() with some magic to execute scripts from
host inside container). I haven't checked vserver scripts but they never
told they have any problems with this.

В Птн, 12/06/2009 в 14:53 +0400, Peter Volkov пишет:
> Is there any problem with /etc/openrc-version?

I don't think this is necessary any more.

-- 
Peter.

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Joe Peterson]

Mike Frysinger wrote:
> maybe, but since we arent going to use /libexec/ at this time, that means /etc 
> is the next best place

How about /usr/share/openrc/version?

Since /usr/share is supposed to contain package-specific (but platform
independent) files that are *not* meant to be modified (unlike /etc), seems
like it might be a good place for it.

						-Joe

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Mike Frysinger]

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

On Monday 08 June 2009 06:39:53 Joe Peterson wrote:
> Mike Frysinger wrote:
> > maybe, but since we arent going to use /libexec/ at this time, that means
> > /etc is the next best place
>
> How about /usr/share/openrc/version?
>
> Since /usr/share is supposed to contain package-specific (but platform
> independent) files that are *not* meant to be modified (unlike /etc), seems
> like it might be a good place for it.

/usr isnt guaranteed to be mounted for all init.d scripts
-mike

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

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Joe Peterson]

Mike Frysinger wrote:
> /usr isnt guaranteed to be mounted for all init.d scripts

Right...  Well, then the best choice is probably /etc out of the list [Roy
pointed out] of the only OS-nonspecific dirs, unless we want to have a small
executable script in /bin or /sbin that spits out the version.

					-Joe

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Roy Marples]

Joe Peterson wrote:
> Mike Frysinger wrote:
>> maybe, but since we arent going to use /libexec/ at this time, that means /etc 
>> is the next best place
> 
> How about /usr/share/openrc/version?

The only dirs that are guaranteed to be available at boot are

/dev
/etc
/lib
/bin
/sbin

Plus these OS specific dirs

/proc (Linux)
/sys (Linux-2.6)
/libexec (the BSD family)

Thanks

Roy

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Mike Frysinger]

i didnt see any real discussion of /sbin/functions.sh ... i dont recall there 
being a reason historically for not checking for this file to detect 
baselayout-1 vs openrc, and no one has complained about its usage in mdadm ...
-mike

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Roy Marples]

Mike Frysinger wrote:
> i didnt see any real discussion of /sbin/functions.sh ... i dont recall there 
> being a reason historically for not checking for this file to detect 
> baselayout-1 vs openrc, and no one has complained about its usage in mdadm ...

That works as a baselayout-1 vs openrc test.
However, there was, or will be, a need to detect OpenRC version as well 
which that doesn't address. I don't know if that is needed right now though.

Thanks

Roy

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Mike Frysinger]

On Monday 08 June 2009 09:01:46 Roy Marples wrote:
> Mike Frysinger wrote:
> > i didnt see any real discussion of /sbin/functions.sh ... i dont recall
> > there being a reason historically for not checking for this file to
> > detect baselayout-1 vs openrc, and no one has complained about its usage
> > in mdadm ...
>
> That works as a baselayout-1 vs openrc test.
> However, there was, or will be, a need to detect OpenRC version as well
> which that doesn't address. I don't know if that is needed right now
> though.

if openrc versions are causing a level of incompatibility, then it should 
itself be setting up an env var for init.d scripts to key off of rather than 
having to figure out what's going on via the filesystem.  the point of this 
thread is to detect baselayout-1 vs openrc only.
-mike

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Roy Marples]

Mike Frysinger wrote:
> if openrc versions are causing a level of incompatibility, then it should 
> itself be setting up an env var for init.d scripts to key off of rather than 
> having to figure out what's going on via the filesystem.  the point of this 
> thread is to detect baselayout-1 vs openrc only.

RC_VERSION is available in 0.5.0
However, for VServer it needs to be easily available without running 
anything, hence this discussion.

Thanks

Roy

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Mike Frysinger]

On Monday 08 June 2009 09:09:43 Roy Marples wrote:
> Mike Frysinger wrote:
> > if openrc versions are causing a level of incompatibility, then it should
> > itself be setting up an env var for init.d scripts to key off of rather
> > than having to figure out what's going on via the filesystem.  the point
> > of this thread is to detect baselayout-1 vs openrc only.
>
> RC_VERSION is available in 0.5.0
> However, for VServer it needs to be easily available without running
> anything, hence this discussion.

if it's in the execution environment of the init.d script,nothing was run
-mike

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Roy Marples]

Mike Frysinger wrote:
> On Monday 08 June 2009 09:09:43 Roy Marples wrote:
>> Mike Frysinger wrote:
>>> if openrc versions are causing a level of incompatibility, then it should
>>> itself be setting up an env var for init.d scripts to key off of rather
>>> than having to figure out what's going on via the filesystem.  the point
>>> of this thread is to detect baselayout-1 vs openrc only.
>> RC_VERSION is available in 0.5.0
>> However, for VServer it needs to be easily available without running
>> anything, hence this discussion.
> 
> if it's in the execution environment of the init.d script,nothing was run
> -mike

You would have to ask the VServer team, but my understanding was they 
needed to detect version of OpenRC in a container from the host before 
the container is started.

Thanks

Roy

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Mike Frysinger]

On Monday 08 June 2009 10:00:23 Roy Marples wrote:
> Mike Frysinger wrote:
> > On Monday 08 June 2009 09:09:43 Roy Marples wrote:
> >> Mike Frysinger wrote:
> >>> if openrc versions are causing a level of incompatibility, then it
> >>> should itself be setting up an env var for init.d scripts to key off of
> >>> rather than having to figure out what's going on via the filesystem. 
> >>> the point of this thread is to detect baselayout-1 vs openrc only.
> >>
> >> RC_VERSION is available in 0.5.0
> >> However, for VServer it needs to be easily available without running
> >> anything, hence this discussion.
> >
> > if it's in the execution environment of the init.d script,nothing was run
>
> You would have to ask the VServer team, but my understanding was they
> needed to detect version of OpenRC in a container from the host before
> the container is started.

if systems need crazy restrictions, these things should be clearly documented 
(preferably in a file in the openrc tree itself).  otherwise we waste time 
talking about stuff none of us have the foggiest clue about.  so until the 
vserver team opts to chime in, i dont think there's anything left here.

the original issue can be handled via sbin/functions.sh (unless someone has a 
reason why not)
-mike

[gentoo-dev] Re: Baselayout2/OpenRC init.d

[Steven J Long]

Mike Frysinger wrote:
> Roy Marples wrote:
>> You would have to ask the VServer team, but my understanding was they
>> needed to detect version of OpenRC in a container from the host before
>> the container is started.
> 
> if systems need crazy restrictions,

It sounded quite simple: no execution of anything; and has clearly been
established as a requirement earlier in the process.

> the original issue can be handled via sbin/functions.sh (unless someone
> has a reason why not)

I can see an advantage to having it in a text file, since it can be checked
at any point in the startup, or before in this case, at the discretion of
the distro or administrator. Where is the advantage in forcing it to be
part of a shellscript?

This is very similar to /etc/gentoo-release, so it's not like it's some
new-fangled "crazy" idea imo.

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

Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Petteri Räty]

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

Robin H. Johnson wrote:
> Hi folks,
> 
> This is a summary of how to detect Baselayout-2/OpenRC from within
> init.d scripts. We raised it in January, without any actual final
> agreement:
> http://archives.gentoo.org/gentoo-dev/msg_5959bcfaf3ba566c551823039643f5c5.xml
> 

How about we don't do runtime detection at all? Let's just use unifdef
in the init scripts with an openrc use flag. When openrc goes stable we
can just drop the conditional code and always pull in openrc. Maybe
makes sense to eclass this stuff so that the code only needs to be
switched in one place. We can also put some QA checks there.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]