Damir Perisa schrieb:
Sunday 04 November 2007, Thomas Bächler wrote: | 1) The patch is unintrusive, there is no way it could harm anyone | who has splash disabled.
is the implementation so that initscripts is untouched if the thing is disabled? if it gets enabled by chance (in rc.conf, right?) then will the code check for all needed things before trying to do fancy things? what happens if e.g. kernel framebuffer driver breaks during a kernel update? will the machine still have unbroken initscripts? this are my concerns on your point.
My concerns about breaking and not breaking things were so far only limited to the case where SPLASH is disabled: If SPLASH is disabled, or /sbin/${SPLASH}_wrapper is not found, then the splash_wrapper function does nothing. Thus nothing will change for you. What happens if the framebuffer breaks is completely up to the specific splash implementation, which may of course be buggy. But those bug reports will concern only whoever maintains splashy or gensplash (which I heard already exist as working packages), and these bugs will only affect those who have splash enabled. I guess that the splash_wrapper cannot initialize itself and will ignore all further commands, thus resulting in our "normal" boot screen. Quoting from your other mail:
actually would break a lot of my private scripts when enabled splash, because i am using stat_XX() functions from functions of arch that i use in xterm.
what would happen if you would use the splash_wrapper on a not-framebuffer capable device? i do not know what is actually the /sbin/${SPLASH}_wrapper doing, but will it fall back to the splash_wrapper() { : } behaviour if it detects that it cannot use any framebuffer device?
The splash_wrapper apparently must have a function that initializes it and one that de-initializes it. Thus, if you call a stat_* function after the splash has exited, splash_wrapper ignores the call. Again, it depends on the splash wrapper implementation, which I don't know or maintain.
this is of course a detail and i'm not mentioning it because i use this functions but in general. is there an option on what happens when "/sbin/${SPLASH}_wrapper $@" fails?
Nothing. The splash screen is not initialized/updated/closed.
| 2) Maintaining two sets of initscripts (one with, one without | splash) will result in inconsistencies between the two and in | _more_ bugreports.
the inconsistencies will not happen, if the fork pkg takes initscript pkg as template and just apply the patch, right? but i see thta it is more work to maintain two pkgs.
It will simply duplicate work. And as I will not maintain a separate set of initscripts, someone else will, and there will be a time delay. It is simply a bad thing to replace such an essential part of the system with a "3rd party" replacement.
| 3) We'd make lots of users happy, because they | will use splash anyway, but right now will break their systems in | doing so.
i'm not against having the option to make somebody happy. life is making people happy after all. but it should not be risking to break an essential part just to have an eye-candy. adding niceties is not KISS and also a modification of philosophy of arch. i'm not against it in a strict sense, but i'm for letting it happen with zero compromises.
The patch adds a very KISS way to provide optional splash support. It simply adds a few hooks that can be passed to an external program (not necessarily a splash implenetation), or ignored.
| The ones of you against using this could summarize their arguments | as well. The only thing I remember was "I don't use splash, so I | see no reason to support it in any way", which I don't accept as a | real argument.
not at all here - so let me try a synthesis:
if the coder(s) who are in charge for initscripts decide to take the burden to add this eye-candy to maintain
As is already apparent from what I said before, all I am willing to maintain is the skeleton that others can and will use to provide splash support. The patch moves this task out of initscripts, so we can keep them clean and don't need several versions of essentially the same code. The actual splash implementations must provide a wrapper that acts according to the commands that we pass to them. From what Roman said, such wrappers already exist for splashy and gensplash.
if the code is failsafe in testing for broken elements (fb driver, missing required pkgs, ...) and falling back to "plain behaviour" in case of any problem
Again, the behaviour of the wrapper is up to whomever maintains it. If it is missing or fails, the scripts behave as if splash is disabled.