[gentoo-dev] Switchup-mode and boottime selector? Was: eselect init
Ian Stakenvicius posted on Sun, 26 May 2013 10:58:24 -0400 as excerpted: On 26/05/13 07:40 AM, Luca Barbato wrote: On 5/26/13 12:57 PM, Michał Górny wrote: You are telling me that a wrapper, a thing that gets executed *every* boot needs to do some random magic to know which init system was in use and which one is supposed to be in use, and then conditionally move around configuration files necessary for it to run. This is just *INSANE*. I like to think it normal and the wrapper doesn't need to run every time but only when a switch had been requested. And only if you prefer doing the switch at boot time instead than at shutdown. The way it's being proposed (and please correct me if i'm wrong), the wrapper is a direct replacement binary (small C program) for all init systems, and would based on some configuration file or whatnot determine and exec the init system it's supposed to -- and make any other necessary changes too, such as switching /etc/inittab) I don't know (outside of a script in the initramfs) how this would otherwise be handled to cover all cases. I am curious though, if you see a way to do this otherwise, what the implementation would look like? Here's an idea I've not seen proposed yet. Make the wrapper function something like a cross between a simple bootloader and traditional single-user-mode. Normal mode, like the bootloader for many users, would be a default choice with (configurable) either a timeout of a couple seconds, or (say shift) key-held-down detection, thus no boot delay as if the key isn't down at the moment of detection, boot proceeds using the existing config. In the event of an init switchup, the user either sets an option before shutdown (much like the run-once defaults of grub, etc, set pre- shutdown), or selects switchup mode with the appropriate boot-time trigger (using the above mentioned timeout or key-down sensing). The special switchup mode would then operate much like single-user in terms of available functionality and the fact that it's a special mode used for system maintenance, but would (normally, with a drop-to-shell option as well) be rather more guided, presumably using a menu, again much like a bootloader, except that it's PID-1 instead of pre-kernel. Critical point #1 is that much like single-user mode, switchup mode would NOT run normally, but would be specifically selected, with either a reboot or simply starting the new init system at switchup mode exit. That gives switchup mode a lot more flexibility in terms of what's allowed, since it's no longer in the time-critical every-boot path, and because it's its own mode, it can mount / rw to make changes as necessary, with either a reboot to start the selected init-system or simply starting it normally, at switchup mode exit. And if anything goes wrong, simply select switchup mode at the next boot once again, and either revert to previous, for fix it. Critical point #2 is that the actual normal-mode wrapper would be very small both in terms of boot-time and code, thus both easy to debug, and not increasing boot time by much at all, particularly in key-down- detection mode where there'd be no timeout delay to tick down. A small binary that simply either runs the timout or detects key-down, before execing the normal init, is all that would run in a normal bootup. The complex functionality would only be invoked if switchup mode is chosen, as entirely separate functionality execed place of the normal init it would have otherwise execed. Meanwhile, switchup mode (again, a separate binary execed only if chosen from the tiny one designed to run inline at each boot) would have a menu with options to invoke scripts for each of the init-system choices offered, and a further fall-back to shell option. Each init-system package would then depend (perhaps conditionally based on an init-switcher USE flag) on the init-switcher package, and would ship one gentoo specific file, the switcher script, thus putting each switcher script under the control of the gentoo maintainers for that init- system package, who could set it up to be as simple or as complex as necessary for their init system. Those who needed a rw root to switch out various files could arrange for their switcher script to handle that, while those who could do without, possibly handling things later with their own native init-service, could do without the rw root bit. Similarly, switchup mode exit-time behavior, presumably either simply triggering a reboot, or starting the selected init-system directly, would be entirely under the control of the individual init-system package maintainers, via the switch-script they maintain. As a first bonus, even people who aren't interested in more than one init- system might find setting the init-switcher USE flag useful, especially on EFI systems, since it would give them the advantages of switchup mode, namely a drop to shell option as yet
Re: [gentoo-dev] Re: robo-stable bugs
On Thu, 23 May 2013 23:40:42 -0600 Ryan Hill dirtye...@gentoo.org wrote: Okay, so what are you using the STABLEREQ keyword for that you want to set it when the bug is filed but before archs are added? If you want to see only stabilization bugs you can search in the Keywording and Stabilization component. Can you suggest another way to search for stabilization bugs that don't yet have archs CC'd (which is something I find rather useful)? We could split up [Keywording and Stabilization] into separate components, [Keywording] and [Stabilization], but then 1) people would still forget to set it, at whatever stage, and 2) this wouldn't fit with [Security]/[Vulnerabilities]. It's important to be able to distinguish between STABLEREQ and KEYWORDREQ. I think a KEYWORDREQ should normally be handled earlier than any STABLEREQ /unless/ the STABLEREQ fixes a security bug, since being late getting keywords back up to par with other architectures tends to make an even bigger mess further on. Alternatively, we could set CONFIRMED or IN_PROGRESS when a) the Component is [Keywording and Stabilization] and b) arch teams are CC'd, but then everyone would forget to set that half the time, too. jer
[gentoo-dev] New global USE flag: qt5
Hi all, Qt 5 has been available for some time, and we are making preparations to move it to the tree. As we will be supporting user choice where packages can be build against both Qt 4 and Qt 5, we will require a new global USE flag: qt5 - Adds support for the Qt 5 application and UI framework Please note that this flag will be immediately masked until Qt 5 actually makes it to the tree, but is required to do the necessary pre-work. Best regards, Michael
[gentoo-dev] Re: New global USE flag: qt5
On 27/05/13 18:06, Michael Palimaka wrote: Hi all, Qt 5 has been available for some time, and we are making preparations to move it to the tree. As we will be supporting user choice where packages can be build against both Qt 4 and Qt 5, we will require a new global USE flag: qt5 - Adds support for the Qt 5 application and UI framework Please note that this flag will be immediately masked until Qt 5 actually makes it to the tree, but is required to do the necessary pre-work. I suppose there will be an eqmake5 that should be called instead of eqmake4 when that USE flag is set?
[gentoo-dev] PSA: python-r1.eclass, python-single-r1.eclass, and REQUIRED_USE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
A quick reminder for anyone using python-r1.eclass or
python-single-r1.eclass:
These eclasses provide a ${PYTHON_REQUIRED_USE} variable that should
be included in REQUIRED_USE under the same USE conditionals (if any)
that ${PYTHON_DEPS} is included in DEPEND/RDEPEND.
For example, if your ebuild has:
RDEPEND=
python? ( ${PYTHON_DEPS}
then you should also have:
REQUIRED_USE=
python? ( ${PYTHON_REQUIRED_USE} )
And if your ebuild just has:
RDEPEND=${PYTHON_DEPS}
then you should also have:
REQUIRED_USE=${PYTHON_REQUIRED_USE}
Failure to include these in REQUIRED_USE may cause the eclass to die
very late in the build process.
Thank you,
Jonathan Callen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCgAGBQJRo309AAoJELHSF2kinlg4dVcP/2t3v1t8CId8jK/c4VG8HLWL
zTEvTI3d8wQILuHydI9VkOZllo3dPWhhUhg/1qJjwEXXnKQXiYNUiVzbtwdkGro/
OlkCrrpDstHgawHiovIZjgyEG9Y+Nz2Z5nKorZIAMFSFepaFsIkihVR3VkeHiG9Q
7XOOVaH8mqGuj7JWZNqikCmB11a6t08jVM68tzwtTZUuil1IRE2qjO5akMPczsvk
3ndoMsv5hQwUE4wmmTH4ffiz+wp/JUylK2Ypy6p/UWlMw+oq8IusyvQdKztF2rU4
SyjnEOHcPtbLXMA24NHSAUov5L3xVcSu4he5A+QnY0Ghn0dZ7Wbk72aRZQP+MOk+
e18tdPRaXE35ux8s0ogLeuD04lju6z5/esJbP8LF8H6loiKCURxVOfYEhUugIMIc
ihb6h4o4cflz2tYV6USOHxUQ6pA78X7ftXGJhOOR1sf1/2GZcg7ZQvD0WqjNLbAo
U52yQl3/bKMVpezYLhkLxgzmRAdwbBdBFdiav8dX+QNYabLPG/0y6mkqK0pc59sS
Lsse/dXCPrxfI6MVbsSQAaFt4s/YNrf9NLabdPHShRlWX8pRc16feQFb7FoTCmWe
BzwBwG63Mvw2OOS0GrXIfXdFs9klbezoZ8Ql8Zb3CIZPWaBPAOYfCqZDHkDDAyQL
UYQyPJdIntHmxKbtMQr9
=frSU
-END PGP SIGNATURE-
[gentoo-dev] Re: New global USE flag: qt5
On 28/05/2013 01:34, Nikos Chantziaras wrote: On 27/05/13 18:06, Michael Palimaka wrote: Hi all, Qt 5 has been available for some time, and we are making preparations to move it to the tree. As we will be supporting user choice where packages can be build against both Qt 4 and Qt 5, we will require a new global USE flag: qt5 - Adds support for the Qt 5 application and UI framework Please note that this flag will be immediately masked until Qt 5 actually makes it to the tree, but is required to do the necessary pre-work. I suppose there will be an eqmake5 that should be called instead of eqmake4 when that USE flag is set? Yes, this will part of the future qt5 eclass for packages that require qmake.
Re: [gentoo-dev] PSA: python-r1.eclass, python-single-r1.eclass, and REQUIRED_USE
On Mon, May 27, 2013 at 11:35 AM, Jonathan Callen a...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
A quick reminder for anyone using python-r1.eclass or
python-single-r1.eclass:
These eclasses provide a ${PYTHON_REQUIRED_USE} variable that should
be included in REQUIRED_USE under the same USE conditionals (if any)
that ${PYTHON_DEPS} is included in DEPEND/RDEPEND.
Thanks for that. I probably should have announced it myself.
Re: [gentoo-dev] PSA: python-r1.eclass, python-single-r1.eclass, and REQUIRED_USE
Is there actually list of current offenders? It would be pretty nice to have bugs opened if someone forgot to set it. Tom
[gentoo-dev] Re: [gentoo-dev-announce] PSA: python-r1.eclass, python-single-r1.eclass, and REQUIRED_USE
El lun, 27-05-2013 a las 11:35 -0400, Jonathan Callen escribió:
A quick reminder for anyone using python-r1.eclass or
python-single-r1.eclass:
These eclasses provide a ${PYTHON_REQUIRED_USE} variable that should
be included in REQUIRED_USE under the same USE conditionals (if any)
that ${PYTHON_DEPS} is included in DEPEND/RDEPEND.
For example, if your ebuild has:
RDEPEND=
python? ( ${PYTHON_DEPS}
then you should also have:
REQUIRED_USE=
python? ( ${PYTHON_REQUIRED_USE} )
And if your ebuild just has:
RDEPEND=${PYTHON_DEPS}
then you should also have:
REQUIRED_USE=${PYTHON_REQUIRED_USE}
Failure to include these in REQUIRED_USE may cause the eclass to die
very late in the build process.
Thank you,
Jonathan Callen
Couldn't a repoman check be added for warning when an ebuild using that
eclasses don't set REQUIRED_USE at all?
Re: [gentoo-dev] Switchup-mode and boottime selector? Was: eselect init
Funny. This is starting to sound familiar... almost like some other software that runs at boot, every boot. Hm, what was the name... Oh, a *bootloader*! Something that *loads* different *boot* configurations! But seriously. For people that can install a bootloader, is there really any reconfiguration needed to reboot into a different init system? Just add configuration items as needed for different init systems. We've never automatically added bootloader options if sys-kernel/* is updated; why start now? For those who are on EFI with direct load of Linux, either install a bootloader or use efibootmgr or similar to add entries into the native boot selector (really another bootloader). signature.asc Description: OpenPGP digital signature
[gentoo-dev] New USE_EXPAND flag for www-servers/monkeyd
Hi everyone, I was about to add a use expand flag for monkeyd (a tiny web server) and there is a notice in base/make.default to discuss use expand flags on the list first. There are about 9 plugins for monkeyd similar to apache which can be turned on/off by a configure switch. It makes sense to follow the same logic as apache here. There are no dependencies on monkeyd and so no use-deps. Seems very safe. Any objections? --Tony -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
[gentoo-dev] Re: PSA: python-r1.eclass, python-single-r1.eclass, and REQUIRED_USE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/27/2013 01:24 PM, Tomáš Chvátal wrote: Is there actually list of current offenders? It would be pretty nice to have bugs opened if someone forgot to set it. Tom While there may be some false positives in this list, below is a list of the ebuilds that inherit python-r1 or python-single-r1 that do not include anything referencing python_targets_* in REQUIRED_USE: app-accessibility/accerciser-3.6.2-r1 app-accessibility/accerciser-3.8.0 app-accessibility/accerciser-3.8.2 app-accessibility/caribou-0.4.10 app-accessibility/caribou-0.4.7 app-accessibility/caribou-0.4.8 app-accessibility/orca-3.6.3-r1 app-accessibility/orca-3.8.1 app-accessibility/pocketsphinx-0.8 app-accessibility/speech-dispatcher-0.7.1-r2 app-accessibility/speech-dispatcher-0.8-r1 app-accessibility/speech-dispatcher-0.8-r2 app-accessibility/sphinxbase-0.8 app-accessibility/SphinxTrain-1.0.8 app-arch/rpm-4.11.0.1 app-benchmarks/bootchart2-0.14.5-r1 app-cdr/cdemu-2.0.0 app-cdr/gcdemu-2.0.0 app-editors/gedit-3.6.2-r1 app-editors/gedit-3.8.1 app-editors/gedit-3.8.2 app-editors/gedit-plugins-3.6.1-r1 app-editors/gedit-plugins-3.8.1 app-editors/gedit-plugins-3.8.2 app-editors/gvim-7.3.905 app-editors/gvim-7.3.931 app-editors/gvim- app-editors/vim-7.3.905 app-editors/vim-7.3.931 app-editors/vim- app-emulation/crossover-bin-12.1.2 app-emulation/crossover-bin-12.2.0 app-emulation/libvirt-glib-0.1.5 app-emulation/libvirt-glib-0.1.6 app-emulation/xen-4.2.0-r1 app-emulation/xen-4.2.0-r2 app-emulation/xen-4.2.1-r1 app-emulation/xen-4.2.1-r2 app-emulation/xen-4.2.1-r3 app-emulation/xen-4.2.2 app-emulation/xen-tools-4.2.0-r3 app-emulation/xen-tools-4.2.1 app-emulation/xen-tools-4.2.1-r1 app-emulation/xen-tools-4.2.1-r2 app-emulation/xen-tools-4.2.1-r3 app-emulation/xen-tools-4.2.2-r1 app-i18n/ibus-1.5.2 app-i18n/ibus-anthy-1.5.0 app-i18n/mozc-1.10.1390.102 app-misc/byobu-5.39 app-misc/byobu-5.41 app-misc/byobu-5.41-r1 app-misc/evemu-1.1.0 app-misc/golly-2.4-r1 app-misc/grc-1.4-r1 app-misc/metromap-0.1.4-r1 app-misc/terminal-colors-1.5 app-misc/workrave-1.10 app-office/gnucash-2.4.12 app-office/gnumeric-1.12.0-r1 app-office/gnumeric-1.12.1 app-office/gnumeric-1.12.2 app-office/libreoffice-3.6.6.2 app-office/libreoffice-3.6. app-office/libreoffice-4.0.3.3 app-office/libreoffice-4.0. app-office/libreoffice-4.1. app-office/libreoffice--r2 app-office/planner-0.14.6_p20130520 app-office/scribus-1.4.2-r2 app-office/scribus-1.4. app-pda/libimobiledevice-1.1.5 app-pda/libplist-1.10 app-shells/autojump-21.3.0-r1 app-shells/autojump-21.5.8 app-text/asciidoc-8.6.8-r1 app-text/asciidoc- app-text/gnome-doc-utils-0.20.10-r1 app-text/gtranslator-2.91.6 app-text/pastebinit-1.3.1-r1 app-vim/splice-1.0.1 app-vim/vim-latex-1.8.23.20130116 dev-db/postgresql-server-8.4.17 dev-db/postgresql-server-9.0.13 dev-db/postgresql-server-9.1.9 dev-db/postgresql-server-9.2.4 dev-db/postgresql-server- dev-java/antlr-2.7.7-r1 dev-java/antlr-2.7.7-r3 dev-java/antlr-2.7.7-r4 dev-java/antlr-2.7.7-r5 dev-lang/yasm-1.2.0-r1 dev-lang/yasm- dev-libs/boost-1.52.0-r6 dev-libs/boost-1.53.0 dev-libs/botan-1.10.3-r1 dev-libs/btparser-0.24 dev-libs/cryptlib-3.4.0-r1 dev-libs/dee-1.0.14-r2 dev-libs/glib-2.36.1 dev-libs/glib-2.36.2 dev-libs/gobject-introspection-1.34.2-r1 dev-libs/gobject-introspection-1.36.0 dev-libs/libpeas-1.6.2-r1 dev-libs/libpeas-1.8.0 dev-libs/libpwquality-1.2.0-r2 dev-libs/libRocket-1.2.1 dev-libs/libRocket-1.2.1_p20130110 dev-libs/libRocket-1.2.1_p20130110-r1 dev-libs/libRocket- dev-libs/libxml2-2.8.0-r4 dev-libs/libxml2-2.9.0-r1 dev-libs/libxml2-2.9.0-r2 dev-libs/libxslt-1.1.28-r1 dev-libs/newt-0.52.15 dev-python/compizconfig-python-0.8.4-r5 dev-python/docutils-glep-0.4-r1 dev-python/graph-tool-2.2.21 dev-python/graph-tool-2.2.22 dev-python/graph-tool-2.2.23 dev-python/graph-tool- dev-python/gst-python-0.10.22-r1 dev-python/notify-python-0.1.1-r3 dev-python/psycopg-1.1.21-r1 dev-python/pyatspi-2.6.0-r1 dev-python/pyatspi-2.8.0 dev-python/pycairo-1.10.0-r4 dev-python/pygobject-2.28.6-r53 dev-python/pygobject-3.2.2-r1 dev-python/pygobject-3.4.2-r1 dev-python/pygobject-3.8.1 dev-python/pygobject-3.8.2 dev-python/pygoocanvas-0.14.1-r1 dev-python/pygtk-2.24.0-r3 dev-python/pygtksourceview-2.10.1-r1 dev-python/PyQt4-4.10 dev-python/PyQt4-4.10.1 dev-python/PyQt4-4.9.6-r2 dev-python/pyqwt-5.2.0-r1 dev-python/pyside-1.1.2-r1 dev-python/python-exec-0.2 dev-python/python-exec-0.3 dev-python/python-exec-0.3.1 dev-python/python-exec- dev-python/python-poppler-0.12.1-r4 dev-python/qscintilla-python-2.7.1 dev-python/shiboken-1.1.2-r1 dev-python/sip-4.14.3 dev-python/sip-4.14.6 dev-python/subunit-0.0.10-r1 dev-python/telepathy-python-0.15.19-r1 dev-util/anjuta-3.6.2-r1 dev-util/anjuta-3.8.1 dev-util/anjuta-3.8.3 dev-util/catfish-0.6.3 dev-util/coccinelle-1.0.0_rc17 dev-util/devhelp-3.6.1-r1 dev-util/devhelp-3.8.1 dev-util/devhelp-3.8.2 dev-util/dwarves-1.10-r1 dev-util/fatrace-0.5
Re: [gentoo-dev] Switchup-mode and boottime selector? Was: eselect init
On Mon, May 27, 2013 at 10:36:41AM +, Duncan wrote Here's an idea I've not seen proposed yet. Make the wrapper function something like a cross between a simple bootloader and traditional single-user-mode. Normal mode, like the bootloader for many users, would be a default choice with (configurable) either a timeout of a couple seconds, or (say shift) key-held-down detection, thus no boot delay as if the key isn't down at the moment of detection, boot proceeds using the existing config. In the event of an init switchup, the user either sets an option before shutdown (much like the run-once defaults of grub, etc, set pre- shutdown), or selects switchup mode with the appropriate boot-time trigger (using the above mentioned timeout or key-down sensing). That is still adding unnecessary complexity to the systems, and an additional possible point of failure. The special switchup mode would then operate much like single-user in terms of available functionality and the fact that it's a special mode used for system maintenance, but would (normally, with a drop-to-shell option as well) be rather more guided, presumably using a menu, again much like a bootloader, except that it's PID-1 instead of pre-kernel. What does this accomplish that could not be accomplished by... * placing a switcher script in /sbin * booting to single-user mode, and running the switcher script Critical point #1 is that much like single-user mode, switchup mode would NOT run normally, but would be specifically selected, with either a reboot or simply starting the new init system at switchup mode exit. It waddles like single-user mode It quacks like single-user mode It flies like single-user mode It *IS* single-user mode Why bother re-inventing the wheel. Use single-user mode, already. Critical point #2 is that the actual normal-mode wrapper would be very small both in terms of boot-time and code, thus both easy to debug, and not increasing boot time by much at all, particularly in key-down- detection mode where there'd be no timeout delay to tick down. A small binary that simply either runs the timout or detects key-down, before execing the normal init, is all that would run in a normal bootup. The complex functionality would only be invoked if switchup mode is chosen, as entirely separate functionality execed place of the normal init it would have otherwise execed. Meanwhile, switchup mode (again, a separate binary execed only if chosen from the tiny one designed to run inline at each boot) would have a menu with options to invoke scripts for each of the init-system choices offered, and a further fall-back to shell option. Each init-system package would then depend (perhaps conditionally based on an init-switcher USE flag) on the init-switcher package, and would ship one gentoo specific file, the switcher script, thus putting each switcher script under the control of the gentoo maintainers for that init- system package, who could set it up to be as simple or as complex as necessary for their init system. Those who needed a rw root to switch out various files could arrange for their switcher script to handle that, while those who could do without, possibly handling things later with their own native init-service, could do without the rw root bit. Similarly, switchup mode exit-time behavior, presumably either simply triggering a reboot, or starting the selected init-system directly, would be entirely under the control of the individual init-system package maintainers, via the switch-script they maintain. I repeat, all this can be handled in single-user mode right now. As a first bonus, even people who aren't interested in more than one init- system might find setting the init-switcher USE flag useful, especially on EFI systems, since it would give them the advantages of switchup mode, namely a drop to shell option as yet another alternative to single user mode, Oh boy... a second single-user mode. AND perhaps even MORE importantly, access to a more or less automated init-system restore option, triggered via selection of the same switcher script that would otherwise be run to switch between init- systems. Again, the contents of that init-system-specific switcher- script would be entirely under the control of the gentoo maintainers for that package, so they could do whatever fancy working-condition checks and restores from backup that they wanted. What you're talking about is rescue-CD functionality. I don't know if it's possible, but it would be very nice as a standalone rescue CD (actually USB stick nowadays). If so, I would much rather prefer it on as rescue CD/USB-stick than as a boot option. If a system is really screwed up, you can't even assume that it'll boot to single-mode from the hard drive. As a second bonus, switchup mode would be extremely flexible and extensible via
[gentoo-dev] Separate boot/root already [WAS: eselect init]
On Mon, May 27, 2013 at 01:47:49AM +0200, Luca Barbato wrote Yes, I tested it first and got the whole system unworkable, one single mode later I baked something to get at least the minimal functionality, supporting our xdm script properly required some more effort I hadn't time to pour that day. People who want to try something different in distros, without irrevocably switching over, normally have a separate partition. This is beginning to look like the simplest, least error-prone approach, even if it is heavy-ganded. Out of sheer curiosity... is bb-init based on busybox? If so, a separate partition would also prevent standard utilities from stomping all over their busybox symlink equivalants. Add another entry to the grub/lilo menu, and boot from that. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] eselect init
On 5/26/13 4:58 PM, Ian Stakenvicius wrote:
The way it's being proposed (and please correct me if i'm wrong), the
wrapper is a direct replacement binary (small C program) for all init
systems, and would based on some configuration file or whatnot
determine and exec the init system it's supposed to -- and make any
other necessary changes too, such as switching /etc/inittab)
The really minimal wrapper would be something like
#!/bin/sh
INIT=/bin/init
if [[ -e /etc/switch-init ]]; then
. /etc/switch-init
fi
exec ${INIT}
With switch-init doing stuff needed, including remounting the rootfs rw
if there are stuff to be changed and if we want stick to symlinks it
could replace itself by a symlink.
Yes, it would be that simple.
lu
Re: [gentoo-dev] eselect init
On Tue, 28 May 2013 05:55:39 +0200
Luca Barbato lu_z...@gentoo.org wrote:
On 5/26/13 4:58 PM, Ian Stakenvicius wrote:
The way it's being proposed (and please correct me if i'm wrong), the
wrapper is a direct replacement binary (small C program) for all init
systems, and would based on some configuration file or whatnot
determine and exec the init system it's supposed to -- and make any
other necessary changes too, such as switching /etc/inittab)
The really minimal wrapper would be something like
#!/bin/sh
INIT=/bin/init
if [[ -e /etc/switch-init ]]; then
. /etc/switch-init
fi
exec ${INIT}
With switch-init doing stuff needed, including remounting the rootfs rw
if there are stuff to be changed and if we want stick to symlinks it
could replace itself by a symlink.
Yes, it would be that simple.
And you actually make the boot depend on:
1) valid /bin/sh,
2) valid /etc/switch-init which would not interfere with boot process.
With switch-init being executed as a shell script, it can do anything.
And I wouldn't be surprised if you made it do various things you'd like
to be done. Not to mention what would happen if it gets corrupted into
binary mess and shell tries to execute that.
There's no fallback that could handle shell failures, you know.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] eselect init
On 5/28/13 6:19 AM, Michał Górny wrote: And you actually make the boot depend on: 1) valid /bin/sh If it doesn't exist you have a few order of magnitude bigger problem. 2) valid /etc/switch-init which would not interfere with boot process. I guess if you want to switch init system you need that =) With switch-init being executed as a shell script, it can do anything. Yes and that's the beauty of it. And I wouldn't be surprised if you made it do various things you'd like to be done. I would be surprised if I'd make it do various things I won't like to be done, surely a possibility, albeit unlikely. Not to mention what would happen if it gets corrupted into binary mess and shell tries to execute that. Having your rootfs corrupted is quite bad, even horrible if an ephemeral file gets corrupted through reboot. There's no fallback that could handle shell failures, you know. I guess your knowledge of shell needs to be expanded, beside that it is easier to write an example using shell pseudocode to explain how it could work. That said, here a friendly suggestion: try to be less destructive in your comments and fix your mailer. Both can be annoying in the long run. lu
Re: [gentoo-dev] New USE_EXPAND flag for www-servers/monkeyd
On Mon, 2013-05-27 at 16:38 -0400, Anthony G. Basile wrote: There are about 9 plugins for monkeyd similar to apache which can be turned on/off by a configure switch. It makes sense to follow the same logic as apache here. Indeed it does. Particularly if it avoids a non-obvious USE-flag that requires an explanation in metadata.xml, like the problem I had with VOICEMAIL_STORAGE in net-misc/asterisk. It took me 3 days to get a reply to that, so I'm replying even though I'm agreeing with you. Then again, perhaps I just want to see something else on this list then bickering... Regards, Tony V.
