Re: [gentoo-dev] New USE_EXPAND flag for www-servers/monkeyd
Am 27.05.2013 22:38, schrieb Anthony G. Basile:
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
Some time ago, Zac proposed a general PLUGIN (or PLUGINS) use-expand,
which could be used for packages with a small amount of plugins to avoid
having a new USE_EXPAND for each and every package. It also has the
advantage, that the resulting useflag 'plugins_foobar' is sane enough
(opposed to 'monkeyd_plugins_foobar'). With this, it serves as a quite
nice compromise for the fraction of USE_EXPAND-dislikers (like me).
Unfortunately this did not get any real discussion. So could this
package be an option to start this? Or do you insist on
monkeyd_{plugins,modules,...}_ ?
Thanks,
René
[gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
Walter Dnes posted on Mon, 27 May 2013 18:40:21 -0400 as excerpted: 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 FWIW I agree with you. In part my post was to make it obvious that's really what we'll end up doing if we want any sort of robustness at all. Otherwise there's simply too much that can go wrong. But assuming people DO insist on traveling that road, there's only one way to do it robustly; thru some sort of single-user-mode by that name or something else. And if it's going to be done, let's quit wasting time on all the too horribly brittle to think about if not simply broken methods that I've seen discussed, and get to it with something that really is proven to work, a single-user-mode of some sort, with scripts to simplify the already simple and potentially break those doing something complex, sure, but if anything's going to work, that'd be it. And if even that can't be made to work or is found not to be worth the hassle, well... -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] New USE_EXPAND flag for www-servers/monkeyd
On 05/28/2013 02:01 AM, Tony Chainsaw Vroon wrote: 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. Thanks. I would have taken silence as consent after one day :) -- 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
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Tue, 28 May 2013 09:56:49 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: In part my post was to make it obvious that's really what we'll end up doing if we want any sort of robustness at all. How much robustness do we really want? http://engineerblogs.org/2011/04/can-a-design-be-too-robust/ Otherwise there's simply too much that can go wrong. You can't have too much go right, that's an unrealistic goal. But assuming people DO insist on traveling that road, there's only one way to do it robustly; thru some sort of single-user-mode by that name or something else. Why reimplement something that exists? Can we reuse single user mode? Why do we need single user mode at all? If you're changing something as important as the init system, one should be prepared to have an system rescue medium available to correct the system if needed; although that is not necessarily needed if you use a wrapper with init=/sbin/einit as you can then just drop that kernel parameter and use the default again. And if it's going to be done, let's quit wasting time on all the too horribly brittle to think about if not simply broken methods that I've seen discussed, A comparison between methods goes further than just calling the other methods broken; this doesn't make me see your method as better, but rather as just another method, perhaps even a broken method. and get to it with something that really is proven to work, a single-user-mode of some sort, with scripts to simplify the already simple and potentially break those doing something complex, sure, but if anything's going to work, that'd be it. And if even that can't be made to work or is found not to be worth the hassle, well... You're making a lot of statements like this but don't back them up. Why would this work best for this situation? What's wrong with the rest? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 28/05/13 12:43 AM, Luca Barbato wrote: OK -- so, given how very simple this wrapper is, and likewise how simple the switcher script would probably be to write, what's the goal of this whole thread, exactly? It doesn't sound like this is something complicated that we'd need to actually provide via an ebuild or integrating patches in other init-system ebuilds anymore... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGkn9QACgkQ2ugaI38ACPDo5gD/aObV6+JWdkb+qK4jR0ukh1p5 M3ITzlLVjayvAV6pixwA/2KdUeXK1xcHESVfXLcD1b7+iE75+SOKsQBZz/9S78lO =4NET -END PGP SIGNATURE-
Re: [gentoo-dev] eselect init
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 28/05/13 12:43 AM, Luca Barbato wrote: 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. OK -- so, given how very simple this wrapper is, and likewise how simple the switcher script would probably be to write, what's the goal of this whole thread, exactly? It doesn't sound like this is something complicated that we'd need to actually provide via an ebuild or integrating patches in other init-system ebuilds anymore... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGkn9kACgkQ2ugaI38ACPD1bwD+IaoJ0yM2nyTt8vhICF+nzhQN CjnLL3yU1LV9qWmwbfUA/jwO4RiTTFKHzoKLn0NHZV2ZqO1y2dbXfzWyuoxz17Lc =oVXb -END PGP SIGNATURE-
[gentoo-dev] Review Board for Gentoo
Hi, I have set up a Review Board instance[1] for testing / evaluation / whatever-you-want purposes. If you are not familiar with what happens in a review, there are a number of established Review Boards to look at.[2] This instance is currently configured for gentoo-x86, as well as a couple of overlays (but it is trivial to add more so let me know if you want your repo added too). While there are a number of options available, I personally like Review Board because it's unobtrusive - it does not disrupt usual workflow because it's only used when wanted. Have a try and see what you think. Best regards, Michael [1]: http://astralcloak.net/~kensington/rb/ [2]: https://git.reviewboard.kde.org/r/110678/
[gentoo-dev] Better handling of USE flags to enable/disable system libraries
I posted a bug about that along with a suggestion, despite sometimes I do not
explain myself correctly (I am very sorry): bug #471590
Many packages are bundling its own libraries rather than link against system
ones, and there is a bug tracker for that (bug #251464)
As I saw in many ebuilds, it is fixed by putting a new system-{$LIBRARY}
IUSE in the affected ebuilds to enable/disable linking with external or
bundled library, but there are plenty of libraries and packages out there to
pullute the use's config files with several combinations of that USE flags.
What I propose here, is to simplify the process a lot by handling those
system-{$LIBRARY} USE flags internally with a very simple configuration for
the user, rather than expose the USE flag directly and forcing user to save
all combinations for that purpose.
This request/idea is inspired on how the x86_ABI is handled:
As a comparison only, most packages have 32 and 64, and you don't have to
handle them via USE flag per-package, rather, you have an option in make.conf
to set it all of them automatically.
What I propose for example, is a very good and simple approach: to have an
option in portage's make.conf, something like that (the name may change):
1.- USE_SYSTEM_LIBRARIES=cairo sqlite XXX
2.- USE_SYSTEM_LIBRARIES=* -cairo
3.- USE_SYSTEM_LIBRARIES=*
Case explanation:
1.- Will trigger automatically (and enable) USE flags: system-cairo, system-
sqlite and system-XXX
2.- Will trigger all system-* related USE except system-cairo which will be
disabled
3.- Will trigger all system-* related USE variables with no exception.
I honestly think, it is a best aproach to resolve the library bundling, along
with a correct fix for affected ebuilds.
What do you think?
Thanks for taking your time to read this suggestion.
David Carlos Manuelda.
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Separate boot/root already [WAS: eselect init]
On 05/28/2013 01:45 AM, Walter Dnes wrote: Out of sheer curiosity... is bb-init based on busybox? If so, a it IS busybox =) 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. You don't need symlinks, you have a startscript that runs busybox ash, then it will use all its applets, init included. This way about all the openrc shell scripts is executed by the same interpreter and sed/grep and such are just function calls and not slightly more pricy fork+exec. Doing this way you get a quite fast boot and depending on your needs you can leverage more busybox applets to replace even more programs (e.g. dhcpcd). That would be the theoretical fastest boot possible short of integrating start-stop-daemon in busybox. lu
Re: [gentoo-dev] New USE_EXPAND flag for www-servers/monkeyd
On Mon, 27 May 2013 16:38:09 -0400 Anthony G. Basile bluen...@gentoo.org wrote: 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? Could you elaborate a bit more on the flags? Please list them, shortly explain and tell us whether you expect the number of plugins to expand and how fast. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Review Board for Gentoo
Hi! Cool! I didnt use RB before, but i use gerrit. Do you pan to integrate it to g.o.g.o? It seems can be done by git commit hooks В письме от 28 мая 2013 23:42:17 пользователь Michael Palimaka написал: Hi, I have set up a Review Board instance[1] for testing / evaluation / whatever-you-want purposes. If you are not familiar with what happens in a review, there are a number of established Review Boards to look at.[2] This instance is currently configured for gentoo-x86, as well as a couple of overlays (but it is trivial to add more so let me know if you want your repo added too). While there are a number of options available, I personally like Review Board because it's unobtrusive - it does not disrupt usual workflow because it's only used when wanted. Have a try and see what you think. Best regards, Michael [1]: http://astralcloak.net/~kensington/rb/ [2]: https://git.reviewboard.kde.org/r/110678/ -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Better handling of USE flags to enable/disable system libraries
On Tue, 28 May 2013 16:43:10 +0200 David Carlos Manuelda stormb...@gmail.com wrote: I posted a bug about that along with a suggestion, despite sometimes I do not explain myself correctly (I am very sorry): bug #471590 Many packages are bundling its own libraries rather than link against system ones, and there is a bug tracker for that (bug #251464) [...] What I propose for example, is a very good and simple approach: to have an option in portage's make.conf, something like that (the name may change): 1.- USE_SYSTEM_LIBRARIES=cairo sqlite XXX 2.- USE_SYSTEM_LIBRARIES=* -cairo 3.- USE_SYSTEM_LIBRARIES=* I don't think we should do it like this. Bundling libraries is a pathological case. In general, we should work on fixing this and getting rid of bundled libraries. In that general case, the flags are not required. The remaining cases usually involve libraries that are somehow forked or otherwise deviated from upstream. For example, the sqlite within Mozilla products has a few braindead features enabled that are not really suitable for system-wide use. In those cases, every library needs to be considered separately and the concept of local flag matches that. Making it anyhow a global matter would suggest that each bundled sqlite is equal and each reason for bundling is exact the same. That said, I don't see why a user would want to choose to have some libraries bundled, and others not in a global manner. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Better handling of USE flags to enable/disable system libraries
On Tuesday 28 May 2013 13:53:54 Michał Górny wrote: On Tue, 28 May 2013 16:43:10 +0200 David Carlos Manuelda wrote: I posted a bug about that along with a suggestion, despite sometimes I do not explain myself correctly (I am very sorry): bug #471590 Many packages are bundling its own libraries rather than link against system ones, and there is a bug tracker for that (bug #251464) [...] What I propose for example, is a very good and simple approach: to have an option in portage's make.conf, something like that (the name may change): 1.- USE_SYSTEM_LIBRARIES=cairo sqlite XXX 2.- USE_SYSTEM_LIBRARIES=* -cairo 3.- USE_SYSTEM_LIBRARIES=* I don't think we should do it like this. Bundling libraries is a pathological case. In general, we should work on fixing this and getting rid of bundled libraries. In that general case, the flags are not required. +1 -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] New USE_EXPAND flag for www-servers/monkeyd
On 05/28/2013 11:35 AM, Michał Górny wrote: On Mon, 27 May 2013 16:38:09 -0400 Anthony G. Basile bluen...@gentoo.org wrote: 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? Could you elaborate a bit more on the flags? Please list them, shortly explain and tell us whether you expect the number of plugins to expand and how fast. Sorry I already committed this with Chainsaw's ack. Anyhow, they are: auth - Provide HTTP Basic Authentication cheetah - Provide a shell-like command line interface #cgi - Provide the traditional CGI interface dirlisting - Show an HTML listing of the content of a directory #fastcgi - Provide FastCGI proxy support liana - Build your own network layer through monkeyd logger - Log requests and common errors mandril - Restrict incoming connections based on the IP address or URI request polarssl - Provide HTTPS using PolarSSL v1.*. The ones that are commented out are global flags and so I did not make them part of the USE_EXPAND, they are still treated as plugins by monkeyd and I have them commented out in monkeyd_plugins.desc with an explanation. Upstream has an entire plugin system which they use extensively and expect contributors to use plugins. There have always been a couple of changes with each bump, eg between 1.1.1 and 1.2.0 regarding ssl. So I expect the same in the future. -- 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
Re: [gentoo-dev] New USE_EXPAND flag for www-servers/monkeyd
On Tue, 28 May 2013 14:57:03 -0400 Anthony G. Basile bluen...@gentoo.org wrote: On 05/28/2013 11:35 AM, Michał Górny wrote: On Mon, 27 May 2013 16:38:09 -0400 Anthony G. Basile bluen...@gentoo.org wrote: 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? Could you elaborate a bit more on the flags? Please list them, shortly explain and tell us whether you expect the number of plugins to expand and how fast. Sorry I already committed this with Chainsaw's ack. Anyhow, they are: auth - Provide HTTP Basic Authentication cheetah - Provide a shell-like command line interface #cgi - Provide the traditional CGI interface dirlisting - Show an HTML listing of the content of a directory #fastcgi - Provide FastCGI proxy support liana - Build your own network layer through monkeyd logger - Log requests and common errors mandril - Restrict incoming connections based on the IP address or URI request polarssl - Provide HTTPS using PolarSSL v1.*. Shouldn't this one be tied to USE=ssl? For the others, how large is the benefit of having them switchable? At least some of them look like something that wouldn't hurt people if it was always-built. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] New USE_EXPAND flag for www-servers/monkeyd
On 05/28/2013 03:07 PM, Michał Górny wrote: On Tue, 28 May 2013 14:57:03 -0400 Anthony G. Basile bluen...@gentoo.org wrote: On 05/28/2013 11:35 AM, Michał Górny wrote: On Mon, 27 May 2013 16:38:09 -0400 Anthony G. Basile bluen...@gentoo.org wrote: 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? Could you elaborate a bit more on the flags? Please list them, shortly explain and tell us whether you expect the number of plugins to expand and how fast. Sorry I already committed this with Chainsaw's ack. Anyhow, they are: auth - Provide HTTP Basic Authentication cheetah - Provide a shell-like command line interface #cgi - Provide the traditional CGI interface dirlisting - Show an HTML listing of the content of a directory #fastcgi - Provide FastCGI proxy support liana - Build your own network layer through monkeyd logger - Log requests and common errors mandril - Restrict incoming connections based on the IP address or URI request polarssl - Provide HTTPS using PolarSSL v1.*. Shouldn't this one be tied to USE=ssl? For the others, how large is the benefit of having them switchable? At least some of them look like something that wouldn't hurt people if it was always-built. I thought about ssl but I'm still not sure if USE=ssl means just openssl or any ssl. Eg, with curl, which has a choice of one of six backend ssl providers, I changed USE=ssl to mean that one and only one of the six must be on. Previously though, USE=ssl in curl meant only openssl which was confusing because you could also have USE=nss or gnutls etc provide your ssl. monkey also bounced around its ssl backend from liana_ssl to polarssl which is what made me think of curl. What if in the future there's yet another ssl backend? Although use.desc does say ... ssl - Adds support for Secure Socket Layer connections. Any advice here? monkeyd is intended for embedded systems which is why it has switchable plugins. You can even choose whether or not to install the shared lib and include files to really slim it down. -- 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
Re: [gentoo-dev] New USE_EXPAND flag for www-servers/monkeyd
On Tue, 28 May 2013 15:22:04 -0400 Anthony G. Basile bluen...@gentoo.org wrote: I thought about ssl but I'm still not sure if USE=ssl means just openssl or any ssl. Eg, with curl, which has a choice of one of six backend ssl providers, I changed USE=ssl to mean that one and only one of the six must be on. Previously though, USE=ssl in curl meant only openssl which was confusing because you could also have USE=nss or gnutls etc provide your ssl. monkey also bounced around its ssl backend from liana_ssl to polarssl which is what made me think of curl. What if in the future there's yet another ssl backend? Although use.desc does say ... ssl - Adds support for Secure Socket Layer connections. Any advice here? Any SSL. If there are multiple backends to support, there are specific flags which affect the choice but USE=ssl means any SSL is suitable. monkeyd is intended for embedded systems which is why it has switchable plugins. You can even choose whether or not to install the shared lib and include files to really slim it down. I can understand using USE flags to trim down plugins (assuming they're large). But shared-lib is an overkill. If people want this degree of scalability, it's either INSTALL_MASK or USE=minimal. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] New USE_EXPAND flag for www-servers/monkeyd
On Tue, May 28, 2013 at 09:07:37PM +0200, Michał Górny wrote: For the others, how large is the benefit of having them switchable? At least some of them look like something that wouldn't hurt people if it was always-built. The dev manual states that use flags are to control optional dependencies and _settings_ which a user may reasonably want to select [1]. Since the developer gives us the ability to control this with configure switches, I feel pretty strongly that we should give the user that control. William [1] http://devmanual.gentoo.org/general-concepts/use-flags/index.html signature.asc Description: Digital signature
Re: [gentoo-dev] Better handling of USE flags to enable/disable system libraries
El Martes, 28 de mayo de 2013 14:03:52 Mike Frysinger escribió: On Tuesday 28 May 2013 13:53:54 Michał Górny wrote: On Tue, 28 May 2013 16:43:10 +0200 David Carlos Manuelda wrote: I posted a bug about that along with a suggestion, despite sometimes I do not explain myself correctly (I am very sorry): bug #471590 Many packages are bundling its own libraries rather than link against system ones, and there is a bug tracker for that (bug #251464) [...] What I propose for example, is a very good and simple approach: to have an option in portage's make.conf, something like that (the name may change): 1.- USE_SYSTEM_LIBRARIES=cairo sqlite XXX 2.- USE_SYSTEM_LIBRARIES=* -cairo 3.- USE_SYSTEM_LIBRARIES=* I don't think we should do it like this. Bundling libraries is a pathological case. In general, we should work on fixing this and getting rid of bundled libraries. In that general case, the flags are not required. +1 -mike Ok, thinking it better I agree, that having them use system libraries is far better, but why then those affected ebuilds have corresponding USE disabled by default? signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Better handling of USE flags to enable/disable system libraries
On Tue, May 28, 2013 at 7:01 PM, David Carlos Manuelda stormb...@gmail.com wrote: Ok, thinking it better I agree, that having them use system libraries is far better, but why then those affected ebuilds have corresponding USE disabled by default? Probably because the use of those system libraries is experimental. If they worked reliably most likely the maintainer would have stripped the bundled library completely and not made it optional. Rich
[gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
Tom Wijsman posted on Tue, 28 May 2013 13:56:19 +0200 as excerpted: You're making a lot of statements like this but don't back them up. Why would this work best for this situation? What's wrong with the rest? While as long as it stays out of my way enough so I don't have to worry about it, I don't particularly care (to the point I debated simply not replying), your post did make me aware of the fact that I was claiming negatives on the other methods without backing up the claims... because from here they were evident, and others had made them well enough I didn't need to. However, I guess if I claim something I owe it to my readers to be prepared to back it up, so... As I've read the thread, there seem to be four issues with most of the other methods discussed, three related, one separate. 1) Changing an initsystem with the system up and running in normal state risks not being able to shut down properly. While some init-systems may either not have that problem or be able to work around it in a trivial way, getting something robust enough to work reliably across all of them, in all sorts of weird site configurations, will be... challenging, to say the least. 2) Doing it at shutdown has problems of its own, including the incomplete switch crash scenario as well as having to do it late enough in the process that the operational-switch issues of #1 aren't triggered. The two problems above lead to the idea of not actually doing the change on a running system, but rather, simply using a trigger mechanism to trigger it at next boot. I didn't see it specifically stated what that would be, but at least here I envisioned it as comparable to the .fsck (whatever it's named) file dropped in root to trigger an fsck at the next boot, only in this case it would trigger the init-system switch. 3) Except... any switch has to occur VERY early in the boot process, before the existing init-system has already gotten us into the operational-switch situation of #1 that we were trying to avoid. Effectively, our switcher must be called as init either by the kernel itself or by the initr*, where it can do its thing before calling the normal init-system it might have just switched to. 3b) Except... at that point root isn't writable, and a robust solution to get it writable in ordered to actually make the switch permanent, that works on all the strange root-on-whatever systems out there, AND works with at least systemd and openrc and bb-init (with extensibility to others), AND inserts extremely minimal delay and code into the routine no changes, just boot the same way you did last time case, AND doesn't take control away from the individual init-system package maintainers, AND doesn't impose a huge burden on individual init-system package maintainers, AND fills ALL these requirements suitably robustly that it works well to say at least two-nines reliability... No wonder someone mentioned that it looked like a case for an initr*... but on gentoo anyway, requiring that has at least political problems of its own. It's beginning to look rather like a Sisyphean task... Which it might actually be. But it occurred to me that we actually do have a demonstrated workable and long used in actual practice exception to the normal boot case as precedent, where such maintenance tasks traditionally occur, single user mode. Then I began thinking how that fit the requirements and use case as outlined, including the (semi-?)automated bit. Which is how I came to post the idea of the sub-thread starter. Not to rehash everything I wrote there, but it seems to me to have the best chance at doing what is otherwise looking to be a Sisyphean task. With the extremely minimal two-case-only code inserted between kernel/initr* and the selected init-system at boot, it fills the quick and simple normal-case boot requirement. All the rest of the code is out of the way. The rest of the code then runs as a semi-automated single-user-mode equivalent. And having even that minimal normal-boot-mode insert under control of a USE flag allows people to get even that out of the way if they're not interested. Meanwhile, it's worth pointing out explicitly that by choosing this insertion point, root must already be at least mounted and accessible in read-only mode, whether by kernel command-line, initr*, or whatever, or the direct init invocation we're replacing wouldn't work. Thus, the whole issue of possibly initr* userspace or kernel commandline getting exotic root-on-whatever even mountable in the first place, is already taken care of, yet real-init hasn't yet executed, so we don't have to worry about messing with an already functioning init-system, thus leaving it no way to climb down. 4) Finally, the fact that each init-system package gets to control its own switcher-mode script keeps control of it with the init-system package maintainers, allowing them to choose as complex or simple a
