Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
В Пнд, 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)
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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
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)
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)
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 Description: This is a digitally signed message part.
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
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 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)
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 Description: This is a digitally signed message part.
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
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 Description: This is a digitally signed message part.
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
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)
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 Description: This is a digitally signed message part.
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
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 Description: This is a digitally signed message part.
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
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 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 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)
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)
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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
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)
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)
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)
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)
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)
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)
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)
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
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
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 : robb...@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgpEzF8o08KRQ.pgp
Description: PGP signature
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
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- to keep things in /lib/rc/
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
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 : robb...@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgpoSvl60ZgYe.pgp
Description: PGP signature
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
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
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
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 : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpz97nQpJ7F9.pgp Description: PGP signature
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
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)
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 Description: OpenPGP digital signature
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
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)
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)
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 : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpHwvuhSsHtK.pgp Description: PGP signature
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
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:
=
h1Converting init.d scripts/h1
note
This section is intended primarily for developers, but is also relevant to
anybody with custom init.d scripts.
/note
h2Detecting 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
h2Detecting 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 : robb...@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgpjp0QbsBhMN.pgp
Description: PGP signature
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
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 wrote: [stuff] Thanks, will take a look. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
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 : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpJ6n8z9U82M.pgp Description: PGP signature
