So there was a recent change (May 9th) to openrc-4.3.2-r2, that breaks the dmcrypt init script, and lots of others (clvm, evms, multipath-tools, udev, etc), that use the existance of /lib/librc.so to determine whether or not baselayout-2 is in use or not. Unfortunately now, all the librc.* files seem to be moved to /usr/lib (the comment in the changelog says it's so ldscript can install a more minimal set of files). Only /lib/librc.so.1 is installed in /lib, but of course the detection code in most of the init scripts doesn't look for that. As far as I'm aware, the existance of /lib/librc.so is still the recommended way for an init script to detect which baselayout it's being run under (although the most recent versions of mdadm seem to use /sbin/functions.sh as indication that baselayout 1 is installed), but if not then this is a bug for those packages...
ikelos: No, the detection of baselayout2 changed to "if [ -f /etc/init.d/sysfs ]; then" some months ago. I do believe there was a thread on -dev about it.
Ah, fair enough, I missed that, and it looks like so did most of the other consumers, only fms, lvm2 and udev use it (and udev very oddly uses a combination of librc.so and init.d/sysfs for start, but only init.d/sysfs for depend). 5:) However, you've marked this as assigned. Does that mean this change will be reverted, or should I turn this into a tracker and start filing bugs against the various other packages?
Just to add, I'm guessing the discussion you meant was http://archives.gentoo.org/gentoo-dev/msg_5959bcfaf3ba566c551823039643f5c5.xml ? I had a re-read and it didn't appear a consensus was reached, rather it was used in udev. You sounded like you had your concerns that in the future it too might go away (it does feel slightly hackish). The internal version sounded good right up until openvz needed it to work through vms (how do they do it now?), and no one really went back to the idea of a file that proves the existance or otherwise. Perhaps we should either ask Roy to implement a ENV variable in runscript and find a different way for openvz to figure it out (having to open a file, etc) or go for a single (non-config masked) file in /etc?
Roy: Could we get your opinion on this matter? I'm not sure if you saw the thread on -dev about the matter back in January, but it's even more relevant now. All: Having a file in /etc, as pointed out by bluebird, would cause the case of a downgrade back to baselayout1 to falsely trigger the checks as the user would not remove the trigger file, and it's protected by CONFIG_PROTECT. The env var solution might work, but means we can't detect in other shell scripts for example, when rc was not the trigger, or the env was stripped. I'd like to suggest that we symlink /sbin/rc to /sbin/openrc, and then detect the presence of that symlink as a marker that openrc is in use. (/usr, /var, /tmp are all unavailable as they may be on a different partition and not yet mounted).
Init scripts can always test for RC_UNAME if [ -n "$RC_UNAME" ]; then openrc_code else baselayout1_code fi
I've just been burnt by this - can't boot because LVM won't start 'cos it thinks it's baselayout 1, whereupon everything goes pear-shaped and my new X 1.5 setup using udev to handle the keyboard and mouse doesn't. So it's reboot in mode 1, start LVM with "lvchange -ay", and then "rc default". In the unlikely event it's useful, here's my emerge --info Portage 2.2_rc33 (default/linux/x86/2008.0/desktop, gcc-4.1.2, glibc-2.8_p20080602-r1, 2.6.28-vs2.3.0.36.4-gentoolargemem i686) ================================================================= System uname: Linux-2.6.28-vs2.3.0.36.4-gentoolargemem-i686-Genuine_Intel-R-_CPU_T1300_@_1.66GHz-with-glibc2.0 Timestamp of tree: Thu, 21 May 2009 06:45:02 +0000 ccache version 2.4 [enabled] app-shells/bash: 3.2_p39 dev-java/java-config: 1.3.7-r1, 2.1.7 dev-lang/python: 2.5.2-r7 dev-util/ccache: 2.4-r7 dev-util/cmake: 2.6.2-r1 sys-apps/baselayout: 2.0.0 sys-apps/openrc: 0.4.3-r2 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O3 -march=prescott -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O3 -march=prescott -pipe" DISTDIR="/var/tmp/distfiles" FEATURES="ccache distlocks fixpackages parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://ftp.mirrorservice.org/sites/www.ibiblio.org/gentoo/ " LANG="en_GB.utf8" LDFLAGS="-Wl,-O1" LINGUAS="en_GB en_US en" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/ibm-internal /usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X acl acpi alsa berkdb bluetooth branding bzip2 cairo cdr cli cracklib crypt cups dbus dri dvb dvd dvdr dvdread eds emboss encode esd evo fam firefox fortran gdbm gif gpm gstreamer gtk hal iconv ipv6 isdnlog java jpeg kde laptop libnotify mad midi mikmod mmx mp3 mpeg mudflap ncurses nls nptl nptlonly ogg opengl openmp pam pcre pdf perl pmu png ppds pppd python qt3 qt3support qt4 quicktime readline reflection sdl session spell spl sse sse2 ssl startup-notification svg sysfs tcpd tiff truetype unicode usb vorbis win32codecs x86 xml xorg xulrunner xv zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en_GB en_US en" USERLAND="GNU" VIDEO_CARDS="intel" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Since the change was only made to -r2, a rollback to -r1 should solve your problems temporarily. Relying on the existence of a non-specific variable still causes a little concern that it could vanish in the future for some reason, however, none of the other versioning methods we have seem to work well. Perhaps it would be possible to have a file baselayout2-version/openrc-version in /etc but not masked out of the CONFIG_PROTECT (would an env.d file do that?) which could then contain the exact version number? Those that really need to parse it (like openvz) could, those that just want to check for existence can, and if it's not CONFIG_PROTECTED it'll go away when it's unmerged? The symlink idea sounds good, but won't solve the openvz issue of needing an exact version number (if I've understood the problem correctly)? Or should we go with RC_UNAME? Whatever we do, we should try and make a decision quickly and carry out the updates against all the relevant packages in the tree, before this bites more people. I've CCed in the vserver group since they seem to have the most complex requirements on the matter...
(In reply to comment #7) > Since the change was only made to -r2, a rollback to -r1 should solve your > problems temporarily. Relying on the existence of a non-specific variable > still causes a little concern that it could vanish in the future for some > reason, however, none of the other versioning methods we have seem to work > well. case "$(/sbin/rc --version 2>/dev/null)" in "") baselayout1_code;; "0."[123]"."*) old_openrc_code;; *) new_openrc_code;; esac If someone opens a ticket on my bug tracker I could easily export RC_VERSION as well.
more /etc/init.d/dmcrypt ... start() { if [ ! -e /lib/librc.so ]; then eerror "The ${myservice} init script is written for baselayout-2" .... ll /lib64/librc* -rwxr-xr-x 1 root root 43328 21 mag 20:12 /lib64/librc.so.1 link /lib64/librc.so -> /lib64/librc.so.1 is missing (i think)
The problem is the fact that the "Right Way" to detect baselayout-2 has changed multiple times and every init script has not caught up yet.
roy: the original thread I linked requested a way to do it without relying on environment (which can get stripped by su and similar things that try to get a clean environment) or causing a separate exec. All: Ok, so to summarize our needs: - We need a simple/fast (no exec, no environment) way to detect openrc presence. - Detailed way to report the OpenRC version (for OpenVZ) - init scripts need to be POSIX-sh complaint. - Most of /etc is in CONFIG_PROTECT. So how about this: - Version in /etc/openrc-release - CONFIG_PROTECT_MASK+=/etc/openrc-release - openrc's: pkg_postrm() { has_version sys-apps/openrc || rm -f /etc/openrc-release } - Existence check: [[ -f /etc/openrc-release ]] - Version check: read version </etc/openrc-release I tested both of these with strace -ff bash --posix --noediting --noprofile --norc --restricted, and get the correct results without any exec/fork/clone. Does anybody have a problem with these being the official ways of checking for openrc? vserver-devs: anything else you need?
(In reply to comment #11) > roy: > the original thread I linked requested a way to do it without relying on > environment (which can get stripped by su and similar things that try to get a > clean environment) or causing a separate exec. Then they're doing it wrong - /sbin/runscript ensures a clean environment. Besides, the test for OpenRC features should happen in the init script before su or any env cleaning tools get run. > Does anybody have a problem with these being the official ways of checking for > openrc? Well, upstream doesn't supply that way so it's the "Official Gentoo Way".
(In reply to comment #11) > Well, upstream doesn't supply that way so it's the "Official Gentoo Way". Roy, "/sbin/rc --version" does not work with openvz. Openvz scripts which manage configure containers (CT) are run on Host Node (HN) while we need to check openrc existence inside CT. HN can have completely different libc from CT. Thus it's very probable that we'll be unable to run any command from CT at HN. Does there exist any official openrc solution for this?
pva: does my proposed solution in comment #11 work for you?
(In reply to comment #14) > pva: does my proposed solution in comment #11 work for you? Yes with small addition: it's necessary to keep /lib/librc.so file for some time. And this time should be quite long since hoster may have another distribution on HN (actually I even have one such VPS, hoster uses Debian on HN) and thus before we remove that file I need to push changes upstream and then wait for other distributions to backport changes to their packages. So one month is short time. Half a year, or year is better.
(In reply to comment #13) > (In reply to comment #11) > > Well, upstream doesn't supply that way so it's the "Official Gentoo Way". > > Roy, "/sbin/rc --version" does not work with openvz. Openvz scripts which > manage configure containers (CT) are run on Host Node (HN) while we need to > check openrc existence inside CT. HN can have completely different libc from > CT. Thus it's very probable that we'll be unable to run any command from CT at > HN. Does there exist any official openrc solution for this? Interesting problem. As Gentoo loves to move library stuff around it makes things more complex than they ought to be. For the time being, you can test the exitance of /sbin/rc-service for OpenRC support, as that's new. But for the long term version checking without actually running anything AND being able to work with Gentoo's love of providing a lib where it's possible /lib doesn't exist I think I'll need to move the non C library stuff out of /lib/rc and into /libexec/rc (which is where it belongs really anyway). libexec{32,64} will never exist, so this works, and allows /libexec/rc/version to have a version file to be read. I'm very against a version file in /etc, as etc *should* just be system configuration foo. How does that sound?
Ok, so to take Roy's request of no version file in /etc as well: Per my proposal from comment #11, instead of /etc/openrc-release, what if we use Roy's suggested path to have /libexec/rc/openrc-release instead? Anybody else have new constraints to add to the problem definition?
Nope, that all sounds excellent (I love it when a plan comes together). 5:) It would probably be best to have this documented somewhere though, but where? It seems a little miscellaneous, but it could do with being written down *somewhere*. Any ideas where?
http://roy.marples.name/cgi-bin/gitweb.cgi?p=openrc.git;a=commitdiff;h=c0fd1b49e49cec28c1f5a3a76f9db11c62e550dc Move non compiled libraries from /lib/rc to /libexec/rc OpenRC version (+ git ref if built from git) is now stored as plaintext in /libexec/rc/version Plugins (cursplash, splashutils) will have to be re-compiled to pickup the new directories. State data needs to be moved from /lib/rc/init.d to /libexec/rc/init.d as well. If Gentoo does not like this, they can always pass LIBEXECDIR=/lib/rc to the make target so things are as they were.
Roy: Looks good. ikelos: How about in the migration manual as well as the handbook? http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=4#doc_chap4 "4.d. Writing Init Scripts" All: For the existing openrc versions until we deploy the new openrc version to machines, I'm going to create the /libexec/rc/version file in the ebuild. Just not sure off the top of my head how we can get everybody with baselayout2 to upgrade. Maybe we have some evil construct like [[ -f /lib/librc.so -o -f /etc/init.d/sysfs -o -f /libexec/rc/version ]] in all the consumers during the migration period?
Robin: Ok. It's the GDP that handles the handbook isn't it? I've CCed them (although I can file another bug if they'd like) just to add a couple of lines in the baselayout-2 migration guide and the developer handbook (see comment 20 for the exact location) mentioning the new method for detecting baselayout-2/openrc (by using [[ -f /libexec/rc/version ]]). All: I think the biggest issue we'll face is getting everybody to update their consumers. Revision bumping all four openrc versions in the tree (five if you could the live build) shouldn't be too tricky, and then we can rely entirely on /libexec/rc/version for all openrc versions. We can use the fact that they're all ~ARCH to assume that they're updated relatively regularly (presumably no one's going to be sticking to a revision-specific ~ARCH version of a package). As to the consumers, I've no idea how to force them to be upgraded, which means that as soon as openrc goes (well, the latest revision already has gone), initscripts start failing all over the place...
*** Bug 270831 has been marked as a duplicate of this bug. ***
Sorry, it'd probably help if I actually CCed the GDP (please see comment 21).
*** Bug 270762 has been marked as a duplicate of this bug. ***
things that make me wonder: i thought openrc was baselayout-2 my migration to openrc is ~6+ months in the past. -->> why does a certain script only recently start to complain about baselayout when the system already got baselayout-2 for ~6+ mounths? -->> why does said script work for a while and suddenly doesnt? ( http://bugs.gentoo.org/show_bug.cgi?id=270762 )
*** Bug 271541 has been marked as a duplicate of this bug. ***
This stopped my system from booting today too. (dmcrypt still relies on /lib/librc.so.) Why don't we add the link /lib/librc.so -> librc.so.1 (which was removed from rev1 to rev2 of 0.4.3-r2) again?
Roy: Is there going to a be a new release of OpenRC soon, so that vserver can have that file, or should I do a revbump that introduces it on it's own for now?
All: Since there's been no more objections here, here's the final result. 1. OpenRC now provides /libexec/rc/version 2. _EVERY_ init.d script that cares about OpenRC detection should take this route for detecting, right now: [[ -f /lib/librc.so -o -f /etc/init.d/sysfs -o -f /libexec/rc/version ]] 3. 6 months after the stabilization of OpenRC/BL2, the detection will be allowed to change to: [[ -f /libexec/rc/version ]] 4. If you need the exact version of OpenRC, you're going to have to depend on a new enough version and read the /libexec/rc/version (should only affect Vserver team right now). I'll email the -dev mailing list about it.
Robin, can we revert and keep /lib/librc.so file at least for 6 month from now?
(In reply to comment #28) > Roy: > Is there going to a be a new release of OpenRC soon, so that vserver can have > that file, or should I do a revbump that introduces it on it's own for now? OpenRC-0.5.0 was released a few days ago. I let people know in #gentoo-base just before I left for the weekend. This can count as an email to base-system ;)
Peter: If you saw the linked email in archives, it never existed in the first place on some systems. My system (openrc-0.4.3-r2) DOES have it, installed as /lib64/librc.so.1, but that only works because I'm on a profile with /lib/ -> /lib64/. If you have the .so.1 but NOT the .so, then something in the linking might have been broken as well temporarily. That's why it's so important that we fix every init.d script in short order. I'll try to go through the tree this afternoon to look for them.
GDP: I provided the text that you should commit in my posting to the -dev list.
(In reply to comment #32) > That's why it's so important that we fix every init.d script in short order. I'll fix this issue now and push fixes upstream now but the problem here is different: users may have Debian or any other distribution installed at a Host Node, and since Debian is where openrc detection is performed, we need to give Debian maintainers some time to incorporate this fixes. Currently each gentoo specific openvz script has: function is_openrc() { [ -f /lib/librc.so ] } Even simple `touch /lib/librc.so` in openrc ebuild will work and that's what I'm asking for. Please keep this file for half a year or better longer. x86 and amd64 systems I have in containers have this file.
Guys, I was wrong: "/sbin/rc --version" _does_ work with openvz. I'm not sure why it didn't long time ago when I really needed to detect openrc and its version and tested this solution. Now after reading vzctl sources I'm sure it should work. Another configuration I had problems with was my chroots script but now I see that it's possible to do things like vzctl does, so, Roy, probably even /libexec/rc/version was not necessary (Err, sorry, but better late then never, right?). Robbin, but still we need /lib/librc.so back to give upstream/other distributions time to sync openrc detection.
i already bumped openrc to restore the librc.so. this should have been done originally, but you can blame me for that. sounds like we do not need to worry about openvz/vserver at all in general then, thanks.
I am fixing an init script to work with OpenRC, and I would like to know if a final decision has been made on this issue. I do not see any changes to the developer documentation. I have looked over other init scripts, and this bug as well as mailing list archives, but I cannot find a final decision anywhere. If there is a decision, I would like to lend a hand in adding it to the documentation. Even if the decision has two parts: i.e. an intermediate fix ('[ -e /lib/librc.so ]') and a final fix I think it would be very beneficial for everyone involved to have a well documented decision on this issue. Thanks, Trevor
Further discussion was held here: http://thread.gmane.org/gmane.linux.gentoo.devel/61839 With my actual proposal here: http://thread.gmane.org/gmane.linux.gentoo.devel/61839/focus=61846 Since then the following additions were also noted in the thread: - replace [[/]] with [/] - version file available in /lib/rc/version NOT $(get_libdir) - RC_VERSION exists in the env in openrc as of 0.6.0
Thanks for the reply. The suggested doc changes you made look great. Also, I see bug 27318 blocks this, but I suggest it should be the other way around so as to give direction to people closing init script bugs. I mean, if your proposal is final, then there should be different bug for the documentation to be made. Bug 270646 should depend on the doc bug, and 27318 should depend on 270646. Then people would have a clear doc about how to close 273138 and friends. Thoughts? Thanks.
(In reply to comment #39) bug 27318 was supposed to mean bug 273138, sorry.
(In reply to comment #38) > http://thread.gmane.org/gmane.linux.gentoo.devel/61839/focus=61846 > Since then the following additions were also noted in the thread: > - version file available in /lib/rc/version NOT $(get_libdir) On my system operc installs version file into /lib64/rc/version: $ qlist openrc | grep version /lib64/rc/version Should I check for /lib/rc/version in any case?
I was discussing this with WilliamH, and here is the final version for usage in scripts. Add the following block at the top of your script: ===== type is_openrc > /dev/null || \ is_openrc() { [ -f /lib/librc.so -o -f /etc/init.d/sysfs \ -o -f /libexec/rc/version -o -f /lib/rc/version \ -o -f /lib64/rc/version ] return $? } ===== If the function is not available in BL1 or OpenRC, the above will ensure that the check works regardless. Then in your init.d script: if is_openrc ; then ... fi vapier: If you are happy with the check, can you please provide it on BL1 for users to upgrade to (and have it only defined once). Either WilliamH or myself will add it to OpenRC at the same time.
ive we're going to extend the API, we might as well do it scalable. have `rc_version` which outputs the "major" version of things. that way next time we have some major feature shift, we can continue to use that. baselayout-1 will output "1" while openrc will output "2". we can simply increment it down the line.
(In reply to comment #43) > ive we're going to extend the API, we might as well do it scalable. have > `rc_version` which outputs the "major" version of things. that way next time > we have some major feature shift, we can continue to use that. > baselayout-1 will output "1" while openrc will output "2". we can simply > increment it down the line. I think your idea is already in place for the future, because the value of openrc's version is available in @libexecdir@/rc/version. I think it would be confusing to add another version number to the mix. We just need a way to know for sure that we are running under openrc.
I need to make a slight correction: (In reply to comment #44) > (In reply to comment #43) > > ive we're going to extend the API, we might as well do it scalable. have > > `rc_version` which outputs the "major" version of things. that way next time > > we have some major feature shift, we can continue to use that. > > baselayout-1 will output "1" while openrc will output "2". we can simply > > increment it down the line. > I think your idea is already in place for the future, because the value of > openrc's version is available in @libexecdir@/rc/version. I think it would be > confusing to add another version number to the mix. I meant @LIBEXECDIR@/version. It would also be quite easy to write an api function for openrc to expose that if we need to.
if we're talking about making a function that simply sits on top of /lib64/rc/version, then it should be just that rc_version() { cat /lib64/rc/version; } and baselayout-1 can have it echo just "0"
(In reply to comment #46) > if we're talking about making a function that simply sits on top of > /lib64/rc/version, then it should be just that > rc_version() { cat /lib64/rc/version; } > and baselayout-1 can have it echo just "0" Robin, what is your opinion about defining an rc_version function like the above, spinning a new release of both openrc and baselayout-1 and using rc_version as follows to determine if you are running under openrc: if [ "$(rc_version)" = "0" ]; then # baselayout-1 code goes here else # openrc code goes here fi I think this would be a good thing, especially if major changes happen in openrc in the future. The thing I'm concerned about is that it would not work for people who do not upgrade right away to the latest baselayout-1 and openrc where we introduce the function, so if we want to test for openrc for them, we would still have to put an is_openrc function like the one in comment #42 in our init scripts.
(In reply to comment #47) > (In reply to comment #46) > > if we're talking about making a function that simply sits on top of > > /lib64/rc/version, then it should be just that > > rc_version() { cat /lib64/rc/version; } > > and baselayout-1 can have it echo just "0" We do NOT need a function for the version. It already exists in OpenRC as the RC_VERSION variable, but it was only added in 0.6.0 (the version file was added after 0.4.3), so users on older versions cannot use it. The point of the test function and this bug was defining a common way for scripts to detect the presence of OpenRC. 1. We have the compatibility is_openrc version from comment 42, inserted into ebuilds that need to know if OpenRC is in usage. 1.1. In the new versions of BL1, we provide is_openrc() { return 1 } 1.2. In new versions of OpenRC, we provide is_openrc() { return 0 } 1.3. The comment 42 check handles _ALL_ old versions of BL1 + OpenRC where the function is not defined. 2. If you need logic based on a specific version of OpenRC, use the RC_VERSION variable, AFTER checking is_openrc. Define a date for sunset of BL1 support. After that point, we can safely assume is_openrc, and remove all of the is_openrc checks. For the stuff in the is_openrc test, here is where it was introduced: /etc/init.d/sysfs - >=0.3.1, but not available on *BSD OpenRC /{lib,lib64,lib${ABI}/librc.so - >=0.3.0 /libexec/rc/version - 0.4.3 - 0.5 /{lib,lib64,lib${ABI}}/rc/version - >=0.5 $RC_VERSION - >=0.6
2.1: Set your ebuild to RDEPEND on >=openrc-0.6.0, where $RC_VERSION was introduced.
Hi all, this plan makes sense to me. (In reply to comment #48) > 1. We have the compatibility is_openrc version from comment 42, inserted into > ebuilds that need to know if OpenRC is in usage. I think you mean init scripts here. I have an init script for dhcpcd on bug #346805 with this function inserted. It has been tested by one user, and so far, it is working. > 1.1. In the new versions of BL1, we provide is_openrc() { return 1 } Mike, can you put this function in a new version of bl1 so we can get it released and stabilized? > 1.2. In new versions of OpenRC, we provide is_openrc() { return 0 } I have this function in a local branch of openrc, and I will commit it and do a new release as soon as I know that the function mentioned in 1.1 is in baselayout-1 and a new version has been released. > Define a date for sunset of BL1 support. After that point, we can safely assume > is_openrc, and remove all of the is_openrc checks. I'm not sure whether we want to define this yet, but, but I'mthinking we should support bl1 for a certain amount of time after we stabilize bl2/openrc. How long does everyone think is reasonable?
no, i'm not adding "is_openrc" anywhere. it doesnt make any sense and is unscalable cruft. if openrc is already providing RC_VERSION, then baselayout-1 can provide RC_VERSION=0, and init.d scripts can test that. if [ ${RC_VERSION:-0} = 0 ] ; then : baselayout-1 else : openrc fi to avoid issues with older openrc being detected, the package then need only add a blocker to its RDEPEND: !<sys-apps/openrc-0.6.0
Ok, updated stuff to put in devmanual documentation/init.d files, if everybody is happy now: ==== To detect the existence of OpenRC, please only this check: [ "${RC_VERSION:-0}" != "0" ] This replaces all prior checks of librc, sysfs, or a /lib*/rc/version. Additionally, all ebuilds installing files with the new check, MUST add the following: RDEPEND="${RDEPEND} !<sys-apps/openrc-0.6.0" ==== vapier, WilliamH: can I get an explicit ack from both of you on the above block.
that's fine by me. it also has the advantage of not needing a baselayout-1 update, although i'll probably do one anyways to include other things.
We can do this as long as what you said in comment #11 about not relying on the environment is not a concern any longer. If that is true, what about the following test instead though: [ -n "$RC_VERSION" ] We don't really care what the value is as long as it is not empty.
Crap, I'd forgotten that environment wasn't reliable back under some of the virtualization stuff :-(. vapier's rc_version function also violates the no exec requirement from comment #11. vapier: what now?
(In reply to comment #55) > Crap, I'd forgotten that environment wasn't reliable back under some of the > virtualization stuff :-(. > vapier's rc_version function also violates the no exec requirement from comment > #11. > vapier: what now? I just came up with an idea chatting with robin. in openrc: is_openrc() { return 0 } # actually we don't care about the content of the function Then the test could be: if type -f is_openrc > /dev/null; then openrc code else baselayout-1 code fi and we would have to have everyone set rdepend in their ebuilds to block older versions of openrc. Vapier, robbat2: What do you think?
(In reply to comment #56) > (In reply to comment #55) > > Crap, I'd forgotten that environment wasn't reliable back under some of the > > virtualization stuff :-(. > > vapier's rc_version function also violates the no exec requirement from comment > > #11. > > vapier: what now? > I just came up with an idea chatting with robin. > in openrc: > is_openrc() > { return 0 } > # actually we don't care about the content of the function > Then the test could be: > if type -f is_openrc > /dev/null; then openrc code else baselayout-1 code fi > and we would have to have everyone set rdepend in their ebuilds to block older > versions of openrc. > Vapier, robbat2: > What do you think? Let me modify the proposed test. It will work, but -f appears to be a bash extention.
umm, why isnt the env reliable ? sudo/su doing anything to the environment is irrelevant since runscript is executed *after* those have been run, and the RC_* vars are set up by runscript itself. sudo -> runscript -> env setup -> init.d parsing/execution further, if your claim is that "the env is unreliable", then having runscript export any variables at all into the environment would be pointless in the first place. but comment #11 really doesnt provide any details, so who knows.
Under sudo, all of the proposals here work. It's not the problem. Comment #13 covers why (specifically with the OpenVZ interactions the environment and exec aren't what you expect). pva: Is your comment 13 regarding OpenVZ still relevant to the latest OpenRC?
Robin, I'm going to slightly modify an earlier proposal from you: (In reply to comment #52) > Ok, updated stuff to put in devmanual documentation/init.d files, if everybody > is happy now: > ==== > To detect the existence of OpenRC, please only this check: > [ "${RC_VERSION:-0}" != "0" ] [ -f /lib/rc/version -o -f /lib64/rc/version -o -f /libexec/rc/version ] > This replaces all prior checks of librc, sysfs, or a /lib*/rc/version. > Additionally, all ebuilds installing files with the new check, MUST add the > following: > RDEPEND="${RDEPEND} !<sys-apps/openrc-0.6.0" > ==== > vapier, WilliamH: can I get an explicit ack from both of you on the above > block. I think your rdepend requirement and only checking for the version file would work because the version file was introduced in openrc-0.5.0.
Vapier, how do you feel about comment #60 as a way to handle this? I spoke with Robin on irc about this and he is fine with it, so we need your ack to go ahead. The advantage of this method is that the only modifications will be to the individual packages and not to openrc or baselayout-1. William
(In reply to comment #59) > pva: > Is your comment 13 regarding OpenVZ still relevant to the latest OpenRC? No it's not relevant (comment #35). I'm not sure why it failed long time ago, but since the in works. At least should work and last time I've checked I had no issues. Currently we use following function in vzctl scripts: function is_baselayout1() { [ -f /sbin/functions.sh ] }
Robin, with pva's response, we are back to using your proposal in comment #52, which Mike has already approved, so it is fine with me.
I think we can close this now since we only support migration from bl1 to openrc. If anyone disagrees, feel free to reopen.
