Am Samstag, 3. November 2007 schrieb Damir Perisa:

Saturday 03 November 2007, Andreas Radke wrote: | Am Sat, 3 Nov 2007 16:48:05 +0200 | | schrieb "Roman Kyrylych" : | > Hi! | > | > This patch finishes the work done by dtw and iphitus for | > bringing an optional splash support to default initscripts. | > It eliminates the need for separate initscripts-splash package | > which provides/conflicts=('initscripts'). | > | > User has to install splashy or fbsplash which provide required | > mikinitcpio hooks and ${SPLASH}_wrapper script, and then use | > e.g. SPLASH="splashy" in rc.conf to enable it. | | -1 from me | | We are not focussed to be an eyecandy distribution. There's | already a usable solution. I dislike to have another possible | breaker in core.

-1 from me too

why is a separate initscripts-splash pkg a bad thing? for those who want to play with it, let them, but do not make the initscripts more complex as it should be.

- D

-1 from me too, eye candy for having more trouble is not worth for. and also it makes it more complex greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org

I agree. I have never myself been very big on bootsplash screens and such. I actually want to see what is happening when i boot my machine..or i click the power button and go get myself some coffee or tea. yay me! I wouldn't think we need to add complexity to our initscripts just for this. I think documenting how people can do it themselves and providing the companion packages (fbsplash,etc), is the way to go.

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 -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><

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.

On Sun, 4 Nov 2007, Thomas Bächler wrote:

I want to summarize the arguments for adding the patch again and provide you with the patch that I would consider a good idea, if it works for the splash implementations that exist:

1) The patch is unintrusive, there is no way it could harm anyone who has splash disabled. 2) Maintaining two sets of initscripts (one with, one without splash) will result in inconsistencies between the two and in _more_ bugreports. 3) We'd make lots of users happy, because they will use splash anyway, but right now will break their systems in doing so.

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.

This is the link to the diff as it is in the splash branch now: http://projects.archlinux.org/git/?p=initscripts.git;a=commitdiff;h=ad804da1...

+1 for adding a patch for splash support. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

Jason Chu schrieb:

...

User has to install splashy or fbsplash which provide required mikinitcpio hooks and ${SPLASH}_wrapper script, and then use e.g. SPLASH="splashy" in rc.conf to enable it.

+1 from me. We either do the work here (and it doesn't break anything for the users who don't change a thing) or we have to fight with it later in a different package that's nearly exactly the same as initscripts with only a few changes.

I don't like certain details about the patch, but we should create a branch in the initscripts git to finalize it all and then apply it. +1 from here.

James Rayner wrote:

On Sun, November 4, 2007 04:25, Thomas Bächler wrote:

...

Jason Chu schrieb:

...

...

User has to install splashy or fbsplash which provide required mikinitcpio hooks and ${SPLASH}_wrapper script, and then use e.g. SPLASH="splashy" in rc.conf to enable it.

+1 from me. We either do the work here (and it doesn't break anything for the users who don't change a thing) or we have to fight with it later in a different package that's nearly exactly the same as initscripts with only a few changes.

I don't like certain details about the patch, but we should create a branch in the initscripts git to finalize it all and then apply it.

+1 from here.

+1 from me. Last I saw the patch was unintrustive and wasn't complicated at all.

The support is not activated by default, a user still needs to install splashy/fbsplash, etc.

I see no practical reason this patch should not be included. It has no negative side effects, offers more, and is not complicated.

Jamese

_______________________________________________ arch-dev-public mailing list arch-dev-public@archlinux.org http://archlinux.org/mailman/listinfo/arch-dev-public

+1 from me too. I agree with James. I want a nice splash once I know my system is running ok, and I don't want to have to struggle to get it. I remember trying splash from community/Aur once long time ago, and since it borked my system, I never wanted to get back to it. If we provide some kind of official support, I'm assuming a good number of users would be interested. So +1 for NOT activating support by default, but making it easy to get if required. Varun

On Sun, 2007-11-04 at 12:02 +0100, Damir Perisa wrote:

seems we have a polarisation here... some are against it, some are for it.

can you guys who think we should add this patch please tell me the reason why it cannot be a fork-package of initscripts but has to be integrated?

Initscripts is an important package. Making users install an unofficial initscripts package will give us extra bugreports. I've seen it with all those pesky "XDG_DATA_DIRS is not set" bugreports because Alex decided to move xorg.sh from xproto to libx11 while many users didn't use the official libx11, but a libx11-xcb package.

Damir Perisa schrieb:

i mean having an official initscripts-flash. one that would take the initscripts as source, apply the patch and be the one used. provided by a dev who likes flash :)

Maintaining a separate initscripts package (official or unofficial) will result in the scripts being out of sync, and we will get bug reports for already fixed bugs. As mentioned above, the patch is unintrusive and (apart from some small details) fine.

On Sun, 04 Nov 2007 13:16:28 +0100 Thomas Bächler wrote:

I added a splash branch to initscripts and applied the patch. We can merge that once the patch is finalized: http://projects.archlinux.org/git/?p=initscripts.git;a=shortlog;h=splash

Why did you open a branch? That sounds to me, that it is decided that we will include the patch to initscripts. There are several devs, who are against this patch!! And you open just a branch to merge it later with official initscripts. For me, that's like I and the other devs were just ignored with the concerns to this patch!!!

On Sun, 04 Nov 2007 13:37:26 +0100 Thomas Bächler wrote:

So, despite the fact that I am willing to listen to the concerns of others, the final decision lies with me and tpowa.

Then the whole discussion is senseless. It's like we have concerns about it, but you do what you want, because you are maintaining it. You are doing a great job on initscripts, that's clear. But the behaviour isn't ok! Just opening a branch that CAN be merged later despite the concerns of others isn't right. I know, you can delete this branch, if it isn't merged later, but I think we are a team and have discuss and decide several things together. Sorry for my words, if they sounds a little bit aggressive....

On Nov 4, 2007 7:43 AM, Thomas Bächler wrote:

Daniel Isenmann schrieb:

...

Just opening a branch that CAN be merged later despite the concerns of others isn't right. I know, you can delete this branch, if it isn't merged later, but I think we are a team and have discuss and decide several things together.

So, you suggest we should post one patch after the other to the list, making the review a pain in the ass. Adding a branch is just a convenient way to collect the work that has been done and show results to others, so they can actually view what is being suggested (which I assume most of you haven't done).

Daniel- I suggest you read up on GIT before you blow Thomas away with invalid accusations. Branches aren't a big deal in GIT, so calm down. Creating a branch doesn't mean anything is getting done anywhere else. Creating a branch is not a "team" decision at all- that is just retarded and would prevent any progress at all on anything we do. NOT creating a branch would be the stupid thing to do here- people get unmotivated to ever submit patches like this again if they just end up in the black hole of politics and bickering. -Dan

On Sun, 4 Nov 2007 12:48:35 -0800 Jason Chu wrote:

I'm going to jump on this bandwagon for a minute...

I just read your concern and it was "I dislike the idea to make it more complex just for eyecandy". Do you or have you ever maintained initscripts? Have you ever submitted a patch or fixed a bug to do with them? If not, then why does it matter how complex something gets if it just works for what you need it to do?

The people who do maintain it and fix the bugs *do* want the patch. Who are you to say whether it's too complex for them or not? Why not say, "thank you for writing the patch, I'm sure that lots of people will be very happy that things have become easier for them"?

Jason

No, I have never maintain or send bugfixes to initscripts. You are right, it's not my problem, because other must maintain it. In my opinion it isn't worth to add it anyway, because it is just eyecandy. But if Thomas or anybody else getting it done without any side effects for users who don't have activate splash, go on and add splash support in initscripts. Or in your words: "thank you for writing the patch, I'm sure that lots of people will be very happy that things have become easier for them" ;) +1 from me (IF everything is running fine for users without activated splash, because that's the default of booting archlinux (and I hope it will be the default option in the future)). Daniel

Man, there was a lot to read through there. Whew! Let me summarize exactly what's happening here. We have a divide between the "what we have now is good enough" crew, and the "lets try some more experimental features" crew. Both sides have valid points. But, sadly, I need to side with one of them. Having splash support in our initscripts is a good thing. We're not forcing anyone to use a bootsplash. In fact, we're doing just the opposite. We're facilitating it. We're saying "if you want to, go ahead". For those of you who DON'T use bootsplash, I humbly suggest you take a peek at rc.sysinit and look at all the stuff we support an no one uses. There's a lot of it. We support quite a lot of stuff in there because, frankly, there's no better place for it. Now here's the thing. This *could* be modular. We *could* do this in a separate dir of scripts that are executed way in the beginning of rc.sysinit. In fact, we could even get crazy and name that dir "/etc/rc0.d" or something. /me smirks. We maintain a very simplistic init style. This is a good thing. The problem with doing so is here - for some features, we need to put support in our scripts. We can't have the support in external files or directories, or anything like that - that's the kind of initsystem we explicitly DON'T have. So here's my suggestion for the naysayers - rewrite our initscripts to support a SysV init style. Do that and I will gladly maintain a second initscripts package. However, right now all you're doing is fighting against the "curse of Arch" - talking real work to death, and killing motivation. In summary: I'm for it.

Sunday 04 November 2007, Thomas Bächler wrote: | I added a splash branch to initscripts and applied the patch. We | can merge that once the patch is finalized: | http://projects.archlinux.org/git/?p=initscripts.git;a=shortlog;h= |splash http://projects.archlinux.org/git/?p=initscripts.git;a=commitdiff;h=ad804da1... +if [ -n "${SPLASH}" -a -x "/sbin/${SPLASH}_wrapper" ]; then + source /etc/$SPLASH.conf + source /etc/rc.d/$SPLASH-functions + splash_wrapper() { + /sbin/${SPLASH}_wrapper $@ + } +else + splash_wrapper() { + : + } +fi and then using it in stat_fail() stat_done() ... 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? 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? maybe something like: "/sbin/${SPLASH}_wrapper $@ || echo 'splash failed - status: $@'" (this is a wild guess - no idea if it may work; i'm not familiar with all the code, just had a look at some diffs) by the way: thanx for the branch. more convincing if oyu can browse git and have a look in a unproblematic way :) - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><