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

[Damir Perisa]

thank you Thomas for the thesis - here the antithesis of your points 
from my point of view. lets see if we can find a synthesis :)

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.

 | 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. who is the main coder / responsible 
of initscripts at the moment? i want the opinion the person who 
maintains this code if he wants to include the patch or not. 

 | 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 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 

and

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 

and

the eye-candy is per default disabled and easily configurable

then i'm for adding it.

feel free to add any antithesis to my synthesis or finish the 
discussion :)

- D


-- 
.·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´
            °        °           °
             °      °            °
     ><((((º>      °              °
                    °            °
                   °            <º)))><
                  <º)))><