[Gnumed-devel] Re: Packaging (Was: Naming convention)

[Andreas Tille]

On Mon, Sep 07, 2009 at 04:34:19PM -0700, Jim Busser wrote:
> Thanks, it is hard to reverse engineer such things when one already did 
> multiple steps (install and run) while not yet knowing so well the  
> insides of the code... :-)

I would say that it is *really* rare that package installations write to
any users HOME directory.  So you can assume this will not happen.  I
fiddled around with this in the past and it is a nightmare regarding
maintenance.  Just assume a new user is created inbetween the upgrade of
a package - you have to deal with upgrading existing files in old users
homes, create new config files in the new users homes, the access might
be sometimes impossible if you have NFS mounted user homes and whatever.
So assuming that the package does not deal with /home is very reasonable
even if some postinstall scripts might have some influence on /home.

> Also, Debian apparently copies from tarball the shell script
>
>       client/gnumed --> /usr/bin/gnumed
>
> and several directories of client code and resources, which appear under 
> Debian to get copied into
>
>       /usr/share/gnumed
>
> and these get referenced by virtue of decommenting
> # export PYTHONPATH
> and adding an "export PATH" line as follows in /usr/bin/gnumed
>
> # packages which install the GNUmed python modules into a path not
> # already accessible for imports via sys.path (say, /usr/share/gnumed/)
> # may need to adjust PYTHONPATH appropriately here
> export PYTHONPATH="${PYTHONPATH}:/usr/share/gnumed/"
> export PATH="${PATH}:/usr/share/gnumed/bin"
>
> ... but there is no "bin" in my /usr/share/gnumed/bin in which case is  
> the above needed for some other purpose?

This might have been a leftover from previous changes.  I have to think
about this.  At least no real harm is done by extending the PATH with a
non existent directory.

Kind regards

          Andreas.

-- 
http://fam-tille.de
Klarmachen zum Ändern!