[Splashy-devel] lsb functions can't be the best solution

[Tim Dijkstra]

On Fri, 18 Aug 2006 23:58:07 +0200
Vincenzo Ampolo <vincenzo.ampolo at gmail.com> wrote:

> As said in #splashy there are some problems with this idea:
> 1) is it legal to write an /etc/lsb-base-logging.sh?
> 2) is this "way" flexible?
> 
> let me answer to these questions:
> 
> 1) In the debian policy manual at
> http://www.debian.org/doc/debian-policy/ch-relationships.html#s7.5.1
> there is written that "Firstly, as mentioned before, it is usually an
> error for a package to contain files which are on the system in
> another package."
> To be sure i asked to the #ubuntu-motu channel:
> <Goshawk> hi, this is a package creation question about the ubuntu
> policy: is it legal that a package replaces or changes a configuration
> file of another package?
> <crimsun> Ubuntu follows Debian policy, meaning that's illegal.
> <crimsun> what you _can_ do is invoke a conffile manager provided by
> that other package
> I don't know if the lsb-base (usually it
> provides /etc/lsb-base-logging.sh) has a conffile manager and IMHO
> it's not good to change a file of that package, because the version
> provided by splashy can break other services.

First, it is not 'illegal' to supply the same file as another package.
This happens all the time. Policy states 'it's usually an error' and
then goes on several ways in correcting the situation. In our case (on
debian) it's clearly not an error, we provide similar functionality as
usplash, so we can just 'conflict' with them (we do). There's nothing
wrong with that. Policy even says something explicitly about the case of
sharing conffiles (10.7.4):
  Packages which specify the same file as a conffile must be tagged as
  conflicting with each other. (This is an instance of the general rule
  about not sharing files. Note that neither alternatives nor diversions
  are likely to be appropriate in this case; in particular, dpkg does
  not handle diverted conffiles well.)

In ubuntu however, it's a different matter. There the file is part
of lsb-base. We can't conflict with lsb-base, because lots of package
depend on it. That would mean splashy can't be installed with at the
same time with all those packages...

I see several ways out this situation: 
1) Get lsb-base to change the calls to usplash in /etc/l-b-l.sh to
something generic like notify_splash, and both usplash and splash then
start to provide a binary named like that. 
2) Get lsb-base to not supply /etc/l-b-l.sh but put it in usplash, just
like on debian. They should just adapt their version
of /lib/lsb/init-functions to do generic logging stuff and let
[u]splash[y] do the splash stuff.

So recouping: 
* On debain there is no problem at all
* On ubuntu we can solve it with some cooperation of their lsb-base
maintainer.


> 2)IMHO, This "way" to change splashy-init (that seems mandatory due to
> CPU usage and script complexity) because we can do just this:
> when a script runs it calls splashy update.

That's not true of course.

> But how do we recognize which script was run? it seems that, in this
> way, it can be difficult to do that.

This is not difficult at all. It is even how my script works now! In
log_end_msg I use the script name $0 to look up the progress step in
/lib/splashy/S-progress . _So we do know which script ended_ This is
the real strength of this approach. The init scripts themselves call
'US' to tell them they have finished! No hacks at all! 

They can also tell us they've just started because they call
log_start_msg

We can even know they started fsck, because that init script calls 
log_action_begin_msg "Checking file systems", so we can trigger on that
as wel!

> Why do i think that? easy. I'm thinking about animations (do you
> remember? it was for splashy 0.3 when splashy 0.1.5 was released,
> maybe now it's delayed) that in this way they can't work.

No problem.
 
> The idea showed by Otavio is better for me:
> Create a new executable that talks with splashyServer, called
> SplashyClient, that substitutes splashy_pgrep, splashy_update and all
> these "little" programs.

Don't get me wrong, I'm not against a C-program. But I think it would
be best if would be _triggered_ from log_*_msg. 

We just call it there with for example
log_end_msg
	.
	splashy_client end $0 
	.

log_begin_msg
	.
	splashy_client begin $0 $1

Where $0 contains the script name, and in the case of log_begin_msg $1
contains a message that would've been send to console.

Then we have all the info we want. Somebody just needs to supply the
icons;)

grts Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/splashy-devel/attachments/20060819/6feb9b7d/signature.pgp