Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#6989 - Make /etc/rc.d/functions source bootsplash functions (e.g., Splashy)

Attached to Project: Arch Linux
Opened by Darwin Bautista (djclue917) - Tuesday, 24 April 2007, 08:43 GMT
Last edited by Aaron Griffin (phrakture) - Friday, 25 April 2008, 14:46 GMT
Task Type Feature Request
Category System
Status Closed
Assigned To Aaron Griffin (phrakture)
Thomas Bächler (brain0)
Architecture All
Severity Low
Priority Normal
Reported Version 0.8 Voodoo
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No


There has been some discussion going on about Splashy on Arch.

Basically, Splashy currently works by modifying /etc/rc.d/functions to source Splashy-specific and redefined Arch functions located in /etc/splashy/functions. In short, Splashy works through a hack, but a rather clean one.

The only problem in this approach is that Splashy gets broken when the initscripts package is upgraded.

iphitus then suggested that I file a feature request to make it easier for Splashy (and similar userspace bootsplash managers) to integrate with Arch. That being said, I propose that the code below be added to the end of the /etc/rc.d/functions file of the initscripts package:

if [ -n ${BOOTSPLASH} -a -f /etc/${BOOTSPLASH}/functions ]; then
. /etc/${BOOTSPLASH}/functions

And that a new option be added in /etc/rc.conf:


This is of course to allow other bootsplash managers that are similar to Splashy (if there are actually any) to be easily integrated into Arch. If that's not the case however, meaning that Splashy is one of a kind (the only userspace bootsplash manager that is actually usable), then just add the simplified and straightforward version of the code:

if [ -f /etc/splashy/functions ]; then
. /etc/splashy/functions

In the same manner, the option, BOOTSPLASH, wouldn't be anymore required to be added to /etc/rc.conf.
This task depends upon

Closed by  Aaron Griffin (phrakture)
Friday, 25 April 2008, 14:46 GMT
Reason for closing:  Fixed
Additional comments about closing:  Solved by the inclusion of /etc/rc.d/functions.d/* sourcing
Comment by Jan de Groot (JGC) - Tuesday, 24 April 2007, 08:50 GMT
Isn't a /etc/functions.d/ directory more logical? This allows much more extensibility. Files placed in there should be sourced alhpabetically, which means that ideally files should be named,, etc.
Comment by Darwin Bautista (djclue917) - Tuesday, 24 April 2007, 09:07 GMT
Seems like a good idea... I never have thought of that because I only considered Splashy.
Comment by Aaron Griffin (phrakture) - Monday, 26 November 2007, 17:03 GMT
I agree with JGC about the functions.d directory support, it'd open us up to a lot more fun things
Comment by Aaron Griffin (phrakture) - Wednesday, 28 November 2007, 20:51 GMT
How about this?
Comment by Aaron Griffin (phrakture) - Wednesday, 28 November 2007, 21:02 GMT
For the record, that uses the path
This is ugly but I can't think of a better way. /etc/functions.d/ is way to general, especially for functions that we intend only for initscripts

Another option is /etc/rc.functions.d/ which might be cleaner.
Comment by Roman Kyrylych (Romashka) - Wednesday, 05 December 2007, 13:48 GMT
This FR is obsoleted by the splash branch in initscripts.git
Comment by Aaron Griffin (phrakture) - Wednesday, 05 December 2007, 16:52 GMT
Possibly, but it Jan makes a valid assertion about this which is why it's open.

In fact, using a functions.d directory to simply override the message functions obsoletes the splash patch.
Comment by Roman Kyrylych (Romashka) - Thursday, 06 December 2007, 16:40 GMT
Well, not exactly. The splash patch provides more than just an alternative implementation of stat_* functions,
e.g. emit_stat (ex splash_wrapper) boot/init/exit/multi. But probably these could be implemented as empty functions in /etc/rc.d/functions and reimplemented properly in /etc/rc.d/functions.d/{splashy,fbsplash,bootprobe,etc}
Comment by James Rayner (iphitus) - Thursday, 20 December 2007, 10:13 GMT
Kinda agree that rc.d/functions.d is ugly. Apart from 'functions' rc.d contains daemon start/stops, and initially rc.d/functions was primarily just dependent functions for those.

We could just make a general dir for bash functions. I've got tonnes of reusable stuff in netcfg2 that would go there.
Something like /etc/functions.d/, /lib/functions/ and the init stuff could go in a /etc/rc.functions/init/

Slightly bikesheddy, but the distinction is that i'm suggesting a general directory -- I know I'd use it and we could redistribute a tonne of useful scripts/functions.

Comment by Aaron Griffin (phrakture) - Thursday, 20 December 2007, 18:12 GMT
Well, there's a difference here.

scripts should NOT be in /etc - they should go in /usr/{lib,share}/archlinux/ or something.

The only reason these scripts are in /etc is that /etc is the ONLY dir of this magnitude that must be there at boot time when the initscripts run.

So the scripts in etc should ONLY be for initscripts and nothing else.

(Well, white lie: other stuff required at boot time, i.e. start_udev)
Comment by James Rayner (iphitus) - Sunday, 23 December 2007, 09:31 GMT
well then /lib/functions and /usr/lib/functions?
Comment by Aaron Griffin (phrakture) - Sunday, 23 December 2007, 19:48 GMT
It would have to be lib. And 'functions' is very generic. We'd want something like /lib/archlinux/* BUT we still need a way to differentiate which functions are for boot time and which are just generic functions for general use in scripts.

It seems like differentiating this much is just... well, wasting time. Right not a lot of distros keep initscript related things in /etc, so I don't think we have any problem with the current implementation besides the ugly naming of the dir.
Comment by James Rayner (iphitus) - Monday, 24 December 2007, 22:07 GMT
/lib/functions/init or /lib/functions/archlinux for init stuff, other stuff in /lib/functions or /usr/lib/functions?

I'm interested because I'd move netcfg2's internals into that directory too. eg /lib/functions/network

Comment by Aaron Griffin (phrakture) - Saturday, 29 December 2007, 06:28 GMT
Well, we don't want /lib/functions as that's too generic. We'd want /lib/archlinux/ or something of the sort. For netcfg, you'd want /lib/netcfg/ as that's more proper.
Comment by James Rayner (iphitus) - Saturday, 29 December 2007, 12:20 GMT
I meant /lib/functions/archlinux /lib/functions/netcfg, etc

but yeah, *shrug* both work.
Comment by Gavin Bisesi (Daenyth) - Thursday, 17 April 2008, 19:29 GMT
What's the status of this bug? functions.d is now implemented AFAIK. Close?