Re: [Gnumed-devel] Re: previous postings to do with installers

[Sebastian Hilbert]

On Friday 18 June 2004 07:25, Jim Busser wrote:
> On Jun 17, 2004, at 11:11 AM, Karsten Hilbert wrote:
> >> Maybe all "installers" should contain the same checking code as
> >> "updaters" in case any user has previously installed components on
> >> their machine(s).
> >
> > They should.
> > Karsten
>
> I got an idea from an old reply of Hilmar's to Sebastian's plan for a
> Windows installer.
> In that reply, Hilmar suggested to have Python do  the installation:
> http://lists.gnu.org/archive/html/gnumed-devel/2004-02/msg00114.html
>
> Assuming that in a previous step a user has installed Python, could a
> Python script or application complete all of the rest of the
> installation?
That was exactly one problem I ran into. Sure we could mention the need for 
python in various installation manuals but if possible I would like to see 
the installation starting without the dependency on python because few users 
will have that on their system. 
>
> If the answer is "yes", could we do as follows:
>
> For each platform, an installer that would simply
> a) check if Python is to be found on the target client or server
> machine and resolve any deficiency, and then
Sound good. 
So on Windows we would have an NSIS installer looking for python and 
installing it if neccessary.
On GNU/Linux/UNIX we have many options.
Seems like we at least have Debian packages which take care of dependencies 
themselves. Same should go for Gentoo. I am not keen on building
RPM-packages. Although depencies can be handled via apt4rpm as well.

Problem being that one more program would be forced onto the users computer 
which potentially screws things up and should be avoided.

or we could use autopackage. This is what their website has to say:

This is autopackage, the distro neutral binary packaging framework for Linux 
systems.

* Build packages that will install on many different distros
* Multiple front ends: best is automatically chosen so GUI users get a
        graphical front end, and command line users get a text based interface
* Multiple language support (both in tools and for your own packages)
* Automatically verifies and resolves dependencies no matter how the software
        was installed. This means you don't have to use autopackage for all your
        software, or even any of it, for packages to succesfully install.

> b) install a Python app or script to complete the installation
This has pros and cons. Using a python script probably means loosing some OS 
specific features during setup. Those could be replicated but then one could 
use native installers in the first place.
>
> Re versions of Python:
>
> - do we identify any one "release" of GnuMed as requiring a SINGLE
> version, or tolerating a RANGE of versions, of Python?
> - could non-Python installers identify the version number(s) of Python
> packages already present on the target machine?
> - if the version of Python is too low for GnuMed
> - - must the existing version be kept on the machine, in case it is
> needed for 'legacy" Python apps or dependencies?
> - - or do we assume all Pythons are backward-compatible and take
> executive decision to delete or disable the old
> - - or do we ask the user
> - - - and if we ask, should we "save" the choice, so it can be "read",
> and the user (who may be a newbie) "reminded" next time?
>
> If so far we have a viable and preferred solution, we are talking about:
> 1) an installer of Python for each target OS/distro, configured to know
> GnuMed's "Python" needs
Yes
> 2) an installer/updater of GnuMed, written in Python
Nes :-)
>
> The installer/updater of GnuMed would:
> - - - modified from the Sebastian/Hilmar post above - - -
> 1.) Check for an installation of wxpython, wxwindows, pypgsql
Here is where the problems start. Or don't they ?
> 2.) Complain if they are not installed (search registry)
I guess searching the Windows registry canbe done with python but that 
replicates NSIS which has already been called to see if python is installed.
> 3.) mark missing ones for installation (links are hardcoded to internet
> addresses, can point to a cd)
> 4.) download and install missing programs
We only need that on MS Windows. GNU/Linux packages have their own mechanisms 
of taking care of dependencies. What about the Mac ? Any dependency handling 
or is this up to the installer ?
> 5.) check for old versions of GNUmed
Yes. This is platform dependent as well.
> 6.) update / install new
Yes
>
> also could Python be OS/distro-aware therefore a single piece of code
> accommodating OS exceptions as in:
>       if debian
>
>       elseif gentoo
>
>       elseif macos
>
>       elseif windows
Yes.

I guess what I am saying comes down to this.
( wget http://www.gnumed.org/installer.sh |sh installer.sh (or something like 
this. )

1) an installer of Python for each target OS/distro, configured to know
 GnuMed's "Python" needs
        install python: 
                Windows : NSIS can check, get and call the native python 
installer
                GNU/Linux : ?? 
                        - something that comes with (is installed) almost all 
distros by default
                        - shell / GUI depending on what's possible
                                either call appropriate command for 
distribution specific installation
                        or
                        --
                                leave it to the user to install python
                MacOSX : ??

1.2.) given python is installed - invoke installation of Gnumed
        python script (yes , now that we have it)  
                - can be called by user or above installer
                - checks for OS and distribution
                        Windows : call to separate GNUmed installer
                                        - gets, installs missing dependencies
                                        - installs Gnumed
                        
                        GNU/Linux: : call to native package managers if 
available
                                                - there is python-apt as far as 
I know
                                                - call to emerge via 
shell-script
                                                - rpm-python ?
                        
                                        or
                                                we take look at autopackage 
                                                        - should work on many 
distributions (distribution-neutral) 
                         
This hopefully solves the client side. Discussion please.
As for the server side. I don't favor GUI installation here. IMHO it's better 
to provide a very good (yet to be written) installation tutorial. At least 
for postgres. Installation of Gnumed's server part should be performed by a 
skilled admin. If we ever find we got nothing better to do we could come up 
with something similar to the cleint install. 

Guess there are two groups of potential users/admins out there.
First group is happy with a root shell and a set of shell scripts. Although 
they probably know how to install python we could provide a shell script 
which does a little checking and is capable of installing python. As usual if 
we go for distribution specific install some of these points are taken care 
of by the package managers rpm / ebuild / deb

The other group need a GUI even for installing the server part. Not because 
they cannot read text in a console but they might be intimidated by the look 
or overwhelmed by the power :-) Those folks probably run KDE/GNOME/XYZ
as root anyway:-) Just kidding.

Anyway. Do we really want to install wxwidgets / wxpython just for one install 
on a server ? I am not going to answer that. Is ncurses installed by 
default ? Maybe this is an option.  

I am not sure if everything makes sense. You tell me.

-- 
Sebastian Hilbert 
Leipzig / Germany
[www.openmed.org] -> PGP welcome, HTML ->/dev/null
ICQ: 86 07 67 86   -> No files, no URL's
My OS: Suse Linux. Geek by Nature, Linux by Choice

Unterstützen Sie die Entwicklung von freier Software durch Ihren
        Internet - Einkauf unter der Adresse:
http://profiseller.de/shop1/index.php3?ps_id=P1658133