[Gnumed-devel] Re: installing GNUMED in DEBIAN

[Andreas Tille]

On Sun, 20 Feb 2005, J Busser wrote:

> 1. will the package for the client take care of any gnumed dependencies 
> (wxpython, wxwindows etc) if they are not already on the machine?
Yes.  But because I do not ship a Packages file for apt you need two steps
after downloading the provided Debs from
      http://people.debian.org/~tille/packages/gnumed/

   1$ sudo dpkg -i *.deb
      ## dpkg will claim missing dependencies
   2$ sudo apt-get -f install
      ## apt will fix the problematic dependencies

> If the 
> machine has different versions of the packages installed, will the package 
> ask whether to remove older versions, and should I accept?
Dpkg does not allow different package versions and that's why older versions
are overriden.  It might happen that the upgrade path is not as smooth as it
should be for released packages (in contrast to my inofficial packages). Just
in case something goes wrong try

    $ dpkg --get-selections | grep gnumed

and do a

    $ dpkg --purge <old gnumed-packages>

but I guess it will not be necessary.

> And if the machine 
> should already have newer versions on it (in my case it probably won't, but I 
> am asking as more of a general case for Andrea's package), will the package 
> offer to install the older versions (e.g wxWindows 2.4) if that is required, 
> and would it work?
Try

    $ dpkg --force-help

to find the answer to this question yourself.

> I recall Richard had posted information on how to permit 
> both versions to co-exist but maybe much fiddling would be required? Would it 
> be a configuration worth including in the package?
As I said: You can not install two Debian packages with the same name at the
same time.  You surely can install one Debian package and use the CVS version
in a different directory.

> 2. with the client package being a "snapshot" package, does it install an 
> image or archived copy of gnumed as the cvs existed on the snapshot date?
I removed the string "snapshot" from the packages because the "version" number
implicitely tells that this is a snapshot.  It is no CVS version but the 
snapshot
which was created at this date by Karsten's cron job from CVS.

> 3. if as Andreas advises below, a user need simply type "gnumed", is that a 
> symlink(?) to a file or shell command that simply does run gnumed "from cvs"
It is a shell script.  Just have a look into it:

    http://people.debian.org/~tille/packages/gnumed/debian/tools/gnumed

If you do a symlink to this skript (which will be placed to /usr/bin/gnumed
by the package) a different config file (according to the name of the symlink)
can be used.  This is done by parsing the name of the executed program in line 
4:

    name=`basename $0`

> 4. if there is value to install a newer version from cvs than is in Andreas' 
> snapshot, I am thinking it could be worth having both on the machine. I did 
> not see a package for this (maybe it is not something a person would use a 
> package for).
We could build daily snapshot packages in the same cron job as karsten builds
the source.  The questions are:

  1. Do we really need this currently?
  2. Is GnuMed stable enough (regarding renaming files adding new modules
     that this would work in a cron job.

> Any suggested configuration for where to set up a newer CVS copy under 
> Debian?
Smae procedure as on any other Linux.

> A simple matter of putting it under a directory like gmcvs or will 
> that screw something up?
I do not know gmcvs but I do not see a reason why this should fail.

> Can I assume the "gnumed" command will still run 
> Andreas' snapshot version, while to run the newer cvs copy it would be a 
> simple matter of navigating to *that* directory and typing gnumed.py as 
> below?
I think so.  If gmcvs does not override anything from the packages (and it
should not because all things the packages install are under /usr/bin, /usr/lib
and /usr/share while local things should go to /usr/local/... all should 
continue
to work.

Please note that on the web site where I put the packages the server packages
are not provided to not confuse users.  The server packages do require a not
yet released dbcommon-config package.  So please go with the client packages
for the moment.

Kind regards

         Andreas.

--
http://fam-tille.de