Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

Robin H. Johnson-2
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     : [hidden email]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

attachment0 (338 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Samuli Suominen-4
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

Reply | Threaded
Open this post in threaded view
|

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

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


signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Roy Marples-2
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

Reply | Threaded
Open this post in threaded view
|

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

Ulrich Mueller-2
In reply to this post by Robin H. Johnson-2
>>>>> 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

Reply | Threaded
Open this post in threaded view
|

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

Robin H. Johnson-2
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     : [hidden email]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

attachment0 (338 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Robin H. Johnson-2
In reply to this post by Joshua Saddler
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     : [hidden email]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

attachment0 (338 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Roy Marples-2
In reply to this post by Robin H. Johnson-2
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

Reply | Threaded
Open this post in threaded view
|

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

Joshua Saddler
In reply to this post by Robin H. Johnson-2
Robin H. Johnson wrote:
> [stuff]

Thanks, will take a look.


signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Robin H. Johnson-2
In reply to this post by Roy Marples-2
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     : [hidden email]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

attachment0 (338 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Ulrich Mueller-2
>>>>> 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

Reply | Threaded
Open this post in threaded view
|

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

Mike Frysinger
In reply to this post by Robin H. Johnson-2
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

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Roy Marples-2
In reply to this post by Robin H. Johnson-2
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

Reply | Threaded
Open this post in threaded view
|

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

Roy Marples-2
In reply to this post by Mike Frysinger
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

Reply | Threaded
Open this post in threaded view
|

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

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

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Mike Frysinger
In reply to this post by Roy Marples-2
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

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Roy Marples-2
In reply to this post by Mike Frysinger
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

Reply | Threaded
Open this post in threaded view
|

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

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

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Joe Peterson-3
In reply to this post by Mike Frysinger
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

Reply | Threaded
Open this post in threaded view
|

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

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

signature.asc (853 bytes) Download Attachment
12