Re: [gentoo-dev] Detecting Baselayout2/openrc - no-symlink profiles leading to breakage
On Sun, Jan 18, 2009 at 12:52 AM, Friedrich Oslage blueb...@gentoo.org wrote: Why not teach /sbin/runscript it's own version? With something like this we could also do stuff depending on a specific version of openrc: That would be a good solution since it'll allow us to check higher versions for new features. Otherwise, it's very likely that we need to solve the same problem again in the near future. Regards, -- Santiago M. Mola Jabber ID: cooldw...@gmail.com
Re: [gentoo-dev] Detecting Baselayout2/openrc - no-symlink profiles leading to breakage
В Вск, 18/01/2009 в 00:52 +0100, Friedrich Oslage пишет:
Robin H. Johnson schrieb:
I'm raising this as an extension of bug 253076, but also because I see
the potential for danger.
As a long term solution, can we just consume an inode and have some file
like /etc/baselayout2?
What package will install this file? Also is it possible to save openrc
${PVR} inside this file? Version is required to introduce workarounds in
reliable way for openrc versions which does not work with openvz startup
scripts. Also why not call this files /etc/*openrc*?
To date, for an init script that has baselayout2-specific behavior, we
have had some variant of [ -e /lib/librc.so ] in the init script.
Why not teach /sbin/runscript it's own version?
In some cases this will break with openvz. openvz container (CT)
start/stop scripts need to check openrc existence inside container and
depending on that generate either openrc or baselayout-1 configuration
files. This start/stop scripts work in host node (HN) environment and
since it's possible to have different versions of everything (e.g. libc)
in HN and CT /sbin/runscript will not work in some cases and thus break
networking and other things for CT.
--
Peter.
signature.asc
Description: Эта часть сообщения подписана цифровой подписью
Re: [gentoo-dev] Detecting Baselayout2/openrc - no-symlink profiles leading to breakage
On 15:07 Sat 17 Jan , Robin H. Johnson wrote: As a long term solution, can we just consume an inode and have some file like /etc/baselayout2? The file must reside on the / partition even when the major trees /usr, /var, /tmp, /opt, /boot, /home, /dev, /root are separate mountpoints. How about using the version in /etc/gentoo-release? comet $ cat /etc/gentoo-release Gentoo Base System release 2.0.0 -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgp0QhD6uOP6N.pgp Description: PGP signature
Re: [gentoo-dev] Detecting Baselayout2/openrc - no-symlink profiles leading to breakage
On Sun, Jan 18, 2009 at 07:11:52PM -0800, Donnie Berkholz wrote: On 15:07 Sat 17 Jan , Robin H. Johnson wrote: As a long term solution, can we just consume an inode and have some file like /etc/baselayout2? The file must reside on the / partition even when the major trees /usr, /var, /tmp, /opt, /boot, /home, /dev, /root are separate mountpoints. How about using the version in /etc/gentoo-release? I should clarify that I want to check simply the existence of a file, rather than parse out a version number or cause a fork to execute. -- 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 pgp1nEZ5NtEki.pgp Description: PGP signature
Re: [gentoo-dev] Detecting Baselayout2/openrc - no-symlink profiles leading to breakage
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robin H. Johnson schrieb:
I'm raising this as an extension of bug 253076, but also because I see
the potential for danger.
To date, for an init script that has baselayout2-specific behavior, we
have had some variant of [ -e /lib/librc.so ] in the init script.
On a multilib profile with no symlinks and a 64-bit userspace, the .so
file would be installed in /lib64/librc.so, and the check would
mistakenly have the wrong result.
There's one fix that has started to turn up already, but I'm not sure if
it's going to be safe always: [ -f /etc/init.d/sysfs ]
This happens to work as openrc installs that init script.
As a long term solution, can we just consume an inode and have some file
like /etc/baselayout2? The file must reside on the / partition even when
the major trees /usr, /var, /tmp, /opt, /boot, /home, /dev, /root are
separate mountpoints.
Using a file in /etc would break if someone would downgrade from
baselayout2/openrc to baselayout1.
Why not teach /sbin/runscript it's own version? With something like this
we could also do stuff depending on a specific version of openrc:
- --- src/rc/runscript.c
+++ src/rc/runscript.c
@@ -1244,6 +1244,7 @@ runscript(int argc, char **argv)
setenv(EINFO_LOG, service, 1);
setenv(RC_SVCNAME, applet, 1);
+ setenv(OPENRC_VERSION, 0.4.2, 1);
/* Set an env var so that we always know our pid regardless of
any
subshells the init script may create so that our mark_service_*
and in the ebuild:
[ -n ${OPENRC_VERSION} ]
Affected and broken profiles:
- amd64's 2005.0/no-symlink (it was very widely deployed. It's not
supported or in the tree anymore, but there ARE still people using it)
- default/linux/sparc/2008.0 (unconfirmed)
That one should be fine. It has a pure 32bit userland, no lib64 or
lib32, just plain lib as libdir.
- Any profile that sets SYMLINK_LIB=no AND the userspace is 64-bit.
- Wouldn't surprise me if some of the N32 style mips stuff was broken
too.
Affected, but not broken profiles:
These are multilib, but with the default as 32-bit causes the lib to be
in right place.
- arch/powerpc/ppc64/32ul
- hardened/linux/powerpc/ppc64/2008.0/32bit-userland
- Any other profile that inherits features/32bit-userland
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAklybyAACgkQknxn9PmJ76VL5QCfXLgKLtrObX2FzbQ3XMHhAqZi
nT8An1zTWYJSmdRs30eLfDIy4LpqslRp
=80mR
-END PGP SIGNATURE-
