gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] Re: gnumed in Ubuntu


From: Andreas Tille
Subject: [Gnumed-devel] Re: gnumed in Ubuntu
Date: Wed, 7 Jan 2009 10:50:32 +0100 (CET)
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)

On Mon, 5 Jan 2009, Karsten Hilbert wrote:

should be installed.  There are some scripts provided in your tarball.
Which one is worth moving to the Debian package
All of them.

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 ...
There is a chance to circumvent this by moving stuff to

   /usr/share/gnumed/server/

and guide the user by documentation to this place.  But in general
some simple manpage just does not harm.  It could even be done in
a single manpage mentioning all these scripts and use symlinks in
/usr/share/man/man[18]/ to a common file.

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.  In short: you are asking for
trouble if you are using the extension.  The same is valid for
bootstrap_gm_db_system.py.

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 to enable precompiling the modules for
any installed Python version (which is the Debian way to handle
this stuff).

BTW another hint: Please do NOT use

    #!/bin/bash

but rather

    #!/bin/sh

if possible.  You should not force the user to depend from a
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.

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 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).

Kind regards

         Andreas.


--
http://fam-tille.de




reply via email to

[Prev in Thread] Current Thread [Next in Thread]