Little change on /lib/lsb/init-functions

[Taco Witte]

Hi,

The benefit of only choosing between "current" and "quiet" mode is that
it's simple and robust.

When using an INIT_FUNC variable, it would be necessary to select which
file to use as a kernel parameter, and this choice would have to be
respected by every single initscript (initscripts invocate the
init_functions file). INIT_QUIET is transparent to initscripts.

Of course, there's another approach: you can make the current
init_functions file a symlink to the file with the desired output. This
would be transparent for initscripts as well, but would not be
configurable on boot. And I think configurability on boot is necessary
because you want to have an "emergency" boot option which displayes
exactly what it's doing. So, in the end you'll want every init_functions
file to have a verbose-mode. (But that doesn't conflict with the idea of
choosing another init_functions file.)

Kind regards,
Taco

Op do, 23-06-2005 te 16:22 +0200, schreef Alberto González:
> I've been looking at both patches and i have thought that instead of
> only making it silent or not, why not make init select the logging
> functions to be used. Instead of INIT_QUIET, make init set "INIT_FUNC"
> with the path of the file that contains the logging functions, one for
> the normal ones, other with silent, and others with whatever you need
> (fbsplash, usplash, a simple text based progressbar...)
> 
> 
> 
> On 6/23/05, Taco Witte <tcwitte at cs.uu.nl> wrote:
> > 
> > Hi,
> > 
> > Did the patch apply well? I made a new patch (against sysvinit original
> > with most recent Ubuntu patches), which can be found in bug 10197. (I
> > can send the new /sbin/init if you want.) To see if the patch for init
> > works, you can add an "export" line in /etc/init.d/rcS and see whether
> > INIT_QUIET is set or not.
> > 
> > Kind regards,
> > Taco
> > 
> > Op vr, 17-06-2005 te 17:36 +0200, schreef Alberto González:
> > > Well, I've been playing a bit with it, and I currently make my ubuntu
> > > boot to say "Hey, you are booting me!" when the system boots, along
> > > with the normal messages. I haven't progressed more because I have a
> > > horrible Turing Machines an AI exam on wednesday and it takes full
> > > time.
> > > 
> > > On 6/17/05, Taco Witte <tcwitte at cs.uu.nl> wrote:
> > > > Op wo, 15-06-2005 te 15:29 +0200, schreef Taco Witte:
> > > > > Karl Hegbloom wrote:
> > > > > On Sun, 2005-06-12 at 23:13 +0200, Alberto González wrote:
> > > > > 
> > > > > > > Those packages could modify init-functions when installed, making
> > it
> > > > > > > point to whatever file they need, as long as it conforms to the
> > > > > > > "interface" of the original file.
> > > > > > 
> > > > > > Are you saying that it should use 'dpkg-divert'? I don't like that
> > > > > > approach very well. It would be better to implement some sort of
> > > > > > overlay or PATH-shadowing system. Overlay would work best, so that
> > the
> > > > > > base functionality of the LSB init-functions could still be
> > accessed
> > > > > > without needing to duplicate it.
> > > > > 
> > > > > I'd propose to hide the output of the initscripts by default instead.
> > > > > This makes things like localization easy because there's nothing to
> > > > > localize (a 'start' message could be replaced by a dot to indicate
> > > > > progress). And I think the user shouldn't be bothered with
> > information
> > > > > he/she doesn't need.
> > > > > See bug #6794 and #10197 for an approach. In this approach, the
> > output
> > > > > of initscripts isn't displayed on boot but only when scripts are used
> > > > > manually (such as on the command line or when installing packages).
> > And
> > > > > this behavior is configurable with the same boot parameters that are
> > > > > used to control the output of the kernel (quiet, splash).
> > > > 
> > > > It seems the discussion has stalled a bit -- does nobody have an
> > > > opinion? The idea to hide the output of initscripts (or display as
> > > > normal) has a working implementation (just look in the bugs).
> > > > 
> > > > Kind regards,
> > > > Taco
> > > > 
> > > > 
> > > > -- 
> > > > ubuntu-devel mailing list
> > > > ubuntu-devel at lists.ubuntu.com
> > > > http://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
> > > > 
> > > 
> > > 
> > 
> > 
> > -- 
> > ubuntu-devel mailing list
> > ubuntu-devel at lists.ubuntu.com
> > http://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
> > 
> 
>