[arch-dev-public] [PATCH] initscripts: Add a splash support

[Thomas Bächler]

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.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://archlinux.org/pipermail/arch-dev-public/attachments/20071104/95d4ad2c/attachment.pgp>