[Gnumed-devel] Re: gnumed in Ubuntu

[Karsten Hilbert]

On Wed, Jan 07, 2009 at 10:50:32AM +0100, RKI Andreas wrote:

>>> and could you provide simple manpages for these?
>> They contain instructions in their headers.
>
> Uhm, Debian policy requires a manpage for every single executable
> in /usr/bin and /usr/sbin ...

Well, you asked for which are useful to be moved to the
Debian package not about which to move to /usr/(s)bin/

We do have manpages now for
/usr/sbin/gm-bootstrap/upgrade_server and for
/usr/bin/gnumed.

> Moreover as I said it is strongly advised to get rid of the *.sh
> extension.  UNIX does not have the extension concept and obtains
> the file type my libmagic.  So the comment in the fist line is
> enouth to tell the interpreter what to do.  Just imagine you will
> later decide to rewrite your shell script in Perl/Python/C/whatever.
> You will be forced to rewrite your docs, change other code which
> might call the scripts or whatever.
which is a good thing - it forces me to reascertain my
assumptions in those places which call the "old" code

> The other *.py files are OK, because they do not seem to be called
> themself but provide Python modules.  On the other hand this raises
> the question whether these should be moved to
>
>    /usr/share/python-support/gnumed-common/Gnumed/server
>
> or something like that
They could. It may require some fiddling with paths in the
config files. Which, surely, is the task of the package
maintainer :-)

> BTW another hint: Please do NOT use
>
>     #!/bin/bash
>
> but rather
>
>     #!/bin/sh
>
> if possible.

You say it. We have already reduced dependancy on bash in
many scripts and have changed them to use sh. Some require
bash, nonetheless. None of the *required* scripts, however,
I believe (such as the bootstrapper). Now, if say the
provided backup scripts need bash and thus do not run on a
netbook - I don't worry too much, that's not my task.

> certain shell implementation if not really needed (default shell
> for Ubuntu and also Debian Lenny will be dash).  In most cases
> it is quite simple to avoid bashisms (like '==' instead of '='
> and things like this).  This hint might become cruxial if you
> want to run your programs on low performance hardware (netbooks
> etc.).  In this case you want a lightweight shell and it is
> worth the very small extra effort to stay POSIX compatible in
> your scripts.

I am always accepting patches which make those scripts run
under other shells.

>>> Once again: If you start a script as root you do not need any sudo.
>> But you need "su".
>
> Yes.  As root you can su to any user.  But you do not need to
> configure sudo which is what I said.
I know. That's why I made those scripts use "su" now :-) I
simply didn't take the time previously to investigate how to
"run a command with su as a certain user".

>> I reduced the dependancy on sudo to those scripts which
>> optionally run *after* installation only (backup etc). Even
>> that can eventually be reduced to su by anyone who cares.
>> Bootstrapping should now work with plain "su".
>
> That's why I wrote you should start the script as root (which
> makes sense for somebody who is allowed to install a package
> because he should know how to become root).

That is precisely what our documentation says. Run the
installer scripts as root. And now they don't even need
"sudo" anymore :-)

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346