BTS

Issue290

Title lsb-functions specification?
Priority package Status resolved
Superseder Nosy List ft, mika
Assigned To ft Topics grml-etc-core

Created on 2007-09-16.10:10:49 by ft, last changed 2007-09-16.12:44:18 by ft.

Messages
msg808 (view) Author: ft Date: 2007-09-16.12:44:18
Okay, all questions covered. Closing this one therefore.
 -ft
msg807 (view) Author: mika Date: 2007-09-16.12:38:56
* Frank Terbeck <ft@bewatermyfriend.org> [20070916 14:37]:
> Michael Prokop <mika@grml.org>:
> > * Frank Terbeck <ft@bewatermyfriend.org> [20070916 14:24]:
> > > lsb-funtions sets a default $PATH.
> > > Is anything depending on that to happen or is script-function's
> > > setpath() used?

> > No, nothing of both is used currently IIRC. :)

> I'll remove it from lsb-functions, then.
> Then the e*() stuff needs to be reworked (still uses non-POSIX stuff).
> I'll probably move the stuff from gentoo's functions.sh to
> script-functions once that done. (unless you tell me not to.)

Great, just go for it. :)

regards,
-mika-
msg806 (view) Author: ft1 Date: 2007-09-16.12:36:52
Michael Prokop <mika@grml.org>:
> * Frank Terbeck <ft@bewatermyfriend.org> [20070916 14:24]:
> > lsb-funtions sets a default $PATH.
> > Is anything depending on that to happen or is script-function's
> > setpath() used?
> 
> No, nothing of both is used currently IIRC. :)

I'll remove it from lsb-functions, then.
Then the e*() stuff needs to be reworked (still uses non-POSIX stuff).
I'll probably move the stuff from gentoo's functions.sh to
script-functions once that done. (unless you tell me not to.)

Regards, Frank
msg805 (view) Author: mika Date: 2007-09-16.12:29:52
* Frank Terbeck <ft@bewatermyfriend.org> [20070916 14:24]:
> Michael Prokop <mika@grml.org>:

[...]
> > let's drop it

> [x] done.

Great.

> I removed add_suffix() as well. We don't use it, I don't see its point
> and now that get_bootconfig() is gone, it's pointless anyway.

ACK

> lsb-funtions sets a default $PATH.
> Is anything depending on that to happen or is script-function's
> setpath() used?

No, nothing of both is used currently IIRC. :)

regards,
-mika-
msg804 (view) Author: ft1 Date: 2007-09-16.12:23:56
Michael Prokop <mika@grml.org>:
> * Frank Terbeck <ft@bewatermyfriend.org> [20070916 13:33]:
> > Michael Prokop <mika@grml.org>:
> > > * Frank Terbeck <ft@grml.org> [20070916 12:47]:
> 
> > > We have such functions also in /etc/grml/script-functions and
> > > /etc/grml/sh-lib. I'd like to merge as much as possible. I
> 
> > > > > > get_bootconfig
> Ok, then lets drop it and we write our own implementation for
> script-functions
> 
> > > > > > get_bootparam
> same here
> 
> > > > > > is_older_than
> Hm, lets move it to script-functions?
> 
> > > > > > reverse_list
> candidate for script-functions as well
> 
> > > > > > get_mount_fstab
> let's drop it

[x] done.

I removed add_suffix() as well. We don't use it, I don't see its point
and now that get_bootconfig() is gone, it's pointless anyway.

lsb-funtions sets a default $PATH.
Is anything depending on that to happen or is script-function's
setpath() used?

Regards, Frank
msg803 (view) Author: mika Date: 2007-09-16.12:01:09
* Frank Terbeck <ft@bewatermyfriend.org> [20070916 13:33]:
> Michael Prokop <mika@grml.org>:
> > * Frank Terbeck <ft@grml.org> [20070916 12:47]:

> > We have such functions also in /etc/grml/script-functions and
> > /etc/grml/sh-lib. I'd like to merge as much as possible. I

> Are you talking about these: (?)

Jupp

> > > > > get_bootconfig
>             ^- I don't think this works in (d)ash as it is.
>                The required change would be simple, though.
>                I *think*

Ok, then lets drop it and we write our own implementation for
script-functions

> > > > > get_bootparam
>             ^- This one required 'gawk'; G(!)awk

same here

> > > > > is_older_than
>             ^- pure sh, AFAICS; works recursively, too.
>                Handy for time-stamping. Don't know if we need it.
>                The implementation looks fairly clean.

Hm, lets move it to script-functions?

> > > > > reverse_list
>             ^- Pure sh. I rewrote this one to make it work with
>                (d)ash.

candidate for script-functions as well

> > > > > get_mount_fstab
>             ^- This requires 'awk'

let's drop it

> > appreciate any feedback. :) [Though I'm not yet sure how to create a
> > new "API" without breaking anything, maybe we should clean up

> Yeah, a test-suite would be handy. :)
> Maybe, now that you got grml-live, it would be possible to create
> experimental ISOs. That way, we could "just do it", and see what
> happens.

Sure, that's my long term goal. :)

> > lsb-functions as far as possible (without breaking any scripts) and
> > provide all the useful functions for scripts (interactive as well as
> > init-style scripts) in a new file (could be even
> > /etc/grml/script-functions as I'm the only one really using it
> > AFAICS).

> Well, I think it would be a good idea to keep the functions that are
> *really* required by LSB in lsb-functions. Everything else (namely the
> e*() functions) can savely go to another file, like
> 'script-functions', if you like.

ACK

> My grep expression also missed these:
>     log_success_msg()       [used]
>     log_failure_msg()       [used]
>     log_warning_msg()       [used]
>     log_warning_msg_nn()
>     log_begin_msg()         [used]
>     log_begin_msg_nn()      [used]
>     log_end_msg()           [used]

> At least log_success_msg(), log_failure_msg(), log_warning_msg() are
> required by lsb. So, we should keep all of them.

ACK

> Removed functions I snipped from this posting, as requested.

Great

regards,
-mika-
msg802 (view) Author: ft1 Date: 2007-09-16.11:33:25
Michael Prokop <mika@grml.org>:
> * Frank Terbeck <ft@grml.org> [20070916 12:47]:
> > Michael Prokop <mika@grml.org>:
> > > * ft <bts@bts.grml.org> [20070916 12:10]:
> > > > add_suffix
> > > > ebegin
> > > > eend                    [required]
> > > > eerror                  [required]
> > > > eindent                 [required]
> > > > einfo                   [required]
> > > > einfon                  [required]
> > > > eoutdent                [required]
> > > > esetdent
> > > > esyslog                 [required]
> > > > ewarn                   [required]
> > > > ewend

> > These just do 'return 0'. Unless you think they are needed I'll remove
> > them:
> 
> We have such functions also in /etc/grml/script-functions and
> /etc/grml/sh-lib. I'd like to merge as much as possible. I

            ^- I don't think this works in (d)ash as it is.
               The required change would be simple, though.
               I *think*

            ^- This one required 'gawk'; G(!)awk

            ^- pure sh, AFAICS; works recursively, too.
               Handy for time-stamping. Don't know if we need it.
               The implementation looks fairly clean.

            ^- Pure sh. I rewrote this one to make it work with
               (d)ash.

            ^- This requires 'awk'

> appreciate any feedback. :) [Though I'm not yet sure how to create a
> new "API" without breaking anything, maybe we should clean up

Yeah, a test-suite would be handy. :)
Maybe, now that you got grml-live, it would be possible to create
experimental ISOs. That way, we could "just do it", and see what
happens.

> lsb-functions as far as possible (without breaking any scripts) and
> provide all the useful functions for scripts (interactive as well as
> init-style scripts) in a new file (could be even
> /etc/grml/script-functions as I'm the only one really using it
> AFAICS).

Well, I think it would be a good idea to keep the functions that are
*really* required by LSB in lsb-functions. Everything else (namely the
e*() functions) can savely go to another file, like
'script-functions', if you like.

My grep expression also missed these:
    log_success_msg()       [used]
    log_failure_msg()       [used]
    log_warning_msg()       [used]
    log_warning_msg_nn()
    log_begin_msg()         [used]
    log_begin_msg_nn()      [used]
    log_end_msg()           [used]

At least log_success_msg(), log_failure_msg(), log_warning_msg() are
required by lsb. So, we should keep all of them.

Removed functions I snipped from this posting, as requested.

Regards, Frank
msg801 (view) Author: mika Date: 2007-09-16.10:59:39
* Frank Terbeck <ft@grml.org> [20070916 12:47]:
> Michael Prokop <mika@grml.org>:
> > * ft <bts@bts.grml.org> [20070916 12:10]:
> > > 'lsb-functions' implements these functions:

> > > _eend                   [internal]
> > > have_tput               [internal]

> I added have_tput() myself. I think I'll rename it to _have_tput() to
> show it is for internal use only.

Great.

> > > add_suffix

> I really want to get rid of dolisting():
> > > dolisting

Feel free :)

> > > ebegin
> > > eend                    [required]
> > > eerror                  [required]
> > > eindent                 [required]
> > > einfo                   [required]
> > > einfon                  [required]
> > > eoutdent                [required]
> > > esetdent
> > > esyslog                 [required]
> > > ewarn                   [required]
> > > ewend

> I'll check which of the other e*() functions are required by others. I
> suspect, they're all needed.

Ok

> I'm completely indifferent about these. No idea if they'd ever be
> useful:
> > > is_net_fs

-> currently we don't need it, if you ever need such a function we
know where we can take it from again ;)

> > > is_uml_sys

-> we don't support UML and never will, so let's drop it

> > > is_vserver_sys

-> works only inside vserver instances (so not on the vserver-host
itself), we can drop that as well for now (like for is_net_fs)

> I don't get the purpose of this one at all:
> > > get_libdir

> Here's its code:
> [snip]
> get_libdir() {
>     if [ -n "${CONF_LIBDIR_OVERRIDE}" ] ; then
>         CONF_LIBDIR="${CONF_LIBDIR_OVERRIDE}"
>     elif [ -x "/usr/bin/portageq" ] ; then
>         CONF_LIBDIR="$(/usr/bin/portageq envvar CONF_LIBDIR)"
>     fi
>     printf '%s\n' ${CONF_LIBDIR:=lib}
> }
> [snap]

Gentoo-specific, we don't need it. :)

> These might be useful sometime in the future. (I don't know if they
> could maybe even simplify existing scripts. ...because I don't know
> the existing scripts. :-) ):
> > > get_bootconfig
> > > get_bootparam
> > > is_older_than
> > > reverse_list
> > > get_mount_fstab

> These just do 'return 0'. Unless you think they are needed I'll remove
> them:

We have such functions also in /etc/grml/script-functions and
/etc/grml/sh-lib. I'd like to merge as much as possible. I
appreciate any feedback. :) [Though I'm not yet sure how to create a
new "API" without breaking anything, maybe we should clean up
lsb-functions as far as possible (without breaking any scripts) and
provide all the useful functions for scripts (interactive as well as
init-style scripts) in a new file (could be even
/etc/grml/script-functions as I'm the only one really using it
AFAICS).

> > > profiling
> > > splash

> These are the same very similar to their counterparts without the
> leading 'v', except that they just take action, if $RC_VERBOSE equals
> 'yes'. They are pretty simple and cleanly implemented. It wouldn't
> hurt to keep them (although they are currently not needed and *could*
> be removed): - (Thoughts?) -

Let's drop it, let's make it as clean and simple as possible.
Especially because Debian provides /lib/lsb/init-functions now as
well and I don't want to reinvent any wheels. :)

> > > vebegin
> > > veend
> > > veend
> > > veerror
> > > veinfo
> > > veinfon
> > > vewarn

> > > I grepped through our repositories and the functions we use are:
> > >     einfo, ewarn, eerror, eend, eindent, eoutdent, esyslog

> > Plus:

> > einfon
> > which is used in grml-debootstrap and grml-iptstate.

> Ah right, my multi-line zargs grep expression had a bug. :-)

:)

> > > Functions I find particularly ugly are everything containing *KV* in their
> > > name and the dolisting function.

> > > So, what do we need/want from that file? What could be dismissed?

> > No, we can drop all the *KV* stuff without any problem.

> Okay. I removed from the list above. I'll update the status of the
> remaining stuff as soon as I get to it.

Great.

regards,
-mika-
msg800 (view) Author: mika Date: 2007-09-16.10:21:25
* ft <bts@bts.grml.org> [20070916 12:10]:

> Yesterday night, I started to refactor the 'etc/grml/lsb-functions' file from
> 'grml-etc-core'. It would be helpful to know what is actually required to
> by implemented in that file.

Cool.

> The specification in LSB requires this:
>   * http://www.linuxbase.org/spec//book/LSB-generic/LSB-generic/iniscrptfunc.html

> 'lsb-functions' implements these functions:

> KV_major
> KV_micro
> KV_minor
> KV_to_int
> _eend
> add_suffix
> dolisting
> ebegin
> eend
> eerror
> eindent
> einfo
> einfon
> eoutdent
> esetdent
> esyslog
> ewarn
> ewend
> get_KV
> get_bootconfig
> get_bootparam
> get_libdir
> get_mount_fstab
> have_tput
> is_net_fs
> is_older_than
> is_uml_sys
> is_vserver_sys
> profiling
> reverse_list
> splash
> vebegin
> veend
> veend
> veerror
> veinfo
> veinfon
> vewarn

> I grepped through our repositories and the functions we use are:
>     einfo, ewarn, eerror, eend, eindent, eoutdent, esyslog

Plus:

einfon

which is used in grml-debootstrap and grml-iptstate.

> Functions I find particularly ugly are everything containing *KV* in their
> name and the dolisting function.

> So, what do we need/want from that file? What could be dismissed?

No, we can drop all the *KV* stuff without any problem.

> (Sticking only mika into nosy list, as I'm not quite sure who might be
>  interested in this topic. mika: could you update that list if needed?)

Thanks, that's fine already. :)

regards,
-mika-
msg799 (view) Author: ft Date: 2007-09-16.10:10:49
Yesterday night, I started to refactor the 'etc/grml/lsb-functions' file from
'grml-etc-core'. It would be helpful to know what is actually required to
by implemented in that file.

The specification in LSB requires this:
  * http://www.linuxbase.org/spec//book/LSB-generic/LSB-generic/iniscrptfunc.html

'lsb-functions' implements these functions:

KV_major
KV_micro
KV_minor
KV_to_int
_eend
add_suffix
dolisting
ebegin
eend
eerror
eindent
einfo
einfon
eoutdent
esetdent
esyslog
ewarn
ewend
get_KV
get_bootconfig
get_bootparam
get_libdir
get_mount_fstab
have_tput
is_net_fs
is_older_than
is_uml_sys
is_vserver_sys
profiling
reverse_list
splash
vebegin
veend
veend
veerror
veinfo
veinfon
vewarn

I grepped through our repositories and the functions we use are:
    einfo, ewarn, eerror, eend, eindent, eoutdent, esyslog

Functions I find particularly ugly are everything containing *KV* in their
name and the dolisting function.

So, what do we need/want from that file? What could be dismissed?

(Sticking only mika into nosy list, as I'm not quite sure who might be
 interested in this topic. mika: could you update that list if needed?)

 -ft
History
Date User Action Args
2007-09-16 12:44:18ftsetstatus: chatting -> resolved
nosy: mika, ft
messages: + msg808
2007-09-16 12:38:56mikasetnosy: mika, ft
messages: + msg807
2007-09-16 12:36:52ft1setnosy: mika, ft
messages: + msg806
2007-09-16 12:29:52mikasetnosy: mika, ft
messages: + msg805
2007-09-16 12:23:56ft1setnosy: mika, ft
messages: + msg804
2007-09-16 12:01:09mikasetnosy: mika, ft
messages: + msg803
2007-09-16 11:33:26ft1setnosy: mika, ft
messages: + msg802
2007-09-16 10:59:40mikasetnosy: mika, ft
messages: + msg801
2007-09-16 10:21:26mikasetstatus: unread -> chatting
nosy: mika, ft
messages: + msg800
2007-09-16 10:10:49ftcreate